4 ms·

First off I have no standing here, and I am nobody. I am a customer of Silent Circle though. (or so I claim) I am sure that StavrosK is well known by the comm

First off I have no standing here, and I am nobody. I am a customer of Silent Circle though. (or so I claim) I am sure that StavrosK is well known by the community and it is my fault that I dont know his connection with SilentCircle. His profile points to stavros at stochastic dot io. But more importantly HackerNews is not a very secure platform. We have no real way of knowing StavrosK is StavrosK, or if ThinkBeat is the same ThinkBeat as last week. Using Hackernews or any social media as a platform to "override" a warrant canary is ill advised. In fact I think it makes matters worse. Properly signed messages through the announced channel is the way to go.

StavrosK 12y ago
Yep, this is definitely true. The only way to get this resolved is to update the canary. I can prove I work there, but it's irrelevant. I also want to note that I didn't try to override anything, dang helpfully tried to temporarily hide this post to avoid causing a panic while we get this resolved, but that doesn't change the fact that this is still a problem we need to resolve.
- jacquesm 12y ago
  I think this needs an additional safeguard, such as the destruction of the private key associated by the messages and a defined 'grace period' (defined up front, not after the fact) in case of a missed update as well as a very good procedure to update and check that the update has indeed been made.
  - StavrosK 12y ago
    What sort of grace period do you mean? For which?
    - spacefight 12y ago
      A grace period for the case that you forget to manually update the canary. Say you forget it, but after x amount of days you (or someone else) notice, then you update and continue. That grace period needs to be well defined, announced and properly used. Having a grace period of almost 3x the announced update rate (5 -> 25th of December) is IMHO not acceptable.
      - krapp 12y ago
        Doesn't that introduce too much ambiguity into what is supposed to be an unambiguous signal?
        jacquesm 12y ago
        It definitely increases the risk but whether or not that is acceptable or not is up to the users of the service. Hence my insistence that such a grace period should be an up-front thing. A service provider that starts out with 'we'll update this canary once per week, maybe, and if not maybe once per month' would not be deserving of my trust. One that says 'we'll update it once per week +- 12 hours on monday at noon' would be much more credible. It's just as much about confidence and competence as it is about the canary principle to begin with. If you're going to dilute that principle then err on the side of caution but recognize that humans are fallible. Better still, overdeliver and update it every 6 days if you promise 7, it's not that hard to make an agenda item out of it and do some automated alerts around the process of the update (not the update itself, obviously).
    - jacquesm 12y ago
      Missed updates, which is what this thread is all about. So say you define up front that you're going to update your canary once weekly but that you reserve the right not to update it for up to three weeks before you consider the canary to be in a state where you can't revive it. This adds a bit of leeway in case someone sleeps in and because you define it up front you can let your users determine if they are comfortable with the period specified as 'uncertain'. Any time beyond that grace period and you're definitely compromised, any time between the normal interval and the grace period and you're in 'degraded' mode and as long as you are within the normal interval you're good. Personally I think the grace time should be much smaller than your normal update period for the system to continue to work without appearing incompetent after all if you can't be bothered to update the canary you probably should not be trusted with critical data. It's not as if it is a large amount of work and it's not as if checking whether it is done or not is a large amount of work either. In fact, the update should be manual but the check could easily be automated and a 'canary out of date' text message could easily be sent to all the people working for companies such as silent circle if they take their job seriously.
      - StavrosK 12y ago
        Right. This goes back to the coercion issue, which I don't personally believe is valid. If one can be coerced to update a canary, then all bets are off. If they can't, there's no need to institute a grace period, as a canary won't ever be completely invalidated. Obviously, the longer a canary stays outdated, the better the explanation should be, and I wouldn't trust a daily canary that started getting updated after six months, but I think missing one or two updates isn't that farfetched. In Silent Circle's case, specifically, I don't think a NSL would have much utility, since we retain almost no customer data at all (only username/password, and optional email/name). I like the idea of automating the canary check message, though, and will write a script to do that right now, thanks.
        jacquesm 12y ago
        > Obviously, the longer a canary stays outdated, the better the explanation should be, and I wouldn't trust a daily canary that started getting updated after six months, but I think missing one or two updates isn't that farfetched. I don't see any factual difference between the two but I realize that humans are fallible. Note that you are still assuming that the only way a canary could be updated is by coercion, a keylogger installed at the right moment would allow one to update the canary absent the original updater just as well and as such I think canaries are of limited use. But if you do have one it should simply work as advertised. Isn't the real value for such monitoring in the future traffic and traffic analysis rather than the content or the customer data?

StavrosK 12y ago

Yep, this is definitely true. The only way to get this resolved is to update the canary. I can prove I work there, but it's irrelevant. I also want to note that I didn't try to override anything, dang helpfully tried to temporarily hide this post to avoid causing a panic while we get this resolved, but that doesn't change the fact that this is still a problem we need to resolve.

jacquesm 12y ago
I think this needs an additional safeguard, such as the destruction of the private key associated by the messages and a defined 'grace period' (defined up front, not after the fact) in case of a missed update as well as a very good procedure to update and check that the update has indeed been made.
- StavrosK 12y ago
  What sort of grace period do you mean? For which?
  - spacefight 12y ago
    A grace period for the case that you forget to manually update the canary. Say you forget it, but after x amount of days you (or someone else) notice, then you update and continue. That grace period needs to be well defined, announced and properly used. Having a grace period of almost 3x the announced update rate (5 -> 25th of December) is IMHO not acceptable.
    - krapp 12y ago
      Doesn't that introduce too much ambiguity into what is supposed to be an unambiguous signal?
      - jacquesm 12y ago
        It definitely increases the risk but whether or not that is acceptable or not is up to the users of the service. Hence my insistence that such a grace period should be an up-front thing. A service provider that starts out with 'we'll update this canary once per week, maybe, and if not maybe once per month' would not be deserving of my trust. One that says 'we'll update it once per week +- 12 hours on monday at noon' would be much more credible. It's just as much about confidence and competence as it is about the canary principle to begin with. If you're going to dilute that principle then err on the side of caution but recognize that humans are fallible. Better still, overdeliver and update it every 6 days if you promise 7, it's not that hard to make an agenda item out of it and do some automated alerts around the process of the update (not the update itself, obviously).
  - jacquesm 12y ago
    Missed updates, which is what this thread is all about. So say you define up front that you're going to update your canary once weekly but that you reserve the right not to update it for up to three weeks before you consider the canary to be in a state where you can't revive it. This adds a bit of leeway in case someone sleeps in and because you define it up front you can let your users determine if they are comfortable with the period specified as 'uncertain'. Any time beyond that grace period and you're definitely compromised, any time between the normal interval and the grace period and you're in 'degraded' mode and as long as you are within the normal interval you're good. Personally I think the grace time should be much smaller than your normal update period for the system to continue to work without appearing incompetent after all if you can't be bothered to update the canary you probably should not be trusted with critical data. It's not as if it is a large amount of work and it's not as if checking whether it is done or not is a large amount of work either. In fact, the update should be manual but the check could easily be automated and a 'canary out of date' text message could easily be sent to all the people working for companies such as silent circle if they take their job seriously.
    - StavrosK 12y ago
      Right. This goes back to the coercion issue, which I don't personally believe is valid. If one can be coerced to update a canary, then all bets are off. If they can't, there's no need to institute a grace period, as a canary won't ever be completely invalidated. Obviously, the longer a canary stays outdated, the better the explanation should be, and I wouldn't trust a daily canary that started getting updated after six months, but I think missing one or two updates isn't that farfetched. In Silent Circle's case, specifically, I don't think a NSL would have much utility, since we retain almost no customer data at all (only username/password, and optional email/name). I like the idea of automating the canary check message, though, and will write a script to do that right now, thanks.
      - jacquesm 12y ago
        > Obviously, the longer a canary stays outdated, the better the explanation should be, and I wouldn't trust a daily canary that started getting updated after six months, but I think missing one or two updates isn't that farfetched. I don't see any factual difference between the two but I realize that humans are fallible. Note that you are still assuming that the only way a canary could be updated is by coercion, a keylogger installed at the right moment would allow one to update the canary absent the original updater just as well and as such I think canaries are of limited use. But if you do have one it should simply work as advertised. Isn't the real value for such monitoring in the future traffic and traffic analysis rather than the content or the customer data?