Looking Forward to 2018 | Hacker News Reader

Looking Forward to 2018

letsencrypt.org

269 pointsl1n60 comments

> We pride ourselves on being an efficient organization. In 2018 Let’s Encrypt will secure a large portion of the Web with a budget of only $3.0M.

I sincerely hope that they don't become like Wikimedia with their ever-increasing scope and bureaucracy. And it might work because Let's Encrypt has a rather specific mission (free TLS certs for everyone), whereas Wikimedia has a rather broad mission (free knowledge/data for everyone).

And for this reason I frowned upon the upcoming wildcard certificates. Adding a new product would cost them, no? I had previously read that wildcard certificates are a non-issue, if the specific certificates are free anyway, as is the obvious case with Let's Encrypt.

wildcard certificates is really only thing missing in their offering. It definitely makes sense for them to also disrupt and offer a quality, more-efficient alternative here.

It's an extension of their offering rather than a new product.

For small deployments you're right. If you have a lot of subdomains coming and going you will hit the Lets Encrypt rate limits real fast. They're generous enough, but I've hit them quite a few times. For certain use cases a wildcard cert just makes way more sense.

One of the things that's very, very difficult with individual certificates and LetsEncrypt's rate limits is to provide subdomains per-customer without leaking details (e.g. usernames) of other customers. If you don't want bob.example.com and alice.example.com on the same certificate, you can have a grand total of 20 users before you hit the rate limits.

This also affects systems like Sandstorm, which use randomly generated, unguessable subdomains per user session per "grain" (document), which may have (small) privacy concerns in some cases. Certificate Transparency would publicly publish every subdomain generated, even if the rate limits weren't a thing.

Wildcard certs really aren't that much trouble to implement. They are more or less removing a restriction that prevented you creating a cert for "*.example.com"

In the long run it might actually save them money by cutting down on the total number of certs their system has to verify and sign.

Letsencrypt has made my live easier... So, don't forget to donate, if it helps you: https://letsencrypt.org/donate/

Don't forget the past :)

> the Web went from 46% encrypted page loads to 67% according to statistics from Mozilla - a gain of 21% in a single year

No no no... That's a gain of 50% (give or take) or 21 percentage points; not a gain of 21%.

The broader problem is that expressing changes as percentages is often intrinsically ambiguous. I'm not sure that the way you're choosing to signal the difference is widely appreciated or understood.

It depends on what do you mean by "widely understood". People that deal with numbers know the difference, but other can just read Wikipedia, see https://en.wikipedia.org/wiki/Percentage_point

It may be similar to people not feeling the difference between causation and correlation.

It is a common mistake, I remember that not so long ago my government (Spain) had to amend a law because the initial text incorrectly said % instead of percentage points.

Why are you calculating the gain out of 46% and not out of 100%?

It clearly doesn't talk about the gain of a percent of a percentage.

Percentage changes are a scaling factor against the previous number. 1-(new/old) is how it should be calculated. So even though they are comparing two percentages, they can't directly subtract them (new - old). Percentages describe _relative_ change.

Unlike with e.g. prices, the sum total of all web traffic provides a natural ceiling, so new/old (multiplicative) and new/total (additive) are both defensible.

Sure, but you need to be clear about what you're representing. Saying X% implies (because of the % sign and what percentages are...) that its multiplicative while percentage points implies additive (and the article used the %, which made it sound multiplicative, but in reality used the additive value -- lots of confusion!)

People often (incorrectly) use "%" instead of writing out "percentage points". Percentage points increase is the correct figure to use here I think, it's more informative to state that the increase is 21 percentage points than that the improvement is ~50%.

Good point, thanks. We just pushed a fix for that language, should show up live shortly.

I think they're underestimating the growth they're going to get when they implement wildard certificates and the word truly gets out :)

uh, why?

shouldn't it get less again? if i use ~8 certs for different servers, i could just get a wildcard for my domain and be done with it...?

Growth in number of sites secured, not in number of certs issued.

To be honest it is easy to do multi-sub domain certificates already. Wildcard certificates will only make my life more simple. But unless you need a huge number of sub domains, or dynamic sub domains, it's not really going to change that much.

If anything it will reduce the strain on their servers. Instead of authorising subdomain by subdomain there will be a single authorisation by domain.

It's possible, but a couple of points to consider:

1) Wildcards may have a net negative effect on total issuance if subscribers who were getting many non-wildcard certificates before replace them with a single wildcard. I'm not sure this will be the case, but it could be. I expect wildcards will help move many more sites to HTTPS - perhaps just with fewer actual certs.

2) Wildcard validation from Let's Encrypt will be restricted to DNS validation, and many people don't have the ability to automate modifications to their DNS records. That being the case, it will be a bit more difficult to validate for wildcard certificates than for non-wildcards.

Are full ECDSA chains going to depend on the upcoming Let's Encrypt ECDSA root being in the client trust store or is there going to be cross-signing?

Good question. We are hoping to have a cross-sign from a widely trusted ECDSA root in place. It's non-trivial to make that happen, and it's part of the reason this feature is taking longer than we had hoped.

I hope to see more built-in integration with Apache and Nginx web servers.

NixOS [1] actually has really great nginx integration with just a single line [2]:

    enableACME = true;

This automatically does the ACME thing and sets up systemd units to renew the certificate. Have been using it a while for my (sub)domains and it's worked really well.

[1]: https://nixos.org/

[2]: https://nixos.org/nixos/options.html#%3Cname%3E.enableacme

I know it's not directly what you've asked for (it's neither apache nor nginx), but the Caddy webserver does just that - almost 0 configuration dealing of the ACME part, auto-redirection from http to https. You still need to tell it what your domain name is, but barely (there's some DNS plugins that make it truely 0 config).

https://github.com/mholt/caddy

(I'm not affiliated, just a happy user)

Does caddy still stop the server if it can't access Let's Encrypt service even though certificate is valid?

The bug you're thinking of was Caddy would refuse to /start/ if the certificate needed renewing and Let's Encrypt was down.

They fixed that so that it has three weeks grace. Now only if you switch off the server wait until the cert has almost expired (say five days left) then switch it on, Caddy will go "eek, time to renew" and if Let's Encrypt is down it'll give up and the server doesn't start.

This means either Let's Encrypt was down for longer than a decent summer vacation or you switched off your own web site for weeks. Neither of those is a good idea.

No, Caddy never did that. Caddy never stopped serving a site that it started serving. Only by shutting down the server (or sending the appropriate signal) would it stop serving the site.

Check out mod_md. It's upstreamed in Apache now.

Setup for Apache with certbot was basically one command. Was even easier than copying and configuring existing SSL certificates.

So think that qualifies as a good integration.

The (beta) nginx certbot-auto module works flawlessly for me.

Funny trivia. Recently, our firewall was blocking a ton of smaller websites. Wasn't sure why. Finally got on the phone with Sophos (our firewall manufacturer) to figure out what was going on. Support guy led me through some troubleshooting steps, we discovered that it's blocking Lets Encrypt certificates for whatever reason. He agreed with me that's strange and he'll look into why Lets Encrypt is getting blocked. So strange. Not related to anything at all, just topical trivia.

At a guess, Sophos isn't/wasn't trusting Let's Encrypt's own root certificate (only their cross-signed ones).

I wonder why they do not user their own certificates?

https://letsencrypt.org reports Identrust.

Probably because they got a certificate before their own certificates were widely accepted?

At first I thought it might be so that you could still access their website for support if you had an issue with their CA.

However it seems that https://community.letsencrypt.org/ which would seem a good place to get help is actually using one of their certificates so maybe it's just historical. The certificate dates back to 2015 and expires in next February, maybe they'll replace it by one of their own then.

We set that up before we were an operational CA and it has just never been a high enough priority to replace it. The team that would do it has a lot of other things to do. We'll get around to it at some point.

Probably not a bad idea to use another CA for that.

I know they are planning wildcard already (as per article), I'm just keeping my fingers crossed we will see code signing and others before too long...

I understand though, code signing will be much harder to automate and maybe not so fit for purpose...

Out of curiosity, how would you implement the authorisation? Would you tie it to a domain? Would that even make sense?

You could go the keybase route and tie in with various platforms using anywhere that you can post a public message to post "proof".

So if you wanted to sign a windows executable, you'd need to have a microsoft account, and that microsoft account would need a place that you could publicly post a string of text.

Then it's up to the Lets Encrypt service to validate that and cut the certificate

Code signing certificates are essentially EV certificates (in terms of validation required), so I doubt they'll be free anytime soon.

Does LE support listing an IP address in a certificate instead of domain names?

While Letsencrypt is doing a good thing, but what if it will stop issuing free certificates?

Then we will not be worse off than we were before.

We would be better off, since there now exists a protocol and extensive tooling for automatic certificate management.

This allows a competitor (even a commercial) one to fill in the gap left by letsencrypt if they stop issuing certs.

In the short term, some will be worse off, because their current certificates will be valid somewhere between 30 and 90 days, instead of the 0 to 365 that is common with traditional certificates.

Still, it's worth it. I have some private sites that now have TLS thanks to let's encrypt, which were plain HTTP before.

I still wish for a second free, automated CA. Just to have redundancy.

Why would they?

They would if they ran out of money. There's a donate button at the bottom of the post...

LetsEncrypt has, as the post said, a super tiny (compared to their massive positive impact) budget of just $3 million dollars and the largest companies of the web as backers.

They're never gonna run of of founds - their backers (Mozilla, Akamai, OVH, Cisco, Google, EFF,++++) would never let them.

I could see a situation where, for instance, they do a security audit and are convinced that they need to significantly up their physical or network security to prevent a potential attack.

There's also the possibility of their competitors pushing an agenda with standards bodies that pushes up the cost of PKI to try to freeze them out.

If they charged a token amount I don't think it would be so bad (except for the whole getting it through the bean counters problem), but it would be more lucrative for them to charge people money for raising the rate limits in their system.

Certain people like Akamai are charging exorbitant amounts to manage large numbers of SSL certificates. Just look at their quarterly revenue, it's insane. Other providers could partner with LetsEncrypt and undercut them substantially enough that they could steal customers, but it might mean LetsEncrypt has to scale up their operational limits to do so.

Reply on news.ycombinator.com