Slashdot Mirror
Thousands of Email Addresses Accidentally Disclosed By Let's Encrypt (letsencrypt.org)
An anonymous reader writes "Let's Encrypt, the certificate authority best known for offering free SSL/TLS certificates, has reported that it accidentally disclosed thousands of user email addresses due to a bug with an automated emailing system." Executive Director Josh Aas posted this announcement:
On June 11 2016 (UTC), we started sending an email to all active subscribers who provided an email address, informing them of an update to our subscriber agreement. This was done via an automated system which contained a bug that mistakenly prepended between 0 and 7,618 other email addresses to the body of the email... The problem was noticed and the system was stopped after 7,618 out of approximately 383,000 emails (1.9%) were sent. Each email mistakenly contained the email addresses from the emails sent prior to it, so earlier emails contained fewer addresses than later ones.
We take our relationship with our users very seriously and apologize for the error... If you received one of these emails we ask that you not post lists of email addresses publicly.
We take our relationship with our users very seriously and apologize for the error... If you received one of these emails we ask that you not post lists of email addresses publicly.
Why the heck do they actually require to store e-mail addresses the first place? ACME works with public keys and cryptography, no? Or was it the email addresses for some forum or something, unrelated from the core service?
I guess this demonstrates how seriously they take security. I wonder how they protect their root keys.
I first learned about this awful incident at Hacker News.
What scares me the most is some of the responses there which just brush it off as no big deal! There are comments there like:
and
and
The responses are just about as bad over at reddit:
and
To make matters worse I'm seeing comments from people pointing out that this is not acceptable getting downvoted!
It scares the living hell out me that people can think that somehow this incident was acceptable or excusable, especially when it was an organization that has to put security, privacy and trust paramount that was responsible.
This incident was not acceptable. It should be considered a total disaster.
Damn, but you're mad about this 100% free service!
The install script doesn't stay resident or seize resources from your server. It performs the automated confirmation that you're the owner of the website you're applying for. You actually don't have to use it, but you'd have a lot of work on your hands otherwise.
I use Let's Encrypt certs and couldn't be happier. The only problems I've had with it are where I link to content on my servers, and the forum/host that I wanted it to appear on is unable to fetch it. In the long run, that's an added bonus since I've had problems with hotlink abuse anyway.
The process of dealing with certificates was shitty to begin with, but at least I figured it out already and it's relatively simple, now I'm forced to deal with another layer of crap on top of that?
In fact they've tried to make it easier. Most people just want to get the job done, nothing more. The "layer" of crap removes one big problem with SSL certificates: manual renewal. Usually you have to renew certificates manually, but with the program from Let's Encrypt, this happens automatically.
Maybe in the future this is even built into the HTTP servers, so that you don't have to install third party software. Its all just checking whether the cert is expired, and running the ACME protocol to get a new one automatically.
Only the default "press and go" option actually sucks in your Apache configs, finds all the domains, makes certs for them all, then plugs those certs back into your Apache config. That's the "dumb user" mode.
You can have it just create the certs you specify for you, save them into a given location, and just put the command that does that into, say, a cron job or do it manually.
Same utility, different command line parameters.
No good deed goes unpunished? Sounds about right... sadly.
This is a basic coding mistake made worse by a set of basic testing mistakes. The state of practical IT is truly amazingly bad when mistakes like these are made routinely. Does not instill any confidence in this specific group of people either.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I think you get it correctly, but do the way browsers are build you need a valid not-self signed certificate and Lets encrypt do exactly that... If you get hacked or have your system not working your certificate will expired after 90 days limited the problem of a forgotten certificate (for instance if you switch server). I'm a user for Lets Encrypts and as my existing certificate expired I'm replacing them all with this awesome services.
That's downright terrifying to me. I've had at least a few situations where a seemingly innocuous cert upgrade went horribly wrong and I had to roll back to a previous configuration to get back up and running. The last thing I want is for that process to be fully automated. There's a reason I don't automate my TLS cert upgrades, and it isn't because it isn't easy to do. It is because if anything goes wrong, I want to be abso-freaking-lutely sure that I'm right there beside the machine when it fails so that I can fix the problem quickly.
Check out my sci-fi/humor trilogy at PatriotsBooks.
I agree, having a centralized repository is bad, but what is even worse is what we are currently having: hundreds of CAs world-wide being able to sign certs for any domain in the planet without any oversight.
So while it is a good reflex to be upset about something centralized, in the case of CAs its the opposite: the more CAs you trust, the bigger the chance that one of them sold a signing cert to some shady country or something.
Yes, a system where multiple entities have to agree before giving out a cert would help the system alot.
Your criticism of "free" looks misplaced. Handing out certificates barely require any manual intervention, nor any resources (if you disregard for the server costs). So its only straightforward to make obtaining them free.
In the case of these people, it's to pretend that you need them WAY more than you actually do.
Not really. There are multiple reasons why long term certs are bad: https://letsencrypt.org/2015/1...
Manual renewal is a bad habit.
But ideally that process should not be volatile. If it is that is a whole other issue. That is like saying I don't want my website to automatically respond to HTTP requests, what if it makes a mistake? I have to be sitting next to it in case that happens.
Let's Encrypt also participates in certificate transparency programs. Every certificate that it issues is put in a public log so if you ever encounter one signed by them you can verify that it is on there. On the other side, site owners can verify that all the certificates they asked for are on there and no extra ones for any sites they own. If enough people audit this, then maliciously granted certificates would be discovered and there would be indisputable proof that something bad was happening. Google Chrome automatically does some of this auditing whenever you visit an HTTPS site I believe, so it would be pretty difficult to get away with anything more impactful than an extremely targeted (toward only a handful of users) bogus certificate attack.
Try sourcing something that isn't also Mozilla and isn't gathering TLS stats from a single browser (gasp, Firefox!).
Automatic renewal opens yourself up to bugs like TFA and MitM attacks, among other possibilities. Manual renewal can suffer from similar problems, but the difference is that a human is in the driver's seat and has the ability to assess the situation. Trusting an automated system to be secure is asking for trouble. This is all discounting the fact that the certificate authority model is broken to begin with.
AC, you are spectacularly bad at composing analogies.
AC, you are spectacularly bad at composing analogies.
Really. He didn't even mention your car. How can you have an analogy without a car?
If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
You are not a zener diode.
In other news, "Let's Encrypt" has changed their name to "Let's Disclose".
Just cruising through this digital world at 33 1/3 rpm...
And even if, you still have to trust the certificate log.
The only real way to be sure your domain is yours is by getting your cert pinned by google and shipped in the browsers.
The last thing I want is for that process to be fully automated.
I agree, but there's nothing about Let's Encrypt that forces you to do everything in an automated manner. The certbot client offers various levels of automation; there are other clients that probably have similar options. I choose to automate issuance/retrieval of the certificates only, and then install them into Apache manually. I also run the renewal process manually instead of having cron do it. There's a --dry-run option when using the command line that will identify potential problems. If for some reason a rollback is necessary, I'm already in the shell and the old certs are sitting in /etc/letsencrypt/archive/.
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
If you received an email from Let's Encrypt yesterday that had other peoples' email addresses prepended to the message, you were affected. If you didn't get such an email, your address wasn't leaked.
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
If you really want to make self signed default, as encrypted but not signed is better than nothing, you do not need certs for the default case. Just encrypt and use certs when you need to certify something (like an identity or a domain ownership for the ip owner).
even with the official tool it's easy without touching your webserver. /var/www/ -d yourdomain /etc/letsencrypt/live/yourdomain/fullchain.pem
letsencrypt certonly --webroot --webroot-path
and then point your webserver to
you may even generate your own csr, which allows you to keep the key instead of generating a new one for each certificate. If you see a point in keeping the key (maybe when your use HPKP?)
Probably there is some cmdline option to keep the first key generated as well. would need to look it up.
nothing happened, which couldn't happen for other CAs as well.