Re:Let's Encrypt Launch Schedule
by diafygi on Tuesday June 16, 2015 @12:15PM
(#9726891)
I'm suuuper excited for this to launch! However, it's worrisome that the ACME protocol (what Let's Encrypt uses) still has a ton of bugs open[1] and they are still changing the protocol often. Just search for "TODO" on the spec markdown[2].
I want this project to proceed, but they should really focus on getting a much more mature and stable spec before launch. This isn't WebRTC, where you can just continuously tack on additional stuff or change the API constantly. It's TLS certs. The certs issued using this API end up telling people it's safe to input their passwords or credit card numbers.
I really hope the ACME spec gets stable before the launch in July.
Re:Let's Encrypt Launch Schedule
by cbhl on Tuesday June 16, 2015 @12:58PM
(#9727205)
> The certs issued using this API end up telling people it's safe to input their passwords or credit card numbers.
I'm pretty sure they shouldn't tell users it's safe to type in credit card numbers -- these certs are "domain validation" (DV).
The certs that generate a green chip in the address bar are "extended validation" (EV) certs that typically cost hundreds and require a human to manually verify things.
Re:Let's Encrypt Launch Schedule
by diafygi on Tuesday June 16, 2015 @01:46PM
(#9727497)
It's taken me years, but I've finally trained my Mom to "look for the lock" whenever she has to type her password or credit card in anywhere. I consider that a win. Trying to get her to understand more than "lock=safe, no lock=unsafe" is incredibly difficult that will take many more years. Like it or not, since DV has a lock, that's what the standard is for what's safe to people who don't understand there's multiple levels of security in computers.
Re:Let's Encrypt Launch Schedule
by vtlynch on Tuesday June 16, 2015 @01:07PM
(#9727270)
Validation has nothing to do with the security of the certificate. There is nothing preventing you from using a DV, OV, or EV certificate to transmit any type of data you want.
Re:Let's Encrypt Launch Schedule
by dragonwriter on Tuesday June 16, 2015 @02:05PM
(#9727654)
> Validation has nothing to do with the security of the certificate.
It has to do with the security and accountability of the end-to-end process in which the certificate is used, which is a security concern even if you define "security of the certificate" so narrowly that it isn't relevant to the security of the certificate as such. (Though what you have a trusted third-party vouching for in the certificate -- which is the key distinction in EV -- is, I would think, by any reasonable standard, a factor in the security provided by the certificate.)
Re:Let's Encrypt Launch Schedule
by vtlynch on Tuesday June 16, 2015 @05:05PM
(#9728696)
Yes, it is true that validation does add accountability and security. However, suggesting that DV certificates are less suitable than EV certificates for handling a certain kind of data is nothing more than misinformation.
The cipher being used and the SSL configuration dictate MUCH more about the security of a site than its level of validation. EV certificates do not guarantee the site isnt using a insecure cipher. EV certificates do not guarantee that the private key was not sent via plain text in an email while a network admin was installing it. So from an encryption standpoint, there is no advantage.
From a authentication standpoint, an EV MAY provide more security but remember: An EV primarily validates the name and location of the relying party. It does not check to see if they are operating ethically or if you are getting ripped off.
I dont think EV is bad, but clamping down on what type of certificates can be used gets tricky. There are very few uses where EV (or OV) certificates should be required.
Re:Let's Encrypt Launch Schedule
by qrmn on Tuesday June 16, 2015 @12:37PM
(#9727045)
I gather they're not launching with ECDSA certificates (and obviously not with EdDSA or whatever comes out of CFRG, because that's still being discussed by the IETF/IRTF), but they're going to add it later. Any idea when?
What's the hold up; HSMs that'll do secp256r1?
Because of the huge performance improvement ECDSA brings over RSA, I know I'm not going to be deploying Let's Encrypt certs until I can get ECDSA ones (as well as RSA ones, presumably).
Re:Let's Encrypt Launch Schedule
by jtchang on Tuesday June 16, 2015 @11:50AM
(#9726653)
I am really excited about this whole initiative. Mostly because encryption should really be standard at this point if not for the hurdles one has to face in deploying it.
What type of help is the Let's Encrypt team still needing?
Re:Let's Encrypt Launch Schedule
by tokenizerrr on Tuesday June 16, 2015 @11:22AM
(#9726441)
Very glad to hear there is a launch schedule, have been curious about how this project has been progressing. It's a fantastic intiative and I almost can't wait until September 14.
Re:Let's Encrypt Launch Schedule
by aroch on Tuesday June 16, 2015 @12:00PM
(#9726744)
No predatory pricing (StartSSL has $25 revocations), free (AlphaSSL) and user-friendly (StartSSL is a UX nightmare). PositiveSSL is probably the cheapest, well supported cert (certs can be had for $3-4/y).
Re:Let's Encrypt Launch Schedule
by aroch on Tuesday June 16, 2015 @05:02PM
(#9728674)
I've bought from the below, there are other resellers around the same price (Namecheap being one). IIRC, they routinely have 20+% codes which get you to $4/y.
Re:Let's Encrypt Launch Schedule
by StavrosK on Tuesday June 16, 2015 @11:58AM
(#9726720)
Because it includes a script you can just run and will take care of everything for you, and you'll have properly TLS-configured web servers with valid certificates and reissues with a single command.
Re:Let's Encrypt Launch Schedule
by dingaling on Thursday June 18, 2015 @02:19AM
(#9737084)
No sane system administrator is going to run a root-privilege program to reconfigure his web server and set-up SSL:
The Let’s Encrypt client is essentially an operating system component. Generically, it requires root privileges to bind to port 443 and (if requested) to reconfigure your webserver for certificate installation and renewal
That also seems like a perfect compromise vector for bad actors to modify the client software.
The Let's Encrypt effort is noble and definitely required but I think they would have been better-focused and quicker to market had they concentrated on establishing themselves as a CA first and leaving the 'auto-configuration magic' to a later stage, for the small subset of users who want that.
Re:Let's Encrypt Launch Schedule
by StavrosK on Thursday June 18, 2015 @05:26AM
(#9737548)
I don't understand how this is any worse than any other of the thousands of pieces that you run on your server. If you audit the code and it looks fine, and it's coming signed from a trusted source, what's the problem? It's not even a daemon, it just runs for a few seconds and exits.
Re:Let's Encrypt Launch Schedule
by clinta on Tuesday June 16, 2015 @01:47PM
(#9727504)
Automatic enrollment and renewal means that it's not a maintenance burden to have certificates that are valid for weeks rather than years. Short lived certificates reduce the cost of a certificate compromise and increase the security of the internet as a whole.
Re:Let's Encrypt Launch Schedule
by masida on Tuesday June 16, 2015 @12:49PM
(#9727138)
Very nice initiative.
But for me the biggest problem with adoption of SSL is still that every domain name needs it's unique IPv4 address, and all problems that come with that, not registering or paying for the SSL certificate.
At work, I usually use virtual hosting for about 100 domains on one IP address. I don't see us buying an IPv4 address per domain and adding them to my NIC configuration one by one. Once we can safely ignore IPv4 and use IPv6 only it will probably become easier and cheaper.
Re:Let's Encrypt Launch Schedule
by LinuxBender on Tuesday June 16, 2015 @04:15PM
(#9728438)
SNI is fine for web browsing, but for end-points that need to be reachable by older versions of python, tomcat, ruby and many proprietary apps, this will not suffice. This becomes a problem on business to business communications, automation, API's, etc. For the general purpose websites, blogs, etc, SNI would be fine.
Re:Let's Encrypt Launch Schedule
by hobarrera on Tuesday June 16, 2015 @08:15PM
(#9729422)
You're probably talking about really old versions of applications. I've been using SNI for half a decade without any issues.
Anything so old that does not support SNI probably still uses SSLv3, or maybe even SSLv2, so you really should be upgrading that ASAP, rather than keep supporting it.
Re:Let's Encrypt Launch Schedule
by LinuxBender on Friday June 26, 2015 @04:35PM
(#9787577)
If you take a look at the wiki article, there are some versions listed. Those are still in use. If our company forced people to use SNI, we would be out of business. There are TLS 1.0+ enabled apps that can't do SNI. Perhaps you and I are just in very different business models.
Re:Let's Encrypt Launch Schedule
by JoshTriplett on Tuesday June 16, 2015 @01:07PM
(#9727268)
> But for me the biggest problem with adoption of SSL is still that every domain name needs it's unique IPv4 address, and all problems that come with that, not registering or paying for the SSL certificate.
Only if you care about IE on Windows XP (which is no longer supported and no longer gets security updates) or Android phones more than 4 years old (2.3 Gingerbread and older). SNI works fine on other devices.
Have you measured? Do you have numbers for how many users you have running one of those two environments?
Re:Let's Encrypt Launch Schedule
by warp on Wednesday June 17, 2015 @12:12AM
(#9730025)
New phones are still being sold with Android 2.3 here [1] in Ecuador (which is ridiculous), so for some markets you do need to verify what your target audience uses before making assumptions like that.
Re:Let's Encrypt Launch Schedule
by vtlynch on Tuesday June 16, 2015 @01:14PM
(#9727323)
With many platforms you can also use a Multi-Domain certificate to use one Certificate with one IP. Let's Encrypt will support Multi-Domain certificates.
Re:Let's Encrypt Launch Schedule
by vtlynch on Tuesday June 16, 2015 @12:39PM
(#9727070)
No. The Let's Encrypt root was recently created and will be submitted to root inclusion programs. It will probably be quite a while until its suitable to issue certs solely from the Let's Encrypt Root.
For now, the certs are cross signed by "DST Root CA X3" operated by Identrust. This root has very strong inclusion.
Re:Let's Encrypt Launch Schedule
by teraflop on Tuesday June 16, 2015 @12:42PM
(#9727083)
Fair enough, but bear in mind that StartSSL's revocation fee is lower than what most certificate providers charge as a starting price. Personally, I'm fine with taking the risk and eating the $25 cost if something unexpected happens.
Re:Let's Encrypt Launch Schedule
by clinta on Tuesday June 16, 2015 @01:44PM
(#9727484)
No company should be incentivising companies to not revoke compromised certificates. Even if the cost is modest. It's more about not patronizing a company with such a bad business model than it is about the dollar cost.
Re:Let's Encrypt Launch Schedule
by currysausage on Tuesday June 16, 2015 @02:15PM
(#9727735)
StartSSL's business model: making things free that don't cost them measurable money, and charging for transactions that cost them money.
An exception from that rule in the wake of Heartbleed would arguably have been appropriate, but the business model as such is in no way bad. If the whole SSL industry worked in a way that put price and cost in proportion, there would be no need for Let's Encrypt.
Re:Let's Encrypt Launch Schedule
by clinta on Wednesday June 17, 2015 @04:08PM
(#9734893)
Not encrypting is better than not revoking a compromised certificate. A compromised certificate gives the user the impression that the connection is secure when it's security is compromised. A plaintext connection makes no false claims.
Re:Let's Encrypt Launch Schedule
by hobarrera on Tuesday June 16, 2015 @08:17PM
(#9729428)
> Revocation costs money[...]
I think it's quite understandable that they charge for things that cost them money, but keep the rest free. You can't really expect for them to give out for free something that has a cost for them.
Re:Let's Encrypt Launch Schedule
by yellowapple on Tuesday June 16, 2015 @03:03PM
(#9728067)
On top of the revocation issues, StartSSL is only free for personal use; if you intend to obtain a cert for a small business or some other non-personal purpose, they won't give you the cert. I also recall StartSSL being incredibly difficult for those who only have a P.O. box for a mailing address (as was the case for me; my apartment didn't have a mailbox, so I had to receive all mail at a P.O. box, which StartSSL didn't like).
Re:Let's Encrypt Launch Schedule
by robertfw on Tuesday June 16, 2015 @01:47PM
(#9727510)
Be aware that the free cert does not support certificate transparancy. This will lead some browsers - notably chrome but I imagine there are/will be others - to give a user warning about SSL integrity. There are supposedly some workarounds [1] but no official support.
I want this project to proceed, but they should really focus on getting a much more mature and stable spec before launch. This isn't WebRTC, where you can just continuously tack on additional stuff or change the API constantly. It's TLS certs. The certs issued using this API end up telling people it's safe to input their passwords or credit card numbers.
I really hope the ACME spec gets stable before the launch in July.
[1]: https://github.com/letsencrypt/acme-spec/issues
[2]: https://github.com/letsencrypt/acme-spec/blob/master/draft-b...
I'm pretty sure they shouldn't tell users it's safe to type in credit card numbers -- these certs are "domain validation" (DV).
The certs that generate a green chip in the address bar are "extended validation" (EV) certs that typically cost hundreds and require a human to manually verify things.
[1]: http://security.stackexchange.com/a/15871
[2]: https://www.blackhat.com/presentations/bh-usa-09/SOTIROV/BHU...
There is an interesting HN discussion on the topic at https://news.ycombinator.com/item?id=8344238
It has to do with the security and accountability of the end-to-end process in which the certificate is used, which is a security concern even if you define "security of the certificate" so narrowly that it isn't relevant to the security of the certificate as such. (Though what you have a trusted third-party vouching for in the certificate -- which is the key distinction in EV -- is, I would think, by any reasonable standard, a factor in the security provided by the certificate.)
The cipher being used and the SSL configuration dictate MUCH more about the security of a site than its level of validation. EV certificates do not guarantee the site isnt using a insecure cipher. EV certificates do not guarantee that the private key was not sent via plain text in an email while a network admin was installing it. So from an encryption standpoint, there is no advantage.
From a authentication standpoint, an EV MAY provide more security but remember: An EV primarily validates the name and location of the relying party. It does not check to see if they are operating ethically or if you are getting ripped off.
I dont think EV is bad, but clamping down on what type of certificates can be used gets tricky. There are very few uses where EV (or OV) certificates should be required.
What's the hold up; HSMs that'll do secp256r1?
Because of the huge performance improvement ECDSA brings over RSA, I know I'm not going to be deploying Let's Encrypt certs until I can get ECDSA ones (as well as RSA ones, presumably).
What type of help is the Let's Encrypt team still needing?
Contributing to our software is one way to help:
https://github.com/letsencrypt/boulder
https://github.com/letsencrypt/lets-encrypt-preview
Also, if you work for a company that might be interested in sponsoring us, starting that conversation is another great way to help out.
[0]: https://letsencrypt.org/sponsors/ [1]: https://letsencrypt.org/become-a-sponsor/
https://www.alphassl.com/ssl-certificates/free-ssl-certifica...
[1] https://cheapsslsecurity.com/comodo/positivessl.html
The Let’s Encrypt client is essentially an operating system component. Generically, it requires root privileges to bind to port 443 and (if requested) to reconfigure your webserver for certificate installation and renewal
That also seems like a perfect compromise vector for bad actors to modify the client software.
The Let's Encrypt effort is noble and definitely required but I think they would have been better-focused and quicker to market had they concentrated on establishing themselves as a CA first and leaving the 'auto-configuration magic' to a later stage, for the small subset of users who want that.
But for me the biggest problem with adoption of SSL is still that every domain name needs it's unique IPv4 address, and all problems that come with that, not registering or paying for the SSL certificate.
At work, I usually use virtual hosting for about 100 domains on one IP address. I don't see us buying an IPv4 address per domain and adding them to my NIC configuration one by one. Once we can safely ignore IPv4 and use IPv6 only it will probably become easier and cheaper.
Anything so old that does not support SNI probably still uses SSLv3, or maybe even SSLv2, so you really should be upgrading that ASAP, rather than keep supporting it.
Only if you care about IE on Windows XP (which is no longer supported and no longer gets security updates) or Android phones more than 4 years old (2.3 Gingerbread and older). SNI works fine on other devices.
Have you measured? Do you have numbers for how many users you have running one of those two environments?
[1] http://www.movistar.com.ec/tienda/Marcas/Huawei/Huawei-Y210/...
https://code.google.com/p/android/issues/detail?id=12908#c2
All modern browsers support it, as do Nginx and Apache.
Also, who pays for all this infrastructure? Mozilla?
Sponsorship is provided by multiple companies, including Mozilla. See https://letsencrypt.org/sponsors/ and https://letsencrypt.org/2015/04/09/isrg-lf-collaboration.htm... for more.
For now, the certs are cross signed by "DST Root CA X3" operated by Identrust. This root has very strong inclusion.
For specifics, please see: https://groups.google.com/a/letsencrypt.org/forum/#!msg/clie...
https://www.comodo.com/e-commerce/ssl-certificates/free-ssl-...
An exception from that rule in the wake of Heartbleed would arguably have been appropriate, but the business model as such is in no way bad. If the whole SSL industry worked in a way that put price and cost in proportion, there would be no need for Let's Encrypt.
I think it's quite understandable that they charge for things that cost them money, but keep the rest free. You can't really expect for them to give out for free something that has a cost for them.
[1] http://korusdipl.egloos.com/6152770
(Root in Windows, Cross-Signed by StartSSL for others)
Advantages 1. No Expiration for 3 Years 2. 256-bit strong encryption with 2048-bit SSL certificate 3. Domain validation by trusted Root certificate authority. 4. Lowest price SSL
Get Comodo PositiveSSL Certificate at only $4.99/year from CheapSSLSecurity and make your self free from SSL Expiration.
Visit here for mode details - https://cheapsslsecurity.com/comodo/positivessl.html.