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.

Comments

Why the heck

[NotInHere]

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:Why the heck

[Anonymous Coward]

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?

SSL Certs are good for 90 days. You get emails telling you when your certs are about to expire so you can renew them if needed.

Re:Why the heck

[NotInHere]

Wasn't ACME partly about making renewing certs automatic?

Re:Why the heck

[Anonymous Coward]

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:Why the heck

[Lennie]

Yes, but because it's all new (and people don't trust the tooling yet) they allow you to specify an e-mail address.

Re:Why the heck

[Anonymous Coward]

I believe they email addresses are so they can warn you when your certificates are about to expire, in case your scripts are broken.

Re:Why the heck

[Anonymous Coward]

Wasn't ACME partly about making renewing certs automatic?

No, it was a company that sold absolutely anything and everything to Wile E. Coyote.

According to the SEC fillings, the CEO of ACME was a Mr. R. Runner, who apparently directed the engineers to insure that all products would fail spectacularly. Beeb, Beeb.

Re:Why the heck

[dgatwood]

SSL Certs are good for 90 days. You get emails telling you when your certs are about to expire so you can renew them if needed.

Yikes. Ninety days? Having such a short expiration period weakens security in at least a couple of ways:

• No sane person is going to be willing to babysit a cert upgrade four times a year. I've seriously considered paying hundreds of dollars for certs instead of using free certs because once per year is annoying as h***, much less four times. Therefore, everyone will store their Let's Encrypt creds on the servers themselves, making them a juicier target than they otherwise would be, because crackers can swipe those creds and create certs in the site owner's name (for other arbitrary sites).
• If certs are automatically regenerated, site owners will stop thinking about the cert creation process, and thus won't periodically upgrade their keys as new weaknesses are found (unless forced to do so).

In short, what the f*** were they thinking?

I've read their statement on the subject, which claims that 90-day certs are the most common length on the web. That's true, but only because there are a whole lot of companies who give away free certs, but limit the duration to 90 days in the hopes that it will drive people to pay money for longer certs. The reality is that 100% of the certs that people pay for are a year or longer. And for that matter, I can get free 1-year certs from StartSSL, so why in the world does anybody even use those? I don't get it....

And there's also one huge problem with that scheme, which is the use of shared servers. If you're using a shared hosting provider and fifty people upgrade their SSL certs once a year, you have 50 server restarts per year for a total of probably three or four hours of downtime. If they upgrade their certs more than four times per year, that's almost a day of downtime annually, unless the ISP forcibly upgrades everybody's certs all at once, but that would mean giving your ISP the credentials to log in for you, which represents an even bigger security risk.

So even if I didn't have this latest security incident as a reason, I still wouldn't touch Let's Encrypt with a ten-meter pole....

Re:Why the heck

[cryptizard]

Modern web servers support hot swapping certificates so downtime is not usually an issue. The most important reason for short expirations is that certificates with short expiration times are more secure against attackers that might be able to steal your certificate. A cert that is valid for a year will be much more valuable than one which expires in 90 days. The same holds true even for the Let's Encrypt credentials themselves. 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. They also participate in public certificate transparency logs so it is easy to detect a situation where someone gets another certificate issued for your site.

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:Why the heck

[Anonymous Coward]

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:Why the heck

[Anonymous Coward]

Fun fact: All the big players use short-lived certificates.

Go visit google now, and check the certificate sent over. It's typically got less than 90 days on it when issued, and sometimes less than 30 days.

Once upon a time the "certs that people pay for" lasted up to 10 years. That stopped. Can you guess why? You're probably thinking "So they could charge a lot more money" right? Nope. Because hardly any of those 10 year certificates remained in use after just FIVE years. Most of the 10 years certs (some of them are still valid today) just got erased, or left on a PC that was sold second hand, and nobody knows where they are today. But they're still valid. They represent an ongoing security risk for TEN YEARS. Ouch.

The CA/B which effectively sets the basic rules for certificates on the web now, decided on 3 years (actually 39 months) and is considering restricting to 2 years (27 months) as the _absolute maximums_ and only because manual issuance means it's such a pain to do all this stuff.

