Sophos Cloud Optix
Just under two months ago, we wrote about the closure of secure email service Lavabit.
Lavabit’s founder, Ladar Levison, explained that he was in a spot of legal bother that made it impossible for him to continue to operate with a clear conscience, so he would suspend the service.
He also noted that, much as he wanted to, he couldn’t give details about said legal bother.
All he could do was to point out that he had lodged an appeal and hoped to open up the service again one day.
Of course, the smart money was that law enforcement wanted access to data belonging to a certain Mr Edward Snowden, the National Security Agency (NSA) whisteblower, who was known to be a Lavabit user.
We hedged our bets about the reasons here on Naked Security, since the only thing we knew was that we didn’t know whether the kerfuffle involved Snowden at all.
But recently unsealed court documents [PDF, 162 pages, 16MB] now tell a bit more of the story.
The name Snowden is still mentioned only in passing (various redactions have suppressed names throughout the unsealed documents).
So we still don’t have official confirmation that Snowden, amongst others, was the target of the investigation.
That, however, hardly matters any more.
What matters is the intriguing tale of the court requiring Lavabit to hand over its SSL private keys, and Lavabit arguing that it ought not to comply, since that would give access to all messages to and from all customers, which would be unfair and unreasonable.
Very greatly simplified (and I hope I have not oversimplified to the point of misunderstanding), the court wanted Lavabit to enable law enforcement to intercept so-called email metadata for a particular user.
But due to the use of SSL/TLS at all times, with data kept encrypted in transit and at rest, even accessing mail headers was no simple matter – unless law enforcement were given Lavabit’s private keys.
(A MiTM, or man-in-the-middle, attack on encrypted traffic is trivial if you have all the encryption keys and certificates to use “in the middle.”)
Eventually, Lavabit had little choice but to comply, turning over five SSL private keys.
It still wasn’t game over for Lavabit user’s privacy, however, because Levison gamely supplied the cryptgraphic material in printed form, stretched over 11 pages in a four-point font.
To say that the law enforcement officers were underwhelmed is the understatement of the year, and matters were soon back in court, with “handing over the keys” quickly redefined to mean, “handing over the keys as computer-readable PEM files suitable for immediate use, and no more mucking around.”
Indeed, to guard against further stalling tactics, the government petitioned the court to fine Levison $5000 for every day he continued to dither.
At this point, Levison folded and complied, but pulled the plug on Lavabit at the same time, and that was that for the men-in-the-middle.
The New York Times reports that a prosecutor referred to the abrupt shutdown of Lavabit as “just short of a criminal act,” but, then, nearly-a-crime isn’t actually a crime.
What can we learn from this?
To me, one of the most interesting aspects of this story is the recognition by a non-tech-savvy court that at least part of the problem was the regrettable fact that Lavabit would need to put the privacy of 400,000 users at risk to secure the lawful surveillance of just one person.
As the court pointed out (this is a transcript, not a written judgement):
[Y]ou're blaming the government for something that's overbroad [the requirement to hand over the all-revealing SSL keys], but it seems to me that your client is the one that set up the system that's designed not to protect that information, because you know that there needs to be access to calls that go back and forth to one person or another. And to say you can't do that just because you've set up a system that everybody has to -- has to be unencrypted, [read: in which all users are encrypted in the same way] if there's such a word, that doesn't seem to me to be a very persuasive argument.
In short, the court is as good as saying, “If you wanted to come up with this ‘but what about the privacy of all the 399,999 other users’ argument, why didn’t you implement the system so their individual privacy was better protected?”
After all, Lavabit could have taken an approach more like the one used by Kiwi internet showman Kim Dotcom’s Mega service, so that each user’s encrypted traffic and content could stand (or fall) alone.
Of course, that wouldn’t have stopped Levison shuttering the entire service, effectively DDoSing all his users to protect the privacy of one of them.
But from a cryptographic point of view, it would have made a lot more sense to me.
Image of eye charts courtesy of Shutterstock.
I'm not sure the author of this article fully understood the story revealed by the unsealed documents.
Author Paul Ducklin says that Lavabit could have been better by allowing each user's "traffic and content" to fall on their own. But Lavabit *did*, according to Ed Felton of Freedom to Tinker (among others). Each user (if desired) could fully encrypt their own email providing secrecy of content, but not secrecy of metadata.
The issue is that the government demanded the meta data on one user (presumably Snowden) and, when Lavabit refused, the government then demanded Lavabit turn over the keys so that they could collect the metadata on the one user… which would have obviously allowed the government to vacuum up ALL users' metadata.
Of course, the government said in the unsealed documents, that they would never do such a thing (*eye roll to NSA*).
I thought like that until I looked at the court documents. (I'll be honest. I did not read every word of every page.)
I think my point is that either of Lavabit or law enforcement, with one set of keys, could get the data that was requested for any user, without the co-operation of that user. That doesn't sound to me like each individual's data standing or falling on its own to me.
I think what Lavabit tried to was to protect everyone by making it so that to reveal one person would be to reveal everyone, thus giving them the arguement that to give out the data of one person (which may be deemed legal) they would have to expose everyone, and that would go too far and would be unreasonable. Sadly that bet didn't work… because in the US government/courts there is no such thing as fair and reasonable anymore.
Let me see if I follow you correctly – you build a system in which a violation of the privacy of any of your users causes an automatic violation of privacy for everyone else…and you do this to *improve* protection for everyone, and as a way to *thwart* the government?
Wouldn't a better system be to say, "Here's all the data we've collected on <mysteryuser> only. We don't retain the keys to manipulate the data once the message has been processed. Please ask the owner of the data to provide the message key if you wish to decrypt it." ( Perfect forward secrecy, I think I am trying to say.)
It could have been the thinking behind it, yes. Of course, that was totally starry-eyed of them. If the government were worried about collateral damage Snowden wouldn't have had anything to leak.
Separately encrypting the metadata for every user… yes, why not. Though then the pressure is on the individual, and giving the government the ability to access the data that way is not good either. Couldn't they have erased everything instantly instead, or was the metadata needed for the operation of the service? And for how long? The government can't access things that don't exist…
I think the US Govt wanted the meta data on future transmissions, hence the courts annoyance when Lavabit simply closed down (smirk). At some stage Lavabit would need to know the destination of an email so they could route the message, so therefore the destination data would need to be decryptable by Lavabit – which means anyone else with the keys (and access) could also do the same.
Yes, that's my reading of it. There was a "show us what you've got" aspect and a "let us run an intercept on what might yet turn up." (Which is why the identity of the interceptee was suppressed, and, indeed, the fact that there was an interceptee, since he'd probably have guessed his own identity 🙂
You could, albeit with practical difficulty, operate with a different SSL key pair for each user…thus solving the "we really do keep your communications separate."
Does no one here understand how SSL works? Really?
SSL is a bit of a red herring…the issue is that Lavabit ended up in a one-key-fits-all situation (actually, five keys were involved, but not 400,000 keys).
Seriously.
It seems to me that no one here understands how SSL works! Assuming we are talking about the key to Lavabit's web certificate! Every (physical) web server has only one certificate people. Doesn't matter whether you are connecting to mail.google.com or yahoo.com or bankofamerica.com. It doesn't present the customer with a separate cert for every individual user that is trying to connect!!!!
But you *could* rig things that way if you wanted, such that there was a private key for every user (or group of users who were willing to have their metadata "stand or fall together").
There would be some trusted certificate annoyances for your users, and the government could still go after everything, but wouldn't have to be given everything if all it had asked for was one user – you could give away that one private key and the potential harm to the other 399,999 would be avoided.
(Cloud-based services that provide HTTPS web sites for X different customers don't use the same SSL cert for every website they host, do they? They have X different keys on hand. Lavabit could have done the same sort of thing, for X = 400,000.)
Actually, the problem is that the SSL connection is not on the application layer, but one layer before that. I.e. the connection is made and certificates excanged BEFORE the client has told the server who he is or what he is planning to do. This means that if you want to give everyone their own SSL tunnel you need to give every single user a unique IP address/port combination to connect to.
Of course, key-based authentication would be a possibility, but that does not encrypt the connection between endpoints and therefore would not make a mitm attack impossible (which the SSL certificate does do). So in conclusion, I don't really agree that it would be technically feasible to protect every user seperately.
You can very easily give each user their own sub domain and then use the SSL extension Server Name Indication to have different certificates per sub domain.
SNI provides the equivalent functionality of name based hosting for SSL connections by including the hostname in the SSL handshake.
With SNI the hostname is passed in cleartext during the TLS negotiation. With your proposed scheme that would give the username (as part of the subdomain) plus the IP address will be in the packet headers, and I'm sure inspection of the packet headers will reveal other metadata, but the NSA would at least be able to get a connection between the IP address and hostname, thereby being able to track users in ways they couldn't do if encryption were negotiated before the hostname was passed, or if the hostname were not tied to each individual username.
Hi Peter – I was trying to respond in broad brush strokes to Erik's point that it's not technically feasible to protect every user individually. I believe it is and SNI is an example of a technique that might allow it, there are others.
Although I don't want to get into designing this imagined system on-the-hoof I will say that Hostnames, IP addresses and usernames are not secrets in my book and shouldn't make you insecure if discovered. If you're relying on those things being secret then I think that's a problem.
My understanding is the whole point of Lavabit was that your mail and metadata was secret and guaranteed to be kept that way. With Lavabit having to give that away AND NOT TELL THE AFFECTED USER means that all the users might as well use gmail as Lavabit could no longer guarantee the confidentiality of the emails. The commentary on the design of the encryption system is secondary to the perverting of the trust offered by Lavabit.
Perhaps Lavabit should never have set up in the US where these legal demands are commonplace and impossible to avoid.
Or Lavabit could have tried a more MEGA-like approach, though that would have made it more of an "encrypted email dropbox service" than a special-purpose email server.
IIRC you could receive email via TLS from "regular" servers, and send to "regular" TLS servers…so (as I think another commenter pointed out) the metadata the cops wanted would have to be processed "in clear" by Lavabit at some point.
Seems nobody has addressed the issue whether Lavabit could have provided the requested information "re-encrypted, or whatever it takes" in such a way that the Government can only get at the appropriate data and nothing else.
It's a bit of a labour to read all those 142 pages (though some of them are handily blank) but I think this was addressed, with Lavabit's lawyer suggesting that the US government might consider bankrolling some custom coding that would provide the surveillance the court had authorised without harming the privacy of the "other 399,999."
IIRC the argument was that it wouldn't be easy (since it was all custom code in the website) and Mr Levison would need paying, and it might take a while, etc.
So I think there was (at least in the endgame) an effort to argue for a "whatever it takes," which ended up pretty much irrelevant once the service was shut down.
I think Lavabit did the right thing. Their secure email service was no longer secure so they fessed up and did the only thing they could do to maintain their integrity.
IMHO most people who *need* secure email want to keep their communications private from the various governmental organisations around the world rather than criminal organisations. Once the US government has access to any account they wish (albeit via a court order) who knows who they will share the data with.
I hope they move out of the US and set up again somewhere where governments do not require this sort of information. Does such a place even exist?
My take on Lavabit was that they guaranteed everyone's meta data (users can secure their own email via pgp, etc if they wish – no one can crack that without a planet sized hammer). If they can't guarantee the security *all* of the mail their service becomes pointless. This is especially true with gagging orders.
Dear Paul Dunklin
so does your email encryption product provide the 'single user' certificate equivalent ?
and, if as it appears, user encryption is based on a password key – does Sophos have sight of this key ?
Gary Prosser
I assume you are talking about Sophos SPX (Secure PDF Exchange)…so here goes:
"Does your email encryption product provide the 'single user' certificate equivalent?" – No.
"Does Sophos have sight of this key?" – Yes. (Sophos the product, not Sophos the company.)
To go in to bat for myself here: the SPX system neither offers, nor claims to offer, a service like Lavabit. SPX's goal is a bit less lofty, but IMO useful nevertheless: it lets you send non-plaintext emails to people who aren't part of your public key infrastructure, without asking them to use a special webmail client or install a proprietary email extension. They use software they probably already have – any PDF reader that supports Adobe's AES document encryption standard.
The idea is that the email can't be mined for its content on arrival at a webmail service; can't be sniffed along the way if any of the hops to the recipient don't use TLS; and can't be read by the wrong person if the recipient has left the company or forwarded their email during a vacation. So, if you tag an email "confidential" on the way out, then SPX converts it to PDF and encrypts it, using AES, with the recipient's key. Since this is symmetric encryption, the server that's doing the encryption needs to know the key.
Therefore, Sophos's product "has sight of the key." But Sophos the company does not, since this isn't a service hosted by us, but a product run by you. (Or, presumably, by someone you trust.)
As for the follow-on question, "Do Sophos products make copies of customers' key material and squirrel it back to HQ 'just in case'?"…well…there's no point in answering that, since if I were to say "No," the next question would be, "But you would say that, wouldn't you?" 🙂
PS. It's Paul Ducklin, not Paul Dunklin.
I'm not sure how much a new SSL key (or even five) costs, but wouldn't that have been an easier way to re-secure future comms after turning over the keys to content the G already had?
Now, of course, if some agency had been snarfing up traffic to & fro Lavabit, all the old traffic is vulnerable; however, shutting down Lavabit now does nothing to mitigate the vulnerability of past traffic.
My knowledge about SSL is still scarce but wouldn't using DHE or ECDHE as the key exchange mechanism alleviate this kind of problem where a service's private keys are compromised?
Paul, I have been regularly reading your posts for several months and never commented – but here I think you nailed it 100%. Nice job.
Paul, I think your ending is incorrect. The core issue was that Lavabit didn't log the metadata being sought. There is no law in the US requiring an email service provider to log metadata.
What the government argued is that because Lavabit couldn't provide the metadata (without modifying their system) they would need to provide their SSL keys instead. With the keys in hand the government could then collect the metadata on its own. The problem is that they could also collect passwords, credit card numbers and email content. It's also worth noting that the feds wouldn't agree to let Lavabit audit the collection an ensure they were only collecting metadata on the accounts authorized by the PTTR order.
Others are correct in stating that the shut down prevented the feds from collecting new information but they were able to decrypt any data they have recorded while the site was operating.
It's also true that DHE or ECDHE would have prevented the feds from eavesdropping even with the keys, but if Lavabit had enabled Diffie-Hellman the feds would have simply implemented a MitM attack (and probably fined Lavabit for their efforts).
The feds also made it clear that if Lavabit revoked its SSL keys after turning them over they would be held in contempt and then required to provide the new SSL keys. The compromised keys would have to remain active for at least 60 days (the length of the PTTR order), but that timeframe could be renewed indefinitely.
Finally, it's worth noting that Lavabit did use individual keys to protect data at rest on it's servers. But that protection required the plain text password be sent to the server via SSL so it could decrypt the private key and access the user's data when they logged in. That is why the feds were keen to acquire user password(s). See this link for details:
https://web.archive.org/web/20130805154113/http:/…
Need to set up a secure service offshore. However, it needs to have a big government to resist the US. Remember the US was able to get everyone's Swiss bank records recently by threatening trade with the US.
I wonder if any country has what it takes to stand up to them? Can they live without Big Macs and Google?