6 ms·

And now try to load the same website over HTTPS

by zevv 1y ago

xrisk 1y ago
Yeah I think this computation doesn’t work anymore once you factor in the tls handshake.
aziaziazi 1y ago
From TFA: > Also HTTPS requires two additional round trips before it can do the first one — which gets us up to 1836ms!
- supermatt 1y ago
  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.
  - aziaziazi 1y ago
    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.
    - jeroenhd 1y ago
      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 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.
      - AStonesThrow 1y ago
        [dead]
mrweasel 1y ago
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.
- tech2 1y ago
  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.
  - jeroenhd 1y ago
    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.
    - tech2 1y ago
      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.
  - mrweasel 1y ago
    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.

And now try to load the same website over HTTPS

by zevv 1y ago

And now try to load the same website over HTTPS

xrisk 1y ago

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

aziaziazi 1y ago

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

supermatt 1y ago
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.
- aziaziazi 1y ago
  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.
  - jeroenhd 1y ago
    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 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.
    - AStonesThrow 1y ago
      [dead]

mrweasel 1y ago

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.

tech2 1y ago
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.
- jeroenhd 1y ago
  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.
  - tech2 1y ago
    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.
- mrweasel 1y ago
  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.