For your own safety, 90 days is a much better choice, the only problem before Let's Encrypt was that it's a bunch of manual effort. Let's Encrypt is getting rid of that effort.

Re:Why the heck

[CRC'99]

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:Why the heck

[CRC'99]

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...

It takes 90% of the pain out of SSL renewals.

Re:Why the heck

[cryptizard]

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.

Re:Why the heck

[CRC'99]

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:Why the heck

[Anonymous Coward]

Go visit google now, and check the certificate sent over.

They can do this because they are their own certificate authority. Everything google serves over TLS is self-signed, but the browsers do not complain about with big red warnings, because, google.

90 day certs that are cannot be used on a shared server are effectively useless for the majority of the internet.

And, as we have seen, encryption is pretty much useless anyway. The people who we need to secure information from have complete access no matter what you do.

Unencrypted web traffic is more secure at this point.

Re:Why the heck

[cryptizard]

Appeal to slashdot ID, haven't heard that one before lol. Who cares what the server supports if the clients don't allow it? All the client has to know is if they see the green lock (as you said) then their communications are secure. It would only matter if the client is using an extremely old browser, in which case SSLv3 is probably the least of your worries considering the huge number of unpatched security vulnerabilities you probably have going on. So yes, I am going to tell you that SSLv3 problems do not exist for the vast majority of people.

Re: Why the heck

[Anonymous Coward]

If only you said, "beep, beep".

Re:Why the heck

[dgatwood]

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:Why the heck

[dgatwood]

Fun fact: All the big players use short-lived certificates.

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 different from the types of users who are in the market for a free certificate provider. Those folks usually have only a single server that has to "just work". Every extra bit of automation adds risk. Every configuration change is a risk. That risk is much higher because their services are not massively distributed. For them, limiting the rate of change is more important than the infinitesimal risk of someone compromising their server, stealing their key, and using it to impersonate their hobby server.

So no, 90 days is not a better choice. It is just a choice. You're trading higher risk of something going wrong during re-certing against a shorter period of vulnerability for clients that don't support OCSP and are actively being attacked by someone who successfully compromised your server at some point in the recent past, up until the end of that cert's validity window. IMO, the decision of certificate length should be entirely in the hands of the site admins, not forced upon them by a heavy-handed certificate authority.

Once upon a time the "certs that people pay for" lasted up to 10 years. That stopped. Can you guess why? You're probably thinking "So they could charge a lot more money" right? Nope. Because hardly any of those 10 year certificates remained in use after just FIVE years.

That's in large part because most companies don't keep servers running that long. Heck, a statistical majority of companies aren't around that long. This is not the case for personal servers, of course, but they were historically never secured with HTTPS because of the cost. That critical difference makes any statistics from that period wholly invalid when determining proper lengths for certs in this day and age.

Also, folks periodically find weaknesses in crypto technology that requires you to rekey your servers. For this reason, periods should be long enough to not be annoying, but short enough that people have to manually intervene every two or three years, to ensure that sysadmins realize that their keys are no longer strong enough and upgrade things accordingly. IMO, automated upgrades actively hinder security by making the process "out of sight, out of mind". Whether that difference matters or not remains to be seen, but it is at least cause for concern.

Re:Why the heck

[allo]

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).

Re:Why the heck

[allo]

> 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:Why the heck

[allo]

IF you're hacked, you want to minimize the damage.

Re:Why the heck

[dave420]

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.

This, from a "security" organization?

[Anonymous Coward]

I guess this demonstrates how seriously they take security. I wonder how they protect their root keys.

Re:This, from a "security" organization?

[Anonymous Coward]

I always give my root keys to the guy sending out my newsletters. Always.

Re:This, from a "security" organization?

[Anonymous Coward]

They have an installation script that, without asking you (!!), tries to install a compiler on your server...
Seriously, what do you expect from people doing something like that?

I wanted to believe

[Anonymous Coward]

When I first heard about Let's Encrypt, I thought it was a great idea so I looked further into the process of getting a certificate from them.

The whole thing seems to be oriented around downloading some "helper" program that rewrites your webserver config files for you (if you're using a common, generic Linux distribution of course). If you don't fall into the common case, their documentation boils down to "run this shell script downloaded from GitHub". WTF? 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?

Considering that plus the ridiculously short expiration period, I decided that not wasting my time with amateur hour crap was worth paying for a commercial cert.

Certificate pinning with no central root makes way more sense security-wise than this ridiculous PKI rent-seeking scheme anyhow.

Re:I wanted to believe

[pepsikid]

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.

Re:I wanted to believe

[NotInHere]

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.

Re:I wanted to believe

[ledow]

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: I wanted to believe

[Anonymous Coward]

I use --standalone mode which makes the request locally and then I copy key/cert/chain to the servers.

Email addresses ARE public info. Just like your name, address, and phone number are (if you live in the U.S. anyway). By the way, your front porch is also considered "public space", even if you live in the woods.

Re:I wanted to believe

[Anonymous Coward]

When I first heard about Let's Encrypt, I thought it was a great idea so I looked further into the process of getting a certificate from them.

The whole thing seems to be oriented around downloading some "helper" program that rewrites your webserver config files for you (if you're using a common, generic Linux distribution of course). If you don't fall into the common case, their documentation boils down to "run this shell script downloaded from GitHub". WTF? 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?

Considering that plus the ridiculously short expiration period, I decided that not wasting my time with amateur hour crap was worth paying for a commercial cert.

Certificate pinning with no central root makes way more sense security-wise than this ridiculous PKI rent-seeking scheme anyhow.

You can use a service such as Kloudesec which handles certificate renewal on behalf of your website(s). It is free.

Re:I wanted to believe

[Anonymous Coward]

You don't have to let Let's Encrypt mess with your server at all, just give it a place to stick your 'proof of identity', and then make sure your web server exposes that location as '/.well-known'.

I have this in my Nginx configuration, it works fine:

ssl_certificate /etc/letsencrypt/live/whatever/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/whatever/privkey.pem;

location /.well-known {
    root /some-place-writable-by-certbot-and-readable-by-nginx;
}

Then you just stick something like certbot renew && killall nginx -HUP in your crontab and you're done.

Re:I wanted to believe

[dgatwood]

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.

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.

Re:I wanted to believe

[cryptizard]

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.

Re:I wanted to believe

[Anonymous Coward]

So if I promise to take care of your house for free while you're on vacation and then screw it up, you won't get mad? That's very decent of you.

Re:I wanted to believe

[pepsikid]

AC, you are spectacularly bad at composing analogies.

Re:I wanted to believe

[I'm New Around Here]

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:I wanted to believe

[pepsikid]

You are not a zener diode.

Re:I wanted to believe

[ShaunC]

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/.

Re:I wanted to believe

[Anonymous Coward]

The moderation of your comment is an excellent demonstration of what is wrong with the slashdot campingcensorshill system.

Re: I wanted to believe

[Anonymous Coward]

Where are you referring to that someone's front door, on privately owned property, is "public space"?

Re:I wanted to believe

[allo]

even with the official tool it's easy without touching your webserver.
letsencrypt certonly --webroot --webroot-path /var/www/ -d yourdomain
and then point your webserver to /etc/letsencrypt/live/yourdomain/fullchain.pem

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.

I'm worried how it's being brushed off at HN!

[Anonymous Coward]

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:

It sucks this happened but I don't really care.

and

Interesting. Slightly embarrassing. Not a huge deal. Handled well.

and

Things like this happens all the time. Give them a break.

The responses are just about as bad over at reddit:

Stupid bug, but the consequences of this bug is... nada. zip.

and

this is non-news, emails are public info

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.

Re:I'm worried how it's being brushed off at HN!

[Anonymous Coward]

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 number, and it happens to them, suddenly it matters and not a moment before. They don't seem to understand that security really matters at all times. Tolerating this kind of slack approach to security just encourages more of it and eventually it WILL be something a lot worse than e-mail addresses.

Re:I'm worried how it's being brushed off at HN!

[Cyberax]

Uhm... Why are they incorrect? It's not a total disaster - nothing is compromised except the email addresses. You know, the ones that are attached to any emails that you send out.

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:I'm worried how it's being brushed off at HN!

[Anonymous Coward]

Why wasn't it acceptable, hmm? You afraid your cert for your loli porn site might be tied back to your real name, Jacob?

Re:I'm worried how it's being brushed off at HN!

[sacrilicious]

Just so you know: when you post a sky-is-falling position about something that seems pretty harmless, and the org in question is one that's up-ending a long-standing cartel that's held the reigns on something tightly, and you don't give any expansion on why (according to you) it is such a catastrophe, AND you post as Anonymous Coward... well, it makes you look pretty likely to be a shill for the industry that's being up-ended. Just wanted you to know how it comes across.

Re: I'm worried how it's being brushed off at HN!

[Anonymous Coward]

"Uhm... Why are they incorrect? It's not a total disaster - nothing is compromised except the email addresses. You know, the ones that are attached to any emails that you send out."

The keyword here being "YOU". You sent it out. Having a third party pass around your email like a $2 whore is negligent and irresponsible.

Re: I'm worried how it's being brushed off at HN!

[Anonymous Coward]

To me, "acceptable" doesn't apply here, as it was an unintentional bug that was since fixed and not going to happen again. You can't change the past, and its not going to repeat.

If this was intentional or new policy, then sure, it's not acceptable.

And yes, it is excusable (read: forgivable), as it was a fucking email address, not credit card number or anything else of that nature.

Sooo...

[dejitaru]

No good deed goes unpunished? Sounds about right... sadly.

"Good deed goes unpunished"? What the fuck?!

[Anonymous Coward]

Just because a service or product is free it doesn't give the provider an excuse to fuck up like in this case!

This isn't just any organization. Security, privacy and trustworthiness should be among its primary focuses! It's inexcusable that they would screw up this badly by releasing information that otherwise should have been kept private.

I saw a link to some tweets where this Josh Aas guy apparently blames it on some Python library that Let's Encrypt apparently used improperly.

But what I don't get is why they didn't find this bug earlier. If they had done some test mailings to their own addresses then I would expect this to have been discovered right away. Are we to believe that they didn't do any testing of this before sending, in their words, "approximately 383,000 emails"?!

We need to ask, HOW THE FUCK COULD THIS HAVE HAPPENED?!

Re:"Good deed goes unpunished"? What the fuck?!

[Anonymous Coward]

But what I don't get is why they didn't find this bug earlier.

We all look forward to you contributing all your waking hours to the organization to make sure this is not repeated.

Re: "Good deed goes unpunished"? What the fuck?!

[Anonymous Coward]

No, we don't. Don't like them, don't use them. But I don't feel the need to get all butthurt over some email addresses. You sound like the guy that was crying in the Leroy Jenkins video. Calm the fuck down.

Re: "Good deed goes unpunished"? What the fuck?!

[Anonymous Coward]

So it's ok to lie that it's secure etc., and whenever they fuck up you'll come around the corner to their rescue? Sure.

But you fail to realize there's actually a lot of money behind this project. So go on now and crawl back under the nearest rock.

Re: "Good deed goes unpunished"? What the fuck?!

[Anonymous Coward]

Um, it's right in the summary - a bug in their bulk email software.

Probably they thought that they could write their own, because it's just email right? Well, lots of free and paid options for sending bulk email that they didn't need to rewrite.

They are amateurs... shouldn't trust their security software either since they probably thought they could do a good job at that too, and it's harder, and only a matter of time before that blows up. Don't be a customer when it does.

Because it's a scam

[Anonymous Coward]

SSL Certs are good for 90 days.

Nope. SSL certs (which provide encryption more or less reliably, and NOT identity, which is a total scam) are good for as long as you say they are. Scam SSL certs that are provided by, and tie you to, a "provider" and pretend to supply "identity" are, on the other hand, generally short term. In the case of scammers like verisign, it's to extort more money. In the case of these people, it's to pretend that you need them WAY more than you actually do.

SSL certs. Just make your own. They're free, and they SHOULD be free. Plus they can last years. Fuck the scammer's "warnings." Just teach the surfers that ALL they provide is encryption. Because that's the FUCKING TRUTH.

Re:Because it's a scam

[NotInHere]

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.

Re:Because it's a scam

[Anonymous Coward]

It is largely a scam, but not entirely. There is measurable value in the statement that

within the last 90 days, an external entity verified that the given public key corresponded to a private key held by someone who had control over a privileged port on the given hostname, and furthermore this statement has been released to the public so that if the legitimate owner of that hostname disagrees, they have the ability to request that this statement be rescinded, which has not happened as of 7 days ago.

It's not a strong statement of identity, but it is quite a lot better than nothing.

There is no such thing as encryption without authentication - whether via PKI, TOFU, web of trust, out-of-band verification, or just plain "I trust my ISP not to fuck with my connections", you must have some confidence that you have actually reached the party to whom you are speaking. And no single mechanism works for all situations.

Many people unfortunately have a tendency to think about these issues only from the point of view of the server operators. The needs of the users - the ones actually affected by the security of TLS and the PKI - are often ignored.

Or to put it another way: if you believe your relationship with your users is such that the PKI provides no benefit, then surely you could just exchange keys with each of them out of band, set up a VPN and forget about TLS entirely.

Re:Because it's a scam

[Anonymous Coward]

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.

Re: Because it's a scam

[Anonymous Coward]

What!? I sign my cert from the genuine Snake Oil Inc. Certificate Authority and have been fine for years.

Re:Because it's a scam

[allo]

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).

A centralized 'free' repository of certs

[Anonymous Coward]

Makes for a great surveillance tool. Can you say MITM ?

Re:A centralized 'free' repository of certs

[NotInHere]

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.

Re:A centralized 'free' repository of certs

[cryptizard]

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.

Re:A centralized 'free' repository of certs

[Anonymous Coward]

Every certificate that it issues is put in a public log

They tell you that. The reality is far murkier. You can't necessarily trust that every certificate they sign is in the public log. They do use a multi-level key structure and there may be second-level keys that they don't tell us about that are used to generate submarine signatures.

The only way to way to verify this is for every client to check the transparency log for every certificate that is sent to it.

Certificate in log: may or may not be false.
Certificate not in log: Submarine signature - report.

I believe Google does something like this in Chome by checking against their own copy of the log and forcefully requiring their own CA for their own domains, as you already said.

Re:A centralized 'free' repository of certs

[NotInHere]

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

[gweihir]

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:Amateur-level scripting

[Sax Russell 5449D29A]

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:Amateur-level scripting

[gweihir]

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".

SSL scam

[JcMorin]

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.

This is why automated solutions won't work

[Anonymous Coward]

Security is a practice, and automating the signing and serving of keys is a security disaster as it kicks out the human element. Others have wondered why I don't use LE. Aside from the 90-day cert lifespan (which is also stupid), this is another nail in the coffin.

Security needs more *accessible* tools, not more *automatic* ones.

Re:This is why automated solutions won't work

[allo]

nothing happened, which couldn't happen for other CAs as well.

How do I find....

[Anonymous Coward]

... out if my email address was one of the ones that leaked? I usually use a randomly generated one, but it it's one of the ones that leaked I'll be changing it on the next certificate renewal and discarding the address.

Spam is a bitch. Let-alone the (small?) possibility that the email address could (maybe?) be used to authenticate/verify against LetsEncrypt and (possibly?) revoke or alter my valid certs. I'm hoping that is not the case.

Re:How do I find....

[ShaunC]

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.

Let's Encrypt...

[Anonymous Coward]

But let us also leak information like a sieve!

Oops.

In other news

[JustAnotherOldGuy]

In other news, "Let's Encrypt" has changed their name to "Let's Disclose".

Re:In other news

[Anonymous Coward]

In other news, "Let's Encrypt" has changed their name to "Let's Disclose".

Still waiting for Fedbook (facebook.com) to get their backlash.

Use encryption. Spies hate encryption. Even versions of Tails newer than 1.4.1 are compromised. Ed Snowden did the spies a favor they just don't know it yet.

Who wrote the script?

[Anonymous Coward]

Are the authors of the email script the same authors of the script that runs on your server to set up your configs?