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?
Let's Encrypt: How It Works
41–50 of 123 posts
Re: Let's Encrypt: How It Works
#42Earlier 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?
Re: Let's Encrypt: How It Works
#43Keep 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…
Re: Let's Encrypt: How It Works
#44Does 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
#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…
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…
Re: Let's Encrypt: How It Works
#47Earlier 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.
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
#48Re: Let's Encrypt: How It Works
#49Does 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
#50Does 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?
Public key pinning would protect against that class of attacks: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn...