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

21–30 of 123 posts

Re: Let's Encrypt: How It Works

#21

Post by tedunangst »

Unfortunate choice of wording. From the web page:

> Obtain a browser-trusted certificate and set it up on your web server

From the "RFC" on github:

> In the background, the web server contacts the CA and uses ACME to request that a certificate be issued for the intended domain name(s).

> Once the CA is satisfied, the certificate is issued and the web server automatically downloads and installs it, potentially notifying the operator via e-mail, SMS, etc.

This really sounds like they are generating the key pair, not just signing it. I think (hope) that's not the case, but clarity on this issue is pretty important.

Re: Let's Encrypt: How It Works

#22

Post by cmwright »

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

Was surprised by this so just did a little research. It appears (https://stackoverflow.com/questions/18578439/using-requests-... , http://docs.python-requests.org/en/latest/community/faq/#wha...) that this is fixable in python 2.7 so not a show stopper, more of just a good to know.

Re: Let's Encrypt: How It Works

#23

Post by sp332 »

cmwright wrote: post #8
haroldp wrote: post #7

It seems like the one thing this doesn't/can't address is the IP shortage. Does help much if example.com is virtual hosted on the same IP address as 100 other sites?

The SNI stuff ( http://en.wikipedia.org/wiki/Server_Name_Indication ) helps with this if you can do without XP support.

It's not really XP that's the problem, but IE6. Firefox and Chrome support SNI even if you run them on XP.

Re: Let's Encrypt: How It Works

#25

Post by tedunangst »

cmwright wrote: post #22
tedunangst wrote: post #12

Earlier quoted context omitted.

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

Was surprised by this so just did a little research. It appears ( https://stackoverflow.com/questions/18578439/using-requests-... , http://docs.python-requests.org/en/latest/community/faq/#wha... ) that this is fixable in python 2.7 so not a show stopper, more of just a good to know.

Note that many people don't use requests, which has a rather large dependency chain, and sometimes you don't have much choice. e.g., feedparser doesn't use requests, nor is it likely to because of the dependencies. PEP 466 https://www.python.org/dev/peps/pep-0466 has more information, too.

Re: Let's Encrypt: How It Works

#26

Post by Supermighty »

aeden wrote: post #16
Simucal wrote: post #10

What kind of impact is Let's Encrypt going to have on the CA industry? I'm not that familiar with the current state of the CA companies, nor do I understand this industry well enough to know if this is going to be a major hit to them or not. Is there any reason why a company would prefer a CA other than Let's Encrypt?

The impact depends largely on their ability to get their root certificate into all of the browsers. It'll be interesting to see what happens with older versions of browsers as well, since if they start with a brand new root certificate then I'm not sure what happens with the older browsers. If they can get their certificate into all of the browsers then it's possible they could achieve broad adoption for domain-verif…

> since if they start with a brand new root certificate then I'm not sure what happens with the older browsers.

IdenTrust will cross-sign Let's Encrypt root cert. I imagine they will keep it cross-signed, for backwards compatibility, once LE has their root cert in all the browsers.

Re: Let's Encrypt: How It Works

#27

Post by CGamesPlay »

tedunangst wrote: post #21

Unfortunate choice of wording. From the web page: > Obtain a browser-trusted certificate and set it up on your web server From the "RFC" on github: > In the background, the web server contacts the CA and uses ACME to request that a certificate be issued for the intended domain name(s). > Once the CA is satisfied, the certificate is issued and the web server automatically downloads and installs it, potentially notifyi…

The technical overview [1] shows that the private key is on your server and never leaves it.

[1] https://letsencrypt.org/howitworks/technology/

Re: Let's Encrypt: How It Works

#29

Post by slasaus »

Wilya wrote: post #4
radiospiel wrote: post #2

I am somewhat excited about letsencrypt, but isn't ownership verification via DNS not a bit, hmm, strange? After all, a proper certificate should defend against MITM attacks; so if an attacker would be able to take control over the target's DNS, he could easily create a certificate, which looks legit for all intended purposes. Or do I miss something in that regard?

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.

"If an attacker has full control over your DNS"

Shouldn't this be "over the CAs DNS resolver"?

/edit

well I guess if the attacker has control over your dns server, ofcours, but another vector is to spoof as the CAs resolver when the CA does a lookup for your domain.

Re: Let's Encrypt: How It Works

#30

Post by cakeface »

venomsnake wrote: post #24

> Automatically prove to the Let’s Encrypt CA that you control the website If something could "just" prove identity without worrying about MITM we would not need the whole RSA stuff.

I had a hard time un-packing this for a minute so I want to try and clarify.

The part about proving to Let's Encrypt is problematic for sites that do not already have TLS on the example.com domain. Any plain HTTP request that Let's Encrypt makes to example.com to validate that you've put up some content on the server is susceptible to a MITM attack. I guess that means for users setting up certs for the first time they can't just put some content up on example.com and need to use DNS or something else to prove ownership.

The MITM problem with requests to example.com doesn't exist if example.com is already set up for HTTPS, which is probably why the examples on the technical description show requests for https://example.com/8303. I was confused about that at first because Let's Encrypt is largely targeted towards people without any TLS encryption yet.

Post reply on HN