Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Encrypt: How It Works

letsencrypt.org

Post reply on HN
Print view View original

101–110 of 123 posts

Re: Let's Encrypt: How It Works

#101

Post by angry_octet »

bifurcation wrote: post #84
angry_octet wrote: post #83

Can someone clarify whether LE will check if there is already a signed SSL cert for the domain, and it contains the same information? For example, via the SSL Observatory? Doing this would prevent a point in time vulnerability in DNS (temporary mitm showing a different IP for the domain) or direct mitm of the connection to the webserver. Otherwise the attacker could get a signed cert for https://peacenik.org , and th…

Yes, we plan to apply a few mitigations of this type. Part of the idea of the "Proof of Possession of a Prior Key" challenge is so that if a web server requests a cert for a domain with an existing certificate, we can ask them to prove that they hold that certificate. https://github.com/letsencrypt/acme-spec/blob/master/draft-b...

Also, it seems possible that large scale DOS could be performed by applying for domains (via DNS hijack) before the owners do, causing significant administrative burden to recover from. I would suggest allowing simpler revocations within some multiple of the DNS TTL value for the domain.

I can also envision unscrupulous registrars pre-applying for LE certs for a fee, like $5.99 per month, and being very tardy and uncooperative about relinquishing control.

Re: Let's Encrypt: How It Works

#102

Post by angry_octet »

iancarroll wrote: post #94
bifurcation wrote: post #84

Earlier quoted context omitted.

Yes, we plan to apply a few mitigations of this type. Part of the idea of the "Proof of Possession of a Prior Key" challenge is so that if a web server requests a cert for a domain with an existing certificate, we can ask them to prove that they hold that certificate. https://github.com/letsencrypt/acme-spec/blob/master/draft-b...

This is a horrible idea... I have numerous certs for my domain and collecting them all to prove to you I own them is not going to be fun.

You wouldn't be in a very good position to revoke them then, would you? For example, if we had another heartbleed.

Re: Let's Encrypt: How It Works

#103

Post by makomk »

mappu wrote: post #66
Wilya wrote: post #4

Earlier quoted context omitted.

Ownership verification is already done via DNS by existing CAs. If an attacker has full control over your DNS, he can already change the DNS records and trick a CA into delivering him a genuine certificate. This isn't really a MITM attack.

What existing CA's offer this? The ones i've used (godaddy, startssl, namecheap/ssls.com rapidssl/positivessl) all wanted email verification iirc. EDIT: of course that's equivalent to verifying the MX. Never mind!

Email verification is worse - not only can it be attacked by modifying DNS, even a passive eavesdropper can generally get enough information to verify successfully.

Re: Let's Encrypt: How It Works

#104

Post by dredmorbius »

mappu wrote: post #68
schoen wrote: post #39

Earlier quoted context omitted.

We are actually hoping to have packages shipping from the official OS repositories, so you won't even have to get the package from us. (If anyone wants to help with this aspect, please get in touch.)

Is it possible to get new packages into Jessie post-freeze?

Generally not into the Debian repos, though it's possible the release manage could approve it.

You can pin other releases for specific packages, though, and if this is well-designed it should have minimal other dependencies. Ideally it's simply requesting and installing a key.

Re: Let's Encrypt: How It Works

#106

Post by kxo »

tedunangst wrote: post #12
silverwind wrote: post #9

Earlier quoted context omitted.

This really isn't a problem any more with SNI. With XP dying out, there's really no excuse anymore to not use it for shared hosting.

Python 2.7 (no SNI support) is the new Windows XP. Not a browser problem, but if you're building an API, it will lock people out. (sorry to beat a dead horse, but it's burned me recently and I think people are flipping the https only switch without awareness or consideration. doesn't mean "don't switch", but be aware.)

Are you unable to throw any number of the faster, event-driven webservers/reverse proxies in front of Python 2.7 to satisfy your SNI needs?

Re: Let's Encrypt: How It Works

#107

Post by kxo »

organsnyder wrote: post #61
schoen wrote: post #42

Earlier quoted context omitted.

There won't be any sort of requirement to allow our tools to run automatically. But the existing track record of expiring certs suggest that some people are having trouble remembering to do the renewals manually, so it may be useful to have a tool that does it automatically for people who want that.

The vast majority of sites fall into the category of "encryption would be nice, but not worth the time." All of my hobby sites (various forums, a site for my choir, etc.) fall into that category. Automagic TLS done right is an improvement from no TLS, IMHO, even if it comes with its own new set of potential attack vectors.

> Automagic TLS done right is an improvement from no TLS, IMHO, even if it comes with its own new set of potential attack vectors.

Is it really? Does it not potentially provide a false sense of security?

Re: Let's Encrypt: How It Works

#109

Post by ultramancool »

josho wrote: post #81
ultramancool wrote: post #79

Earlier quoted context omitted.

It's very, very hard for traditional CAs to compete with free, trusted in all major platforms and with dead simple set up. Hopefully this sort of scheme, combined with the added trust of Certificate Transparency, can kill off most traditional CAs. The only reason I would still buy 1 certificate is for wildcard support.

Wait. Where can I get free certs today? Or did you mean once this service goes live? I've used StartSSL, but somehow messed up the process and can't issue a new cert unless I pay to revoke the current. Even then their free certs expire in a year. The only other free cert I found was from Comodo, but it expires after 90 days. So, I wouldn't exactly say the only reason to pay for a cert is for wildcard support.

Yes, I was saying once this service goes live. But currently I've had 0 issues with StartSSL including renewals and getting multiple certs for a single domain. You do not need to revoke to get more certs from it in my experience at least. Paying for certs is just generally pointless right now even.

Re: Let's Encrypt: How It Works

#110

Post by xorcist »

Animats wrote: post #13

Keep track of when your certificate is going to expire, and automatically renew it. Or, all you have to do is let this new piece of software run periodically on your secure server. What could possibly go wrong?

You're probably already doing something similar if you use OCSP stapling.

It needs to run continously for revocation purposes but8

Post reply on HN