Live data from Hacker News

Let's Encrypt: How It Works

letsencrypt.org

41–50 of 123 posts

Re: Let's Encrypt: How It Works

#41
Does this kill the business model for normal CAs, or is there something worth going to another CA for?

Also, how trivial/hard will it be for a state agent to generate its own certificate-signing traffic and use the Let's Encrypt CA to sign arbitrary domains of their choosing?

Re: Let's Encrypt: How It Works

#42
post #38

Earlier quoted context omitted.

I take it you've read the source code of Apache and Nginx then and confirmed that they aren't doing anything malicious as well? :) In any practical security system you are always going to have to trust that certain components are doing what they say they're doing. Fortunately, Let's Encrypt is from a reputable group, and sponsored by organizations with good reputations (Mozilla, EFF, etc.), which is about as good as…

Yes, I need to trust some things. But I can limit the amount of trust I need to have by limiting the number of things to run. I can add a reminder to my calendar to say "hey renew your certs", or better yet I can add a check to my existing monitoring service to look at expiration dates. Why run a whole new persistent service just for this?

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.

Re: Let's Encrypt: How It Works

#43
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?

I take it you've read the source code of Apache and Nginx then and confirmed that they aren't doing anything malicious as well? :) In any practical security system you are always going to have to trust that certain components are doing what they say they're doing. Fortunately, Let's Encrypt is from a reputable group, and sponsored by organizations with good reputations (Mozilla, EFF, etc.), which is about as good as…

Many people draw a line between one time trust and continuous trust. If this thing can update the certs on my server whenever it likes, that's substantially more trust than permitting it to install a cert exactly once. If, for example, it has a bug that permits a malicious upstream to overwrite arbitrary files, the window of vulnerability expands from "the CA is pwned this instant" to "the CA will at any future time ever be pwned".

Re: Let's Encrypt: How It Works

#44
post #41

Does this kill the business model for normal CAs, or is there something worth going to another CA for? Also, how trivial/hard will it be for a state agent to generate its own certificate-signing traffic and use the Let's Encrypt CA to sign arbitrary domains of their choosing?

I'm thinking someone could spoof a DNS entry for the signing server and prove that they own any domain they want, is that prevented somehow?

Re: Let's Encrypt: How It Works

#45

> 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 the…

I don't see how using TLS would prevent MITM in this case. TLS only prevents MITM if you know public key or if it's been signed by a CA, but neither is the case here.

Re: Let's Encrypt: How It Works

#46

> 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 the…

Why can DNS not be spoofed when HTTP can? It seems to me that you need one to spoof the other...

Re: Let's Encrypt: How It Works

#47
post #36
post #33

Earlier quoted context omitted.

Bear in mind that this is all vaporware. The github repository for "AJAX" just has a spec, no code. They're selling a security "solution" no one has evaluated yet. I'm bothered that this runs periodically. Will it auto-update code? How secure is the auto-update process? Who can run an auto-update? Does it run as root? If so, why? If it was a one-time manual run, that wouldn't be so bad. You can snapshot a system, run…

I think they have stated that they want to get official packages into distro repositories, so you'd get whatever security your distribution's package manager provides, and your distribution of choice would act as a kind of gatekeeper against malicious code/updates the same way it does for other packages.

That is exactly correct. And the client will be open source code written in Python.

It's not like "take this binary blob from us and run it as root on your machine", it's like "we have an open source project that would like to work with your upstream OS distributor on exactly the same terms as, and in exactly the same way as, the other tools that you're using on your server".

Edit: If you want to follow along with, audit, contribute to, help package, etc., our preview client, it is available at

https://github.com/letsencrypt/lets-encrypt-preview

We will also welcome people to create their own interoperable software, so if you don't want to run our client or any of its dependencies, or if it doesn't work well with your serving environment, you can create your own alternative. (Hosting providers or CDNs that want certs for sites they host, for example, could create their own tools to deploy them, instead of using our tools.)

Re: Let's Encrypt: How It Works

#49
post #41

Does this kill the business model for normal CAs, or is there something worth going to another CA for? Also, how trivial/hard will it be for a state agent to generate its own certificate-signing traffic and use the Let's Encrypt CA to sign arbitrary domains of their choosing?

It doesn't issue EV certs, so the business model for traditional CAs will be those.

Re: Let's Encrypt: How It Works

#50
post #41

Does this kill the business model for normal CAs, or is there something worth going to another CA for? Also, how trivial/hard will it be for a state agent to generate its own certificate-signing traffic and use the Let's Encrypt CA to sign arbitrary domains of their choosing?

I'm thinking someone could spoof a DNS entry for the signing server and prove that they own any domain they want, is that prevented somehow?

If an attacker can spoof DNS, they can just create A records that point to their own server, and MITM from that.

Public key pinning would protect against that class of attacks: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...

Post reply on HN