Let's Encrypt Is Now In Public Beta (eff.org) 135
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.
Irony overload (Score:1)
Almost as good as unicode support here
Re: (Score:2)
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."
Re: (Score:2)
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.
Re: (Score:2)
So much for certificate pinning.
Re: (Score:1)
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.
Shared hosting (Score:3)
From Introduction [readthedocs.org]:
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?
Re: (Score:2)
expect lack of interest due to no interest from other customers. therefore unwillingness to invest people-time into testing this.
i suspect your provider will simply tell you to go to startssl and get yourself a free ssl certificate.
Re: (Score:2)
Low port, you mean. Ports below 1024 can only be opened by root. The server can (and should) change users after creating the socket.
So DANE (Score:2)
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 [wikipedia.org] record into an X.509 certificate.
Re: (Score:2)
The idea is that a DANE CA would act as a transition mechanism, automatically issuing domain-validated certificates for use with user agents that do not yet support DANE.
Re: (Score:1)
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.
That's a planned feature, sadly it was considered low priority for the beta launch. Hopefully it'll be implemented in the next few months though.
Re: (Score:2)
So does that mean you have to take down your regular web server on port 80 while their server does that verification? That's pretty shitty.
Re: (Score:1)
Yep. Got this same problem. Very interested, but need it to work through CPanel ideally or at least WHM.
Re: (Score:1)
Beta software that requires root access. What could possibly go wrong?
Re: (Score:2)
>> What are the most likely objections that a hosting provider might have to enabling this?
I know one of mine (HostGator) threw a fit (charged me for installation) when I got my X.509 server cert from another provider.
I suspect many of them were looking forward to the brave new world of "HTTPS by default" as a big money-maker and aren't too pleased with the fact that the consumer's price for certs has already been driven down to $0.
Re: (Score:1)
It does require root if you want it to run a private port 80/443 service to do the authentication for you and/or to install the certificate into your apache config on your behalf. A nice feature for less capable users (ain't that a scary though)
But if you are using an existing web server and are okay with manual certificate installation/configuration and have a long command-line full of path overrides (eg. no using /etc for storing the generated certs) then it runs just fins as a normal user. I did it durin
Re: (Score:2)
Because it's a bad idea? Two independent purposes are served by HTTPS - encryption in transit, and sender identification. Self generated certificate is enough to do the encryption in transit business.
For sender identification, it makes no sense to do it automatically and/or cheaply. It should be even more expensive, and come with lots of verifications. By doing it "automatically", we defeat the whole purpose of sender identification.
Browsers (including a partner in this project- Mozilla) are too stupid to n
Re: (Score:3)
Let's Encrypt already validates that the sender is authorized to speak for the domain. But you make it sound like there's no place for encryption in transit without stronger sender identification, ideally one verified against real-world credentials. Further, you make it sound like there ought to be an entry barrier to sender identification. Do I understand you correctly so far? And if so, how much ought the right to send to cost, in your opinion? Should individuals have the right to send, outside the course
Re: (Score:2)
But you make it sound like there's no place for encryption in transit without stronger sender identification
I am saying the opposite, no idea why you interpret it this way. It is very easy to encrypt in transit - just generate your certificate and encrypt away. Even the name of the project - Let's Encrypt - "makes it sound like" encryption in transit is the big deal, not the sender identification.
Repeat after me - encryption DOES NOT NEED identification.
Further, you make it sound like there ought to be an entry barrier to sender identification
How do you identify something without creating a barrier for it?
Do I understand you correctly so far?
50%.
Should individuals have the right to send, outside the course of a business?
Send away, no problem.Want to send encrypted? Generate a certificate and send away, no problem
Type-in vs. inbound link traffic (Score:2)
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 atta
Re: (Score:2)
Thank you for explaining. Consider three different attacks on an HTTP session: passive sniffing, active proxying by a man in the middle, and typosquatting
There is a fourth one - phishing. You might call it a variant of typo-squatting, but actually it is not. Your attempt to call it social engineering will also be met with a "Nah".
You get an email about updating your ING bank contact details urgently, and get a link to click on directly. But it is ingatyourservice.com - page content look and feel copied from ING's net banking website. User doesn't notice that this is not real ING, ignores the few mistakes in copying the phishers made, and enters everything th
Re: (Score:2)
There is a fourth one - phishing. You might call it a variant of typo-squatting, but actually it is not.
Phishing is similar to typosquatting in that the user is being redirected to the wrong domain. I agree that an organization-validated cert protects against this, especially among novice users who can't be trusted to stick to bookmarks. But a domain-validated cert might be enough if credentials aren't valuable enough to allow rapid irreparable damage before blocking the account, such as a forum or wiki account compared to a bank account.
There is a fifth attack vector - though none of the business of website owners or visitors. But EFF has made it their business to complain about it. It is the dragnet surveillance by TLAs. HTTPS prevents that too. "Let's Encrypt" sounds like an attack on that attack.
This counts as passive sniffing and occasionally MITM.
both - banks' padlock icon and Joe Sixpack's website's padlock icon look the same to me.
On Pin Eight [pineight.com], whic
Re: (Score:2)
This counts as passive sniffing and occasionally MITM.
MITM is too much work for dragnet. But yeah, passive sniffing.
On Pin Eight, which uses a domain-validated certificate, Firefox shows me only a green lock. On Chase, which uses an organization-validated certificate with EV extensions, Firefox shows me a green lock plus "JPMorgan Chase & Co." in green.
You're right, I notice that now. But distinction is not big enough for the people who will get scammed by the phishing. And I remember emails from my bank a few years ago about looking for the padlock icon - this distinction wasn't made there.
So it remains a bad idea - insufficiently validated websites getting that padlock, getting more people to be phished. All due to conflating encryption and sender validation.
Re: (Score:2)
"A site doesn't need MITM protection unless it also needs phishing protection." Are you claiming or not claiming this?
MITM is too much work for dragnet.
Yet MITM is common on corporate networks.
And I remember emails from my bank a few years ago about looking for the padlock icon
It depends on how long ago was "a few years ago". Was it before the introduction of extended validation [wikipedia.org]? If so, browsers might not yet have introduced UI to distinguish domain- from organization-validated certificates.
So it remains a bad idea - insufficiently validated websites getting that padlock, getting more people to be phished.
For a web site operated by an individual as a hobby, where the operator desires protection from passive and MITM attacks, what measures
Re: (Score:2)
Thanks to you, I learnt about EV certificates.
"A site doesn't need MITM protection unless it also needs phishing protection."
Everyone "needs" all kinds of protection, but different people pay for different ones. MITM is used in a way of phishing, so you cannot protect against phishing unless you also protect from MITM . But if certificates are a dime a dozen, you've not really protected from MITM phishing as well as impersonation phishing. You're only achieving the encryption in transit, and preventing the
Re: (Score:2)
But if certificates are a dime a dozen, you've not really protected from MITM phishing as well as impersonation phishing.
Then let me reword my perception of your central thesis one more time: "It is not worth making a certificate that protects against impersonation of a domain owner using the same domain unless it is also worth paying for a certificate that protects against impersonation of a business using a different domain." Do I have it right now?
Re: (Score:2)
It is not worth making a certificate that protects against impersonation of a domain owner using the same domain unless it is also worth paying for a certificate that protects against impersonation of a business using a different domain
Depends on the ease of attack. One way I see for same domain impersonation is by compromising the user's DNS. Are there others? DNS compromise is somewhat involved but not extremely difficult, not very common in my experience with novice users, nor in the news I read.
But you are right, in that this attack vector definitely cannot be ignored, so it is worth making a certificate to protect against the same domain attack.
So does it boil down to Let's Encrypt being a protection against DNS compromises?
Re: (Score:2)
So does it boil down to Let's Encrypt being a protection against DNS compromises?
Until all domains' DNS servers are upgraded to support DNSSEC and all web browsers are upgraded to support DANE, half of what a DV cert does is defend against DNS spoofing on a user's first visit. The other half is a protection against transparent proxying.
Re: (Score:2)
Remember banks are relying on the "HTTPS" lock icon and instructing their users to look for it and consider themselves "safe" if it exists. ING bank shouldn't have to buy ing.com, ing.org, mying.com, ingbank.com, myingbank.com just because domain ownership is the be all and end all of "identification" on the internet.
This is why you should expect EV-SSL [wikipedia.org] from your bank. There is plenty of additional paperwork required to prove identity and it gives additional assurance with a different icon in the browser address bar.
Can novices tell DV lock from EV lock? (Score:2)
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.
Re: Can novices tell DV lock from EV lock? (Score:2)
That's more of a browser implementation problem. It's still the right choice if someone can think of a good way to distinguish between secure and trusted. A lock probably isn't the right icon for trust, years of passive training aside.
Re: (Score:2)
Anonymous Coward wrote:
It's 2015. Why is anybody running on shared hosting? You can get a solid VPS for $10/month and install whatever the hell you want.
Because they're on a shared hosting plan at less than $10 per month.
So anyway, in case anyone is reading this and shopping for a new web host, which $10 per month VPS hosts are any good?
Re: (Score:2)
Very short certs. (Score:5, Insightful)
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.
Re:Very short certs. (Score:5, Insightful)
Re: (Score:2)
I was looking forward to this... (Score:5, Insightful)
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.
Re: (Score:1)
This isn't Mozilla. Mozilla is a sponsor (as are a number of other companies), but it's not a Mozilla project at all.
Ports below 1024 (Score:2)
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"?
Re: (Score:3)
If they don't fit your needs, vote with your dollars. You're more that free to pay for certs from another organization!
On that note: I initially had some issues with part of their implementation, too. But I'm working through it now by having a dedicated VM just for renewing my certs, and then that VM's cron script pushes the cert files to the actual web servers.
It isn't that difficult to work around the limitations on their system right now if you just put a little thought into it.
Re: (Score:2)
Oh don't worry, I am voting with my (non-)dollars. I've just signed up for some more annual certs from StartCom. LetsEncrypt and their stubborn attitude can go hang. It's just disappointing, that's all.
Re: (Score:2)
The whole LetsEncrypt thing is about making the internet more secure. In all honesty long lived certificates is not a good idea. Because most CAs have your certs expire once a year, many people don't automate certificate renewal.
But we should, just like we should rotate passwords, etc... (I know it's not the same).
Obviously, LetsEncrypt won't fit in with most existing setups. Hopefully, shared hosting providers will pick it up and integr
Re: (Score:2)
Re: (Score:2, Insightful)
It's probably the right decision though, because certificate revocation is terminally broken. Short-lived certificates are the only option to ensure that the expected audience won't have effectively irrevocable certificates floating around for years after losing control over the keys in a configuration mishap.
However, I am certainly not going to trust them with root access to the server, partly because I don't have it myself, and partly because that should not be necessary at all.
Re: (Score:1)
You can run the LE auto-update software as a non-root user. It takes some thought, but it's 100% doable.
Re: (Score:1)
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 dat
Re: (Score:1)
1) There are some pretty compelling reasons for choosing the 90-day cert expiry period: https://letsencrypt.org/2015/11/09/why-90-days.html
2) You don't have to run the official LE client. ACME is fully documented and at least one fully-functioning alternative client is out there. Given that LE entered public beta *today*, expect many more ACME clients in the near future.
3) ...who *needs* CA-issued TLS certs that have a 365 day expiry period? Far-flung embedded devices that don't even have the horsepower to
Trust? (Score:1)
Re: (Score:1)
Their root cert is cross signed by another big time CA, which is trusted by all the major browsers.
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Or, to put it shorter, "Let's Encrypt is an Identrust reseller."
Re: (Score:2)
Re: Trust? (Score:1)
Why would a CA authority cross sign a competitors certificate , and kill their own business ? That I don't get
Lets run arbitrary code (Score:3)
With access to my server's private keys. Who does this sound like a good idea to?
Re: (Score:2)
Re: (Score:2)
It has automated updates built in and is pretty much required to be fully automated to be useful. So I would have to disable those updates until they break it from working then re audit the code again and hope to catch that break before the SSL cert expires. That is a whole lot of work and risk.
Now you could just grab a new expiration date cert via the same certificate request and not need to know the private key in the first place ever but that does not look like how this works it expects to have a free
Re: (Score:2)
It has automated updates built in and is pretty much required to be fully automated to be useful. So I would have to disable those updates until they break it from working then re audit the code again and hope to catch that break before the SSL cert expires.
So why must you audit the code? Can't you simply trust the guys to not deliver malicious code? Do you not think that they are at your side? Why be part of anything in the first place if you can't trust the makers?
Re: (Score:2)
The code should only need to ready the private key one time during the initial setup. A Cert request is not dated and has no sensitive information and can be reused to get a new cert until the private key changes. Pretty much this is one tool that should be two, one to setup with no need for network access (it creates a priv key a cert request configures other servers) and another that does the every 90 days or more often updates.
Re: (Score:1)
Agreed, I don't see how any of this needs root at all.
Get going (Score:2)
The protocol is free and open source. You're free to reimplement it in C.
Re: (Score:2)
Those who don't have the skills to do it otherwise? It is of no use to any other kinds of people anyway.
Re: (Score:2)
If your unable to figure out how to install a SSL cert and are running a web server, you should probably not be running a web server and the lack of SSL is the least of your worries.
Re: (Score:2)
Then there is no market for this product, so requiring root is least of your worries.
Re: (Score:2)
It was supposed to remove the cost of CA signed SSL certs as a roadblock to implementing them.
Re: (Score:2)
That part works without running this code too.
Re:DOA? (Score:4, Insightful)
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.
Some people are just hard to please... (Score:4, Informative)
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.
Re: (Score:2)
Re: (Score:2)
The only people I remember doing that were the .fr domain name requests. You had to get a physical letter signed by a police officer in France to prove you were a person or get a copy of your physical business permit. Then you had to fax it or mail it in after it went through several other manual steps.
But Why? (Score:2)
Re:But Why? (Score:5, Informative)
It seems that certificate revocation is not working particularly well in practice. The 90 day duration is meant to help with this, you can simply let the certificate expire.
Re: (Score:2)
Re: (Score:2)
They want you to enable HSTS for long duration (1 year), with certificates that expire in a week so that when you mess with the authorities and don't comply with their demands, they are able to wipe you off of the Internet faster.
Re: (Score:3)
Re:But Why? (Score:5, Informative)
Bear in mind that current free certificates from the likes of StartSSL expire after 1 year anyway - and are at least 4 times more hassle to obtain and install than Lets Encrypt is shaping up to be.
StartSSL process (Score:3)
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 th
man.. (Score:2)
Re: (Score:2)
With Windows running only 27% of the Internet's web servers*, calling it "severely limit[ing]" is more than a little hyperbolic.
* source: http://news.netcraft.com/archi... [netcraft.com]
Re: (Score:2)
Back in the day we web devs would be regularly told that only targeting 97% of visitors through only supporting IE was not good enough, and that 3% counted...
On that basis, 27% of market share is a little more to worry about.
Re: (Score:2)
Yes, AC, that's _exactly_ what you would do. This is in beta, where you choose a prime sub-section of your market to run tests with. That is literally part of the definition of beta testing.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2, Informative)
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 pr