Silent Circle's warrant canary is out of date
canary.silentcircle.com
canary.silentcircle.com
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.
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.
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.
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.
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.
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?
So, I essentially have a built-in grace period of two days before the canary expires, and users know that a canary issued on the 13th or 14th is also fine. I really don't see any downside to this method except for the fact that it extends the effective interval between canaries up to two days (the same as a two-day grace period would, but with less reduction in confidence). And in my application that interval varies based on the length of the month anyway, so you can see that I'm not particularly concerned about the length of the interval so long as there is a clearly defined date after which users should worry.
Lets say there was a good reason for the canary not being updated.
I the FBI or whichever law enforcement agency was involved in the process noticed that updates were missing, (or saw it because it was pointed out on a well trafficked website)
Could the law enforcement agency then compel the employees to post a note that it was just a mistake and it will be rectified soon? And then have them update it?
Since not updating it when asked would equal disclosing that the event had taken place, which under certain laws might be illegal?
This hurts my head.
It sounds like you're confusing the PSTN calling offering with the Silent Phone service itself, which is encrypted peer to peer.
"enables Silent Circle members to make and receive encrypted, private voice calls through the company's Silent Phone service to non-Silent Circle subscribers in 79 total countries"
The PR goes on and in about how "disruptive" this is, even though it's much more expensive than Skype, and about as secure.
It's highly misleading. The PR obviously wants people to buy this product for security and encryption, but it can't deliver. It's about as good as using SIP+TLS/SRTP, Skype, or a VPN. Yet given the high cost (12 cents a minute) plus the marketing, it makes users believe they're getting actual encrypted calls. You guys should clearly state in the marketing and in-app that the call gets a first hop encrypted, then dumped unencrypted out to the Internet/PSTN (which nowadays are rather intermingled, sometimes when least expected).
Other stuff like "100% dedicated network – no sharing or leasing" sounds like it's probably untrue, or uses a special value of 100%. Either way, such statements should be backed with clarification.
Finally, there was a PR with Mike Janke, linked here on HN about a year ago. I can't seem to find it now, but he says a bunch of misleading/false things while writing off competition and makes SC come off rather slimy. Y'all shouldn't let him talk for the company as it makes the engineers look bad. (Not to mention the whole thing about Blackphone - a closed source fork of Android with a few 3rd party apps, no mention of the baseband processor issue, yet billed as some amazing breakthrough and it's own OS.)
SC should lower the hype and be transparent about things. Overall, I get the distinct impression it's a marketing joint bankrolled by a non technical founder, who hired some good names and provided a commercial vehicle for zRTP. Which by itself is fine, but the execution feels more marketing than technical.
PS, if you're using FreeSwitch, then I gotta ask: where are all the CVEs? Are you fixing them privately, publicly without announcement, or are you using FS without a security audit? (The only reason I mention this is SC often seems a major sponsor of ClueCon.) If not FS, what is your VoIP platform, and in what language is it written?
From http://en.wikipedia.org/wiki/Warrant_canary
The US security researcher Moxie Marlinspike states that "every lawyer we've spoken to has confirmed that [a warrant canary] would not work" for the TextSecure server.
Direct link: https://github.com/WhisperSystems/whispersystems.org/issues/...
https://developer.android.com/tools/publishing/app-signing.h...
Compare this to rsync's (http://www.rsync.net/resources/notices/canary.txt), which this seems to have been based off of. It explicitly states "No warrants have ever been served to rsync.net, or rsync.net principals or employees. No searches or seizures of any kind have ever been performed on rsync.net assets, including:..."
If they failed their own canary - how could you believe them in terms of their warant canaray setup ever again? Not so much at all, I'd say.
A canary also fails open by design. There's no way for the canary to fail on the side of getting your data compromised. If we forget to update it, you should just be more cautious, until we update it again (if we do).
Can there really be a fail-open or fail-safe here?
Edit: "not posting" fixed.
From the outside, there is just no way of knowing that it was just a forgotten update or if it was a strong message.
Nobody is going to convince me that same individual went on a twenty day bender and sobered up on Christmas morning.
False alarms are lethal for something as important as this.
Sorry...
That signal has now gone off and I have no clue how you could put the genie back into the box without a time machine.
Then again, I don't know if the US can make you lie and coerce you to sign the canary. If so, then what you say makes sense.
"If the canary has not been updated in the time period specified by the host, users are to assume that the host has been served with such a subpoena."
That seems pretty clear to me.
Then, it stands to reason that if the canary gets updated again, you trust that everything is fine again, and that the owner didn't get served with an NSL. Therefore, it follows that if you trust canaries at all, you cannot stop trusting them if they fail to be updated for a time, except for that specific duration.
Please correct me if my reasoning is wrong anywhere.
Once dead they tend to stay dead. If you then prop up the canary afterwards and say it wasn't really dead, we just forgot to feed it for three weeks you're risking credibility at a minimum.
So either the operator is incompetent (which makes them a bad choice for trusting them with critical data) or the canary is now potentially under control of another party.
The problem I have with the whole setup is less one of whether or not this is a 'fixable' issue and we should redefine warrant canaries and give them a re-incarnation option, it's that if you think the chances of getting slapped with a NSL or warrant are large enough to have a canary system to begin with that you're dealing with customers that are - or should be - paranoid enough that any tampering with the system other than behavior as explicitly stated up-front should be un-acceptable.
Otherwise it becomes a question of where do we draw the line? A few weeks, a month or a year, what point is there to feed the canary at all if you can revive it at some arbitrary point in the future. After all the canary is a channel with very specific conditions attached to it, it now seems as though you are trying to redefine those conditions after the fact and that is the one property a thing like a warrant canary does not have.
If silent circle would have stated up front we will feed the canary weekly + a potential month in which we will take a holiday and everything is fine, otherwise we have been served with a warrant then you could call this operating within allowed parameters.
But I don't think you should be able to tack on such a clause afterwards.
The intra-period but within defined parameters risk is a different one from the post canary has given its signal one.
The way I understand the whole system to work is that you set up a fragile, fusible link that will blow exactly once to give its signal, and any further signals are suspect. Otherwise why agree on a protocol to begin with if you can then break that protocol at will?
I can see a case for changing the protocol assuming the previous one was not broken but once you violate the protocol I can't see a way to un-do that without making the whole concept meaningless as a result.
I don't think that conclusion is warranted. If the canary gets updated it could be any one of a number of things, one of which is that things are fine. But saying that the canary being updated is the same as you being compelled to lie misses out on a few critical options:
- presumably you set the time interval between updates short enough that your key or passphrase could not be compromised in that timeframe, so any interval longer may indicate a compromised private key
- it's only fine if the canary specs as defined up-front have not been violated (which in this case they have)
- canaries may be useless as a concept anyway because lawyers are human and hence fallible.
(That last one is a stretch, but with stuff like this it's either 1 or 0, not something in between and I don't see an iron clad guarantee there, merely an informed opinion.)
That's not really true.
The canary is only "dead" and that channel is only useless until a new one is published. Unless the operator of the canary has decreed in advance that a particular time period elapsed should be considered "dead" regardless of future updates, then the canary is alive and well as soon as a new update comes out.
Here's the thing - a warrant canary is, by definition, a manual process. It should never be automated. A human has to resign and republish (or they are doing it wrong). And this means that sometimes they get published late.
In the 9 years that we (rsync.net) have been publishing our canary, we've probably missed our normal Monday morning publish 10 or 15 times. But as soon as we publish, with the affirmative canary and it's signature and language, etc., it's alive and well again.
Obviously this changes if someone is months late with an update.
That's what I was asking before - what is a reasonable timeslot for being "late"? Is it "months" or "weeks" or the <deltaManualUpdateT+1d> of canary x? In this case, SC was almost 3 times their weekly update rate late (December 5th to December 25th).
Once it gets to weeks, I think something else is going on.
By how much did you miss your Monday morning deadlines? Did you ever go a whole week without an update? Is someone tasked with doing it and someone else tasked with checking that it has been done (which is the way this should be set up, preferably with more than one person for the second role backed up with an automated process that sends out messages of impending aviary demise).
I don't care for all this "I'm 99% sure" and "blah bah bah."
Make an affirmative assertion, and back it up, please.
All this non-sense about their "offices being closed" is just silly.
My conclusion is that they've lost the trust of the public, and their reputation and credibility is tarnished, perhaps irreperably.
https://blog.silentcircle.com/our-move-to-switzerland/
If the warrant canary is out of date, though, I wonder if they moved to Switzerland because the US government tried to get to them, and it wasn't just a forward-thinking action.
$> whois 199.180.184.6
Think of Microsoft's current fight over giving up email from one of their Irish servers. Microsoft has the resources to fight this off, and that's the only reason they're still fighting and not complying. Someone small would have to fold or go to jail.
If you're small, it doesn't matter if the law is on your side if the USG overwhelms you before the question even gets a hearing.
For now, do not trust that Silent Circle has not been compromised despite anything you may read in this thread. When the canary is updated, then you may return to the state that you had before: you can speculate that they are being coerced into lying about the canary, or that they are trustworthy. That choice is an has always been yours to make.
It's not practical to release new canaries constantly, so there is always an interrim period between one and the next where it is unclear if the situation has changed. A due date/release schedule is a guideline to users for that interrim period. Last canary within one normal scheduled interval? Everything is normal. Last canary longer back? Now we must worry that the situation has changed, because if it hadn't the canary should have been updated.
The release schedule is only that, though, a guideline for deciding during the period since issuance. It changes nothing about the fundamental nature of the canary as a claim up to the specified date. A new canary, early, on time, or late, makes the exact same assertion as each of the older canaries. It being late just prevents user confidence about the state of the service in the time period between 'expiration' and new issuance, the new issuance brings back this confidence.
Releasing a canary late is a sin because it creates a time period in which the state of the service is in question, and frequent/lengthy/otherwise egregious incidents should reduce user trust in a service. That time period ends when a new canary is issued, though, as the protection of the canary is once again in place.
But perhaps I simply misunderstand your ideas. Could you explain what you mean by a means other than analogy (which is honestly not particularly useful here, as the nature of signed text is different than the nature of birds)? Or a better question, if a new canary is issued, but late, then what is the actual scenario that users are not protected against?
We need a canary monitor service or something to that effect, I imagine of the alarm wasn't raised here then this situation could have gone on for much longer still. Makes you wonder what the value of the canary is if nobody is actively monitoring it.
If the NSL had the ability to force an update, the canary would have been updated before anyone noticed it was a problem. If the NSL didn't have the ability to force an update, the canary would still remain un-updated.
So it's up again?
That or they were forced to by law enforcement due to all of the attention this was getting. Turns out warrant canaries are mostly useless.
ps anyone got a link to any previous canary update, or even a copy of the public key?
pps the update I read (including signature) had sha1sum 790b9817923137c68bd0a818456f2b47ff25719f
From far away, the warrant canary served its purpose well.
$> whois 199.217.106.243
http://myip.ms/view/ip_addresses/3352914432/199.217.106.0_19...
Edit: Typo law enforcement.
Edit: Ok, we restored it with a question mark. That's a more balanced way to handle these; I just forgot about it.
Edit 2: Now that I think about it, there's no need for a question mark on a factual statement. Sorry—I'm a little distracted right now! (We can change "is" to "was" if they update it, but someone will have to let us know.)
I'm going to detach this subthread now so it can go to the bottom as off-topic.
The sole issue of a warrant canary is to either feed it weekly (their own decision) or retire it.
Not feeding the updates weekly means something... telling everyone false alarm doesn't make me happy.
Everything else would completely defeat the purpose of the canary.
Edit: the only thing i'll accept here is an explanation signed with the same PGP key As long as that hasn't happened something happened. Period.
I used NSL as a generic term. I'm not american either, doesn't change anything.
But seriously please stop posting. You're doing more harm than you help. You can't know IF something happened. Posting a public statement that nothing happened just puts the people that might know under more pressure. There is a good reason you can't update the canary yourself. Because if you could, it wouldn' work.
I cannot take your company serious that way.
Next time send the SMS without any public statement please.
http://en.wikipedia.org/wiki/Warrant_canary
"A warrant canary may be posted by the provider to inform users of dates that they have not been served a secret subpoena. If the canary has not been updated in the time period specified by the host, users are to assume that the host has been served with such a subpoena."
I'm not talking about trust in a company or how this makes one look. I'm talking about protecting people's data, and failing to update a canary doesn't compromise that.
> No, you have no clue
Come on, lads.
First of all, it is a factual post, nothing sensationalist.
Second, it is obviously on topic (warrant canaries and their failure modes have been discussed here several times, and usually very civilly).
Third, just because "some guy" tells you "hey, everything is fine" doesn't make it true. You just declared that you're satisfied with the explanation, which I can understand, but demoting the story means that you don't believe that someone can rationally think otherwise. That's unfair, IMO.
Fourth, if you're posting a warrant canary and fail to update it, you deserve the suspicion and discussion. That's kind of the whole point. So: working as designed. :-)