Thousands of Email Addresses Accidentally Disclosed By Let's Encrypt (letsencrypt.org) 81
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 (Score:2)
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?
Re: (Score:2)
Wasn't ACME partly about making renewing certs automatic?
Re: (Score:1)
Wasn't ACME partly about making renewing certs automatic?
No, it was a company that sold absolutely anything and everything to Wile E. Coyote. The executives of this company were very smart and truly understood their market. That's why they never offered to sell raw or cooked road runners, nor any other poultry, to said coyote. To do that would destroy their much more lucrative crazy gadget market.
Re: (Score:2)
Yes, but because it's all new (and people don't trust the tooling yet) they allow you to specify an e-mail address.
SSL scam (Score:2)
Re: (Score:2)
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... [letsencrypt.org]
Manual renewal is a bad habit.
Re: (Score:1)
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
Re: (Score:2)
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).
Re: (Score:1)
Yikes. Ninety days? Having such a short expiration period weakens security in at least a couple of ways:
Re:Why the heck (Score:5, Informative)
Additionally, Let's Encrypt WANTS to make certificate renewal an automated process, and short expirations force users to do that like you said. There should be no reason to "think about the cert creation process" because CAs should never issue you a certificate with a cipher or key length that is not secure. The idea that web site administrators should all be up on the cutting edge of cryptographic attacks is pretty crazy actually. Standards should be enforced at the bottlenecks (in this case CAs) so that as few fuck ups as possible can happen.
Re: (Score:1)
If Let's Encrypt refuses to grant any certificates longer than 90 days then your credentials are actually NOT as valuable as they would be otherwise.
Really? Is this what we've become? We expect that systems are that insecure that they can't say unhacked for longer than 90 days?
Sorry, but 90 days is just stupid and expecting everyone to just trust this to a script is just silly.
Lets really get to the point of what LE is all about - people who have no idea of security - but it lets them get this green padlock in their browser (even though its probably SSLv3 by default).
Re: (Score:3)
Re: (Score:2)
This is where I realize you don't know what you're talking about because SSLv3 has been disabled in modern browsers for 2 years now. Have a good day with your uninformed, knee-jerk opinions.
So you're going to tell a guy with a 5 digit slashdot ID that SSLv3 problems don't exist because the browser disabled it?
You realise that unless you disable it *ON THE SERVER* it is still offered, right?
Re: (Score:2)
Re: (Score:2)
IF you're hacked, you want to minimize the damage.
Re: (Score:1)
No sane person is going to be willing to babysit a cert upgrade four times a year.
That's the point. They want to strongly discourage babysitting cert upgrades. They only want to support automatic upgrades. They would like to make the period as short as possible.
Re: (Score:2)
And my point is that it isn't their place to discourage sysadmins from monitoring their server cert upgrades. It's fine for them to encourage the various web servers to make the automatic upgrades easy so that people with no experience have an easier time, but it is crossing a line to insist that we shouldn't be allowed to be cautious.
Re: (Score:2)
So be cautious. Babysit your certificate upgrades if you really can't get it together enough to automate them. Clearly babysitting certificate upgrades is not scalable, and is prone to introducing errors. No one will stop you from being overly paranoid and under performing.
Re: (Score:2)
Fun fact: All the big players use short-lived servers. They deploy things to cloud servers frequently, un-deploy them frequently, and they run their own CAs. That's great if you're a giant cloud provider. After all, if one of those servers fails to come up because of a re-cert, the server transparently fails over to another server, and as long as the configuration doesn't propagate too far, there's no impact on anything.
That's completely differen
Re: (Score:2)
I can get free 1-year certs from StartSSL, so why in the world does anybody even use those?
And I'll keep mentioning StartAPI every time this BS about Lets Encrypt comes out - and point to my implementation of it in perl: https://github.com/CRCinAU/sta... [github.com]
It takes 90% of the pain out of SSL renewals.
Re: (Score:2)
> Having such a short expiration period weakens security
This is bullshit. Google uses very short lived certificates for many of its services.
google.com right now (seen from here):
begin: 06/01/2016
end: 08/24/2016
Re: (Score:2)
its optional for access recovery (revocing certs when you lost your access key) and notification mails about certs about to expire (to see if your automatic renewal failed).
This, from a "security" organization? (Score:1)
I guess this demonstrates how seriously they take security. I wonder how they protect their root keys.
I'm worried how it's being brushed off at HN! (Score:3, Insightful)
I first learned about this awful incident at Hacker News [ycombinator.com].
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 [reddit.com]:
and
Re: (Score:1, Insightful)
To make matters worse I'm seeing comments from people pointing out that this is not acceptable getting downvoted!
Yes, the generic term for this phenomenon is "echo chamber". The same thing happens here at Slashdot if you say certain things that are unpopular and back them up with solid evidence so they can't easily be hand-waved away. It's just the way small minded people react at the point where they should say "I was mistaken".
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.
Speaking of small minded people, they generally look at particulars and not at principles. So it's all insignificant until they personally get hurt by it. When it's a SSN or a bank account
Re: (Score:2)
It's a remote possibility that somebody used a unique email that encodes some important information in the address. But such people are their own enemies.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:3)
AC, you are spectacularly bad at composing analogies.
Re: (Score:2)
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?
Re: (Score:2)
You are not a zener diode.
Re: (Score:3)
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 on
Re: (Score:2)
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. Th
Re: (Score:2)
Re: (Score:2)
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 reas
Re: (Score:2)
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.
Re: (Score:2)
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.
Sooo... (Score:2)
Re: (Score:2)
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 wo
Re: (Score:2)
Re: (Score:2)
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.
Amateur-level scripting (Score:2)
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.
Re: (Score:2)
Who needs test management, right? I mean, if your code is always *awesome*, why throw money down the well! :-)
Test management is and always has been an uphill battle. You have to be constantly proving yourself and telling the management how this-and-that bug saved the company a $100K+ down the road. Quality has this funny trait of being rather invisible when it's present and people only really notice it when it's not there.
Re: (Score:2)
More like "who needs tests" in this case. Test management is a bit overblown for a simple small script. (At least that is what I would use. And I would send it out via a relay and check what is in the queue before activating that relay. Of course, I may just be overly cautious.)
You do have a point of course. Skimping on testing, test management and developer skills is about as stupid as if firing the sysadmins because "everything is working well".
Re: (Score:2)
nothing happened, which couldn't happen for other CAs as well.
Re: (Score:2)
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.
In other news (Score:2)
In other news, "Let's Encrypt" has changed their name to "Let's Disclose".