Hacker News Reader

Comment by zevv | Hacker News Reader

And now try to load the same website over HTTPS

I know some people who are experimenting with using shorter certificates, i.e. shorter certificate chains, to reduce traffic. If you're a large enough site, then you can save a ton of traffic every day.

Please though, for the love of dog, have your site serve a complete chain and don't have the browser or software stack do AIA chasing.

With half of the web using Let's Encrypt certificates, I think it's pretty safe to assume the intermediates are in most users' caches. If you get charged out the ass for network bandwidth (i.e. you use Amazon/GCP/Azure) then you may be able to get away with shortened chains as long as you use a common CA setup. It's a hell of a footgun and will be a massive pain to debug, but it's possible as a traffic shaving measure if you don't care about serving clients that have just installed a new copy of their OS.

There are other ways you can try to optimise the certificate chain, though. For instance, you can pick a CA that uses ECC rather than RSA to make use of the much shorter key sizes. Entrust has one, I believe. Even if the root CA has an RSA key, they may still have ECC intermediates you can use.

The issue with the lack of intermediates in the cert isn't browsers (they'll just deal with it). Sure, if they aren't already in the cache then there's a small hit first time. The problem is that if your SSL endpoint is accessed by any programming language (for example, you offer image URL to a B2B system to download so they can perform image resizing for you, or somesuch) then there's a chance the underlying platform doesn't automatically do AIA chasing. Python is one-such system I'm aware of, but there are others that will be forced to work around this for no net benefit.

That is a really good point. Googles certificate service can issue a certificate signed directly by Google, but not even Google themselves are using it. They use the one that's cross signed by GlobalSign (I think).

But yes, ensure that you're serving the entire chain, but keep the chain as short as possible.

Yeah I think this computation doesn’t work anymore once you factor in the tls handshake.

From TFA:

> Also HTTPS requires two additional round trips before it can do the first one — which gets us up to 1836ms!

This hasn’t been the case since TLS1.3 (over 5 years ago) which reduced it to 1-RTT - or 0-RTT when keys are known (cached or preshared). Same with QUIC.

Good to know, however "when the keys are know" refers to a second visit (or request) of the site right ? That isn’t helpful for the first data paquets - at least that what I understand from the site.

Without cached data from a previous visit, 1-RTT mode works even if you've never vistited the site before (https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/#1-rtt-mode). It can fall back to 2-RTT if something funky happens, but that shouldn't happen in most cases.

0-RTT works after the first handshake, but enabling it allows for some forms of replay attacks so that may not be something you want to use for anything hosting an API unless you've designed your API around it.

Reply on news.ycombinator.com