Here at Naked Security, we’re well-disposed towards encryption, especially TLS, which is the cornerstone of secure web browsing.
TLS is short for Transport Layer Security, and it’s the technology that puts the padlock in your browser’s address bar when you use HTTPS to visit a secure website.
In theory, TLS is easy, because software at each end does all the hard cryptographic work of securing the connection.
Importantly, TLS isn’t only about the confidential aspects of encryption, where your data is scrambled so it’s meaningless to eavesdroppers.
TLS also deals with authenticity and integrity, using encryption to help you verify not only that you’re talking securely, but also that you are talking to the right person.
(No point in having a strongly-encrypted session with a crook instead of your bank!)
But TLS has one tricky part: before your web server can “prove” who you are, you have to get a digitally-signed certificate that vouches for you, issued by someone who is themselves trusted by everyone’s browsers.
Until recently, that was modestly complicated, and cost money, both up front and then every year or so to renew the certificate.
Then, a non-profit called Let’s Encrypt came on the scene:
Anyone who has gone through the trouble of setting up a secure website knows what a hassle getting and maintaining a certificate can be. Let’s Encrypt automates away the pain and lets site operators turn on and manage HTTPS with simple commands. Using Let’s Encrypt is free, so there is no need to arrange payment.
The concept is simple: HTTPS makes things harder for eavesdroppers, phishers, scammers and other imposters, so let’s encrypt.
An imperfect month
Unfortunately, the past month hasn’t been a perfect one for Let’s Encrypt.
Back in May 2016, the organisation let slip a login key for its GitHub account, where the source code used to run the service is hosted.
In theory, that meant anyone who’d noticed the leaked key could have logged in and made unauthorised changes deep inside the codebase, undermining the trust in the community that has sprung up around the project.
A security breach, even a potential breach that fortunately never happened in real life, is never a happy moment.
But the Let’s Encrypt team responded quickly and openly, and concluded:
Our investigation has concluded, and with GitHub’s help we’ve determined that the leaked credentials were never improperly used. No code was improperly modified, and no subscriber or other confidential information (aside from the leaked API key) was exposed.
A good outcome under the circumstances.
Another security SNAFU
This weekend, Let’s Encrypt had another security SNAFU, this time involving leaked email addresses.
To be fair, leaking email addresses, for example by CCing people when you meant to BCC them, isn’t the end of the world, but it’s still something best avoided.
Spreading big email lists to very many recipients isn’t just a breach of privacy, it’s also a potential gold-mine for spammers.
Malware on any one of the computers that received the list could scoop up those addresses and “call home” to deliver them to the crooks, perhaps leading to yet more spam for the innocent names in the list.
What happened with Let’s Encrypt was nearly, but not quite, amusing:
- The first person received an email containing the message body.
- The second person received an email containing the first person’s address plus the message.
- The third person got the first two addresses plus the message.
And so on.
If Let’s Encrypt hadn’t noticed early on, the last person would have received 382,999 addresses plus the message.
The good news is that the glitch was noticed after 7618 messages and the plug was pulled on the process.
1+2+3+4+5...+N comes out as
N/2 × (N+1), which is
(N2 + N)/2, which grows quadratically with
N (i.e. “as its square”).
Let’s Encrypt may have spotted them problem because this sort of quadratic growth in the total volume of email going out is rather unusual.
Ironically, perhaps, the email was to tell subscribers about an update to the subscriber agreement.
As the organisation said:
We take our relationship with our users very seriously and apologize for the error. We will be doing a thorough postmortem to determine exactly how this happened and how we can prevent something like this from happening again. We will update this incident report with our conclusions.
If you received one of these emails we ask that you not post lists of email addresses publicly.
The silver linings are that the problem was stopped early on, and that Let’s Encrypt’s apology carries some weight.
They’ve promised to report how the mistake happened, and how to stop it in future, which is actually both open…
…and useful, because we can all learn from other people’s mistakes.
Security tip. An email gateway with some form of DLP, short for data leakage prevention, can help in cases like this. For example, using the Sophos Secure Email Gateway, you can use what we call content control lists to set a rule such as “no outbound email should have more than 10 plaintext email addresses” (or any credit card numbers at all, and so on). This limits the damage done if a user copies-and-pastes the wrong data, or an automated script goes haywire.
One comment on “Let’s Encrypt accidentally shares user email addresses”
Cryptography is not difficult but key and certificate management and their associated infrastructures (i.e. PKI) and trust schemes can be a challenge for individuals to use effectively.
The first issue for users is to maintain the list of “trusted” Certification Authorities’ Certificates on their devices through the tools (normally) provided by the operating system. So better certificate management tools should be made available to users together with some clear educational material, particularly on the deletion of CA Certificates from unknown sources, e.g. Test Root CA Certificate.
The second issue is really down to application providers to implement applications that use the certificates stored on a users’ devices correctly. Again, education to has a leading role to play.
Thirdly, the source of CA Certificates itself should facilitate an authenticity check, e.g. Regulation (EU) N°910/2014 on electronic identification and trust services for electronic transactions in the internal market.
Fourthly, users are generally unaware of the financial limitations and other restrictions imposed by CAs or Trust Services providers. When was the last time you checked the Certificate Policy relating to a certificate and the CA’s Certification Practices Statement?
Lastly, there is no such a thing as a free lunch, there are costs, e.g. for certificates, utilities etc, (as well as benefits) to using the cloud.
There is still a long way to go……….