Last year they did a talk at CCC. Well worth a watch.
Our First Certificate Is Now Live
71–80 of 263 posts
Re: Our First Certificate Is Now Live
#72This whole effort is making me a little bit giddy! Viva la admin-friendly security!
Re: Our First Certificate Is Now Live
#73Does anybody know if there is any protection built in against MITM or DNS poisoning attacks? It feels like this makes network hop security far more important. If I'm able to insert a MITM or DNS poisoning anywhere between where letsencrypt.org's servers are and where it thinks the requesting server should be then I can generate a false certificate. For example, Amazon's DNS resolves for letsencrypt as 1.2.3.4 which r…
Boulder (the CA backend) has two solutions to this problem a. if we know of an already existing certificate for the domain that is being authorized you must prove control over both the server and the key used in the existing certificate b. validation is done over multiple paths to confirm results, an attacker would need to be able to hijack connections from all of our validation servers in order to cause miss-issuanc…
What happens if the user loses the key?
What happens if a certificate is requested, the domain is sold to a new owner and the new owner tries to request a certificate, but doesn't have access to the keys for the old one?
Also, how can the new owner revoke all certificates delivered to previous owners?
Re: Our First Certificate Is Now Live
#74Everyone repeat after me, wildcards, wildcards, wildcards. (just hoping they will appear next year) One more nail in the coffin of the ssl cert mafia.
While I too would like to see wildcards, doesn't the fact that you can programmatically obtain a cert for a subdomain obviate most of the wildcard needs? Sure it's a bit more difficult but if your service has some form of sorts to make a subdomain work for a specific word, surely it can request the cert at that time. Having said that, obviously keeping track of only one cert and not having to build this into your app…
This comes up when you are running a multi-tenant app with many tenants; github.com is a good example. You can sign up as "dude.github.com" or "me234.github.com" and so on. So, Github can either a) obtain wildcard SSL cert for "*.github.com" once, and then present it to tenants, and control access with the "domain" property of the cookie, and don't worry about SSL cert until next year's renewal time, or 2) apply to some authority for XXX.github.com every time the new tenant signs up. Well, 2) makes you reliant on "some authority" every time new customer signs up, (hopefully many times a day!) which is not so very good IMHO. Just my 5c.
Re: Our First Certificate Is Now Live
#75I feel like these initiatives to make SSL available for everybody just lead to the same conclusion: EV will be the only viable alternative to show real trust, and EV is much, much more expensive than regular SSL ever was.
Re: Our First Certificate Is Now Live
#76Earlier quoted context omitted.
Well. I missed that memo. Or rather I kinda sorta knew it was getting devalued, but a Padlock in my browser is something I trust . If it's not trust worthy or verified should we not go the whole hog, dump trusted public keys from all browsers and move to the web-of-trust / certificate pinning. From the blog: just too much of a hassle. The application process can be confusing. It usually costs money. It’s tricky to in…
> But a Padlock in my browser is something I trust. On the padlock note, Microsoft Edge shows a hollowed out, grey padlock for DV certificates. Only EV certs get a full green one (as well as the legal name as other browsers show for EV). See https://certsimple.com/blog/dv-ssl-in-microsoft-edge
Now we just need to add a big red icon for http sites...
Re: Our First Certificate Is Now Live
#77I feel like these initiatives to make SSL available for everybody just lead to the same conclusion: EV will be the only viable alternative to show real trust, and EV is much, much more expensive than regular SSL ever was.
But that's nothing new. If you need real trust, you need EV. The win from LetsEncrypt and any other attempt to make SSL more mainstream is the encryption, not the trust. If you're using SSL you're protected from some government and ISP snooping, and from having the contents of your message or webpage altered in mid-stream by a nefarious third party like AT&T.
Re: Our First Certificate Is Now Live
#78Earlier quoted context omitted.
Incorrect. Inclusion into the Firefox root store is being tracked in https://bugzil.la/1204656 and has not yet been resolved. Firefox trusts the cert on TFA because letsencrypt.org itself is using a certificate signed by IdenTrust.
Looking at http://helloworld.letsencrypt.org/ I see: > Let's Encrypt hasn't yet been added as a trusted authority to the major browsers (that will be happening soon), so for now, you'll need to add the ISRG root certificate yourself. Specifics will depend on your browser. In Firefox, just click the link.
Wow the Firefox process to add a root is pretty simple! Downloading a file is more difficult. Adding an exception for a self-signed cert is scary.
But adding a new root? Little popup, check a box and OK-you-go!
Re: Our First Certificate Is Now Live
#79It's amazing that it takes a free provider to make things simple: https://letsencrypt.org/howitworks/ I'd actually pay more than I do now for SSL certs to get that kind of simplicity.
I run https://certsimple.com : we only do EV certificates, we're the fastest place to get an EV cert, we check as much as we can before you pay us a cent, and our application process is 80 seconds.
These shameless plugs are getting really annoying. We know about you, we know CloudFlare and Let's Encrypt are kinda competitors with their free certificates, but you don't have to comment on each post about them. Really, stop annoying us - it doesn't do you any good, honestly!
Re: Our First Certificate Is Now Live
#80Earlier quoted context omitted.
Boulder (the CA backend) has two solutions to this problem a. if we know of an already existing certificate for the domain that is being authorized you must prove control over both the server and the key used in the existing certificate b. validation is done over multiple paths to confirm results, an attacker would need to be able to hijack connections from all of our validation servers in order to cause miss-issuanc…
What happens if the user loses the key? What happens if a certificate is requested, the domain is sold to a new owner and the new owner tries to request a certificate, but doesn't have access to the keys for the old one? Also, how can the new owner revoke all certificates delivered to previous owners?
Certificates expire. Presumably the answer to all of your questions would then be to wait for the old certificate to expire.
So if you want to mitigate the consequences at the outset, use certificates that expire quickly. Which should be easy when renewing a certificate is free and automatic.