Let's Encrypt Launch Schedule | Hacker News Reader

Let's Encrypt Launch Schedule

letsencrypt.org

233 pointsjoshmoz66 comments

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.

[1]: https://github.com/letsencrypt/acme-spec/issues

[2]: https://github.com/letsencrypt/acme-spec/blob/master/draft-b...

> 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.

EV certificates are no different from normal SSL certs. They offer no extra security. References:

[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'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.

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.

> 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.)

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.

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).

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?

Glad you like the project!

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.

What are the tiers for corporate sponsors?

The tiers are Platinum, Gold, and Silver. Check out the current sponsors [0] and info on becoming a sponsor [1].

[0]: https://letsencrypt.org/sponsors/ [1]: https://letsencrypt.org/become-a-sponsor/

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.

Can someone summarize why this is better than, say, StartSSL or AlphaSSL?

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).

Looks like the free offer from AlphaSSL is no more:

https://www.alphassl.com/ssl-certificates/free-ssl-certifica...

Sorry, I meant free ([unlike] AlphaSSL])

Are you sure about that $3-4 price point? The cheapest I'm seeing on their site is $49/yr.

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.

[1] https://cheapsslsecurity.com/comodo/positivessl.html

Namecheap sells PositiveSSL certs for $9, I'm sure others are in that price range as well.

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.

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.

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.

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.

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.

SNI has been a thing for a long while now.. Do you seriously need to support older browsers than this? https://en.wikipedia.org/wiki/Server_Name_Indication#Web_bro...

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.

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.

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.

> 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?

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.

[1] http://www.movistar.com.ec/tienda/Marcas/Huawei/Huawei-Y210/...

What's depressing is that 2.3 already had an API that would use SNI, but they didn't update the stock browser to use it :|

https://code.google.com/p/android/issues/detail?id=12908#c2

That's exactly why I asked about measurement; just because such users exist doesn't mean they use your site, or buy anything from it.

Use SNI, Server Name Indication: https://en.wikipedia.org/wiki/Server_Name_Indication

All modern browsers support it, as do Nginx and Apache.

Thanks for the info, eirst time I hear about this. I'll look it up. I'm honestly a bit ashamed I haven't heard about this before.

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.

OK, that's very nice.

can someone clarify if revokation is free with letsencrypt?

Also, who pays for all this infrastructure? Mozilla?

All the services provided by Let's Encrypt will be completely free, including revocation.

Not sure about revocation.

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.

Do Chrome and Mozilla have Let's Encrypt in their Root stores? I don't see them.

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.

For specifics, please see: https://groups.google.com/a/letsencrypt.org/forum/#!msg/clie...

Dangit, I didn't read the second paragraph. For GA, they will have the cross-sign. It's just for the EA that they don't.

They're cross-signed by DST Root CA X3 which is in the list.

Damnit, my existing cert expires September 12. Any free alternatives to that?

Comodo has a 90 day free SSL trial that should get you through that window.

https://www.comodo.com/e-commerce/ssl-certificates/free-ssl-...

RapidSSL also offers a free 30-day certificate: https://www.freessl.com/

https://www.startssl.com/ provides free domain-validated certificates.

Please don't use startssl. Revocation costs money, and the company's behavior surrounding heartbleed was at the very least very unethical.

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.

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.

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.

How does an automated revocation cost them money?

https://blog.cloudflare.com/the-hard-costs-of-heartbleed/

What about every other certificate issuer, whose up-front fees incentivize companies to not encrypt data in the first place?

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.

In which case if you don't want to pay for revocation, you could just revert back to an unencrypted connection.

> 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.

I am thinking that they should adopt short lived certificates.

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).

The issue is you have to pay for revocation.

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.

[1] http://korusdipl.egloos.com/6152770

Chrome only downgrades EV to non-EV without SCTs. You can always send them yourself via the TLS extension method.

https://buy.wosign.com/free/

(Root in Windows, Cross-Signed by StartSSL for others)

Namecheap sells basic Comodo certs for $9.00/yr.

If you worried much about expiration of your free SSL certificate, I advise you to invest some $ on domain validated SSL certificate.

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.

Reply on news.ycombinator.com