Slashdot Mirror
Let's Encrypt Is Now In Public Beta (eff.org)
Peter Eckersley writes: As of today, Let's Encrypt is in Public Beta. If you're comfortable running beta software that may have a few bugs and rough edges, you can use it to instantly obtain and install certificates for any HTTPS website or TLS service. You can find installation instructions here.
From Introduction:
Because a shared web hosting customer is not root, the hosting provider will have to install Let's Encrypt on behalf of its customers. I plan to open a support ticket with my hosting provider to request installation of Let's Encrypt. What are the most likely objections that a hosting provider might have to enabling this?
They really want you to automate this. From the web site:
Let’s Encrypt CA issues short lived certificates (90 days). Make sure you renew the certificates at least once in 3 months.
Excessive forking causes un-wanted children.
And one must install anew at least every 90 days.
The intent is that something like cron "install[s] anew at least every 90 days."
Unfortunately, their MAXIMUM length of certificate is 90 days and it ain't getting longer; if anything they want to make them shorter in duration. So anyone who doesn't want to or can't, for whatever reason, run some cronjob on their server to auto-renew their certificates should give these guys a miss. Great shame that they let their "automate everything or GTFO" ideology override many people's legitimate need or desire for annual certificates.
== Jez ==
Do you miss Firefox? Try Pale Moon.
I'm all about free certs - but what kind of general support will there be? The last thing I want to do is tell my mom that her Android tablet can't connect to my web server because Chrome for Android won't trust the connection and won't give her the option to add an exception...
With access to my server's private keys. Who does this sound like a good idea to?
No sir I dont like it.
Honest question -- why would you want a cert you have to renew every 90 days? In case it gets stolen? I guess I just don't understand the point.
This isn't Mozilla. Mozilla is a sponsor (as are a number of other companies), but it's not a Mozilla project at all.
Nothing for windows, kind of a disappointing way for the EFF to severely limit their audience.
This only looks hard because of a mental block people have about stuff that doesn't have a gui. In reality it's way often easier to copy and paste into a terminal window -- doing obvious substitutions for things like "www.example.com" -- than it is to try to read some gui designer's mind.
You don't have to understand everything "git clone" does, any more than you have to understanding everything that happens behind the scenes when you click a button.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I understand that the target audience is admins, and that this is beta, but really?
Have you ever had to generate a certificate request, get it signed by a CA and install it in your web server? Its not rocket science but its certainly tedious with a dense jargon thicket to battle through.
./letsencrypt-auto certonly --webroot -w /var/www/example -d example.com -d www.example.com -w /var/www/thing -d thing.is -d m.thing.is
...is improvement beyond recognition.
Anyway, there's a lot of infrastructure behind that command line that should make it easy for the likes of CPanel, Plesk or maybe even Wordpress to wrap it in a nice point-and-drool dialog.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
And one must install anew at least every 90 days. Wtf, this should be trivial but is instead a sysadmin project with high maintenace.
The idea is that you would automate it, so that the client automatically renews it within the 90 day window.
Another option would be to add a TXT record with the challenge-response to the DNS. Control of the DNS literally means controlling the domain.
In other words, the CA would translate a DANE record into an X.509 certificate.
The reason for expiring certificates is to limit exposure in case the private key falls into the wrong hands. Originally certificate revocation was supposed to deal with this problem, but practice has shown that revocation doesn't work, at all. Even if it did work, the number of revoked certificates that have to be checked against depends on the validity period of the certificates: The longer they were valid originally, the longer they have to stay in the revocation lists. Certificates without an expiry date would have to be kept on the revocation list indefinitely if their keys were compromised.
They don't want to have to run weird software as root on their servers, assuming they even have this much access.
They already run NGINX, lighttpd, or Apache as root so it can listen on ports below 1024 (such as 443, the standard HTTPS port). What makes software "weird software"?
Today I went through the StartSSL process to renew the certificate for a site because it'll more than likely expire before my hosting company has a chance to implement Let's Encrypt. StartSSL isn't really that different from GoDaddy, except for two things: you use a client certificate instead of a password to identify yourself, and verifying domain control and issuing the cert are split into two steps. One e-mail verification to get your individual client cert, another to verify the domain, then paste in the CSR, and a few minutes later, the class 1 domain-validated certificate is siting in your Tool Box. The biggest UI flaw is that the tabs on your user page (Tool Box, Certificates Wizard, Validations Wizard) are arranged in reverse order of how they're used. The second biggest is that the e-mail validation requires you to be aware of tabbed browsing or at least opening your webmail in a new window.
I haven't tried WoSign. Is it any cleaner?
So much for certificate pinning.
Thank you for explaining. Consider three different attacks on an HTTP session: passive sniffing, active proxying by a man in the middle, and typosquatting. HTTPS with a self-signed certificate solves the first. HTTPS with a domain-validated certificate solves the first two. HTTPS with an organization-validated certificate solves all three.
Want to send encrypted? Generate a certificate and send away, no problem there either.
This resists passive attacks but not MITM or typosquatting. Traditionally, web browsers that support HTTPS have set the bar at MITM.
Want someone to vouch for you that you are the sender you pretend to be? Ouch, that will be $x - not because it is a prerogative of the rich, but we need to do the following verifications which cost $x.
That depends on whether you define attacks on "the sender you pretend to be" to include typosquatting. The premise of StartSSL, WoSign, and Let's Encrypt is that validation that you are the same person who owns a particular domain costs very little on top of what you are already paying for a domain. Perhaps we disagree on the impact of typosquatting, especially in a hypertext environment when people are more likely to find web sites through hyperlinks in other web documents, such as web search results, news articles, opinion columns, social media, and bookmarks, than through type-in traffic.
Remember banks are relying on the "HTTPS" lock icon and instructing their users to look for it and consider themselves "safe" if it exists.
The two tiers of CA-signed certificate have distinct purposes. Domain validation is suitable for basic validation that the sender is authorized to speak for the owner of a particular domain, whereas organization validation is suitable for further validation that the owner of a domain is also an established business. Domain validation is resistant to MITM attacks, but only organization validation is resistant to typosquatting. A hobbyist operator of a forum or wiki would use the former because he wants his site's login page to be resistant to MITM, but he sees little risk (probability times damage) of typosquatting given that forums rely on bookmarks and wikis rely on search traffic. A bank would use the latter because it sees more type-in traffic and thus more risk of typosquatting.
a) You should be renewing your SSL certificates more frequently anyway to prevent nation-states from guessing your private key by analysis of your weaker SSL protocols.
b) You automate it, it costs you $100 once and you have a lifetime of SSL certificates across your entire server farm if need be. I think hosting providers may even opt to insert it right into your base images.
c) Commercial entities and green bars really don't provide any extra security. The entire green bar is a marketing scam, it doesn't prove anything as has been proven by people being able to obtain illicit ones.
Custom electronics and digital signage for your business: www.evcircuits.com
Which is also easy to automate on the server side... It's just a header value you stick on every response. If you are cert-pinning on the client side then you might want another mechanism to help out, perhaps the DANE protocol.
Doomed to fail. The people who aren't deploying SSL are also the ones who can't install Git.
Give it a chance - its only just been released as beta. Since Its Open Source, packaged versions for all the major Linux distros will undoubtedly follow (there are already a couple). Also, people are missing the point that, apart from the client tool, there's a ton of infrastructure behind this that greatly simplifies the process of obtaining a certificate. There's now no technical excuse why, in a years time, the control panel for your web hosting service, or even your CMS, shouldn't sport a big friendly "Secure with Let's Encrypt" button (with an 'auto-renew' checkbox alongside).
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
The protocol is free and open source. You're free to reimplement it in C.
I think bingoUV's point is that novice users do not know what to look for to tell the difference between DV and EV certificates. The icon is the same either way: a lock for DV or a lock and business name for EV. Novices don't know to look for the business name because they haven't been taught so, as back when TLS proponents were first saying "look for the lock", EV didn't exist.