31–40 of 123 posts
Sorry for the newbie question.... So if I have apache running http://example.com on port 80 and I follow the instructions ($ lets-encrypt example.com) Will Apache now be correctly serving encrypted traffic on port 443 with a cert for https://example.com ?
That's the idea. It assumes you are using an OS with a package manager, and letting it manage your software and (to some extent) config files.
Sorry for the newbie question.... So if I have apache running http://example.com on port 80 and I follow the instructions ($ lets-encrypt example.com) Will Apache now be correctly serving encrypted traffic on port 443 with a cert for https://example.com ?
Earlier quoted context omitted.
Why so negative? Don't you think this is much better than the very manual ways that we now have? Automate it. Make it part of your maintenance scripts. Put it in a cron job. I think it will be a huge step forward.
I think the OP was expressing concern over Let's Encrypt being installed on servers and potentially doing malicious things. Of course, if you apply this logic to Let's Encrypt you could just as well apply it to your web server or your mail server, or even your OS itself. At some point you just have to trust that the people and organizations that you're getting your software from aren't malicious... or you could write…
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 it, and see what it changed. When it gets to run on its own, that's harder to test.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
I think the OP was expressing concern over Let's Encrypt being installed on servers and potentially doing malicious things. Of course, if you apply this logic to Let's Encrypt you could just as well apply it to your web server or your mail server, or even your OS itself. At some point you just have to trust that the people and organizations that you're getting your software from aren't malicious... or you could write…
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…
> 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…
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.
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…
Great project! Please also provide a yum repository and instructions (and any others you feel are popular enough). You may want to look at the way SSLMate does it, with an operating system drop down selection (Debian, Ubuntu, RedHat, Arch, Mac, Other).