Why caring at all about OCSP/CRL revocations that don't work anyway (https://www.imperialviolet.org/2014/04/29/revocationagain.ht...)? If you have an agent running on the webserver, you're 99% close to simply use short-lived certs. Just issue 1-week certs and be done with.
Let's Encrypt: How It Works
51–60 of 123 posts
Re: Let's Encrypt: How It Works
#52Why caring at all about OCSP/CRL revocations that don't work anyway ( https://www.imperialviolet.org/2014/04/29/revocationagain.ht... )? If you have an agent running on the webserver, you're 99% close to simply use short-lived certs. Just issue 1-week certs and be done with.
Getting to short-lived certificates is a goal, but the reality for now is that OCSP and CRLs are what implementations require, and what the CABF Baseline Requirements require. So we'll need to start with those.
Re: Let's Encrypt: How It Works
#53Wouldn't it be much easier if lets-encrypt just created the .crt .key files!? Rather then set it up automagically.
You could have it run once a year via crontab.
I would like to keep the control of my .conf files.
Re: Let's Encrypt: How It Works
#54Does 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.
I don't think EV SSL certificates have been a big success (though that's just a personal opinion rather something backed with specific data)
For me the differentiation in the browser presentation of EV against ordinary SSL doesn't provide much additional security. Most users don't notice the difference and even if they do, wouldn't remember which sites had an EV certificate, such that they would notice it changing back to non-EV
Re: Let's Encrypt: How It Works
#55Upside: This is an awesome idea and I really hope you can get support for this from browsers, the major operating systems, and smartphone makers. I, for one, usually want a cert when I request it (often as the last step before launching a product) and hate the wait imposed by Network Solutions, GoDaddy, and others.
Downside: You are lowering the bar for SSL certs (no business registration verification, for example) which could open the door to malicious players impersonating established organizations (i.e. microsoft.phishme.com masquerading as Microsoft Corporation) and making it easier to dupe the vulnerable.
Re: Let's Encrypt: How It Works
#56Earlier quoted context omitted.
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...
Whose DNS layer? If they own the user's, no. If they own the server's, maybe, if they could convince the CA to sign a certificate they control. Otherwise, they couldn't really do anything.
Re: Let's Encrypt: How It Works
#57Earlier quoted context omitted.
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 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. FYI, CAs do this already (HTTP validation), but an easy fix is to generate a self signed cert and pass the fingerprint of it to the CA.
Not sure how the self-signed cert would make things better. Couldn't an MITM attacker do the exact same thing? Presumably, the MITM attacker would already be the party making the (fraudulent) request to the CA, so they could submit their own fingerprint.
Re: Let's Encrypt: How It Works
#58Wouldn't it be much easier if lets-encrypt just created the .crt .key files!? Rather then set it up automagically. You could have it run once a year via crontab. I would like to keep the control of my .conf files.
That will be an option.
Also, the current implementation only changes the SSLCertificateFile directive if you provide your own --key, --csr and already have an SSL vhost for the domain. (This one change is logged.)
Re: Let's Encrypt: How It Works
#59Earlier 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…
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…
Easy fix: Run the tool as its own user, give write permission to cert & key files to that user. If you're really paranoid, run it in a jail that only has access to those files. No different than proper security for any other system process.
Re: Let's Encrypt: How It Works
#60Unfortunate 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/
The open source python code also demonstrates it.