4 ms·

Not if they still fit within one TCP packet per side of the handshake.

by koolba 6y ago

toast0 6y ago
Most physical transports don't pad packets to the maximum size. Ethernet only pads if you're below 46 bytes of payload, which is smaller than TCP packets with TCP timestamps; so if you're on Ethernet and have TCP timestamps enabled (which is very common), you'll certainly see the savings from any bytes removed from your certificate; unless your TLS layer is padding out to (path) MTU. Assuming that's in the neighborhood of a 20 byte savings, it's not very significant. Using EC keys rather than RSA keys if possible is a bigger savings. And disabling TCP Timestamps, which add 12 bytes per packet (including ACKs) would be bigger still[1]. That said, shaving off bytes wherever possible adds up. [1] I've heard that disabling TCP Timestamps may disable receive window scaling on iOS (and maybe macos), see [2] for a report. It's also very useful to avoid problems with wrapped sequence numbers if your (bytes/time * assumed maximum segment lifetime) is anywhere near 32-bits; this usually requires around a gigabit on a single TCP connection. As the link mentions, tcp timestamps do make retransmits have different content than the original send, which can incidentally help if you have broken networking equipment on your path, depending on the details of the brokenness. [2] https://www.snellman.net/blog/archive/2017-07-20-s3-mystery/ https://www.snellman.net/blog/archive/2017-07-20-s3-mystery/
- tialaramex 6y ago
  > unless your TLS layer is padding out to (path) MTU I'd actually like to see more servers doing this. In TLS 1.3 it's actually free (in earlier versions signalling the intention to pad costs some space so it's possible you've got some free space but not enough to add padding without using a whole extra packet), but in TLS 1.3 as a side effect of other changes needed you can add any number of empty padding bytes to a record). This means an adversary loses some precision in estimates of your payload size from size of TLS transfer, which may reduce their ability to fingerprint these payloads. > That said, shaving off bytes wherever possible adds up. If this matters (and I'm not convinced it does when you aren't shaving off whole packets or making space for something else) other tricks you can do: * Arrange to obtain unlogged certificates from your issuer. To be trusted by browsers and perhaps in future other clients, your certificates must have proof they were logged in the Certificate Transparency system, most issuers will sort this out for you, log certificates and bake the resulting proofs inside your certificate. But this makes the certificate bigger, you can legitimately obtain certificates which aren't logged, log them yourself, and hand over the resulting proof only to clients that insist on seeing it, thus saving bytes * Implement the certificate compression feature RFC 8879. Many clients today don't do this, but more will over time, this TLS 1.3 feature lets you compress the certificate before sending it to a client that understands how to decompress it. * Use smaller keys (2048-bit RSA but more importantly if possible a smaller elliptic curve key) * Get short names for things, only use those names. A certificate for some.short.example and longer-name.our-company-is-famous.example is worse, because that has both names in it, but if you can get OK to just use some.short.example that's saving a few bytes even if you only have SANs and no Common Name at all. * Get issuer to disable unnecessary verbiage. Many certificates are full of disclaimer text and needless baggage. Does your issuer realise those cost you money? Does this site need to say YCombinator is in San Francisco which is in California? Does anybody who cares check the certificate? This sort of thinking is why Let's Encrypt's replacement for "Let's Encrypt X3" is just named "R3". We know which CA made it, so why waste bytes saying so twice?
  - toast0 6y ago
    >> unless your TLS layer is padding out to (path) MTU > I'd actually like to see more servers doing this. In TLS 1.3 it's actually free (in earlier versions signalling the intention to pad costs some space so it's possible you've got some free space but not enough to add padding without using a whole extra packet), but in TLS 1.3 as a side effect of other changes needed you can add any number of empty padding bytes to a record). This means an adversary loses some precision in estimates of your payload size from size of TLS transfer, which may reduce their ability to fingerprint these payloads. Yeah, I think this is a good use of not entirely needed bytes. Even though it's way more bytes than repeating one of the hostnames. Of course, it puts more emphasis on path MTU working, especially if the client does it too. It seems very likely the server side of the handshake will easily fill at least one whole packet, unless you've got jumbo packets or terrible packetization.

Not if they still fit within one TCP packet per side of the handshake.

by koolba 6y ago

Not if they still fit within one TCP packet per side of the handshake.

Most physical transports don't pad packets to the maximum size. Ethernet only pads if you're below 46 bytes of payload, which is smaller than TCP packets with TCP timestamps; so if you're on Ethernet and have TCP timestamps enabled (which is very common), you'll certainly see the savings from any bytes removed from your certificate; unless your TLS layer is padding out to (path) MTU. Assuming that's in the neighborhood of a 20 byte savings, it's not very significant. Using EC keys rather than RSA keys if possible is a bigger savings. And disabling TCP Timestamps, which add 12 bytes per packet (including ACKs) would be bigger still[1]. That said, shaving off bytes wherever possible adds up. [1] I've heard that disabling TCP Timestamps may disable receive window scaling on iOS (and maybe macos), see [2] for a report. It's also very useful to avoid problems with wrapped sequence numbers if your (bytes/time * assumed maximum segment lifetime) is anywhere near 32-bits; this usually requires around a gigabit on a single TCP connection. As the link mentions, tcp timestamps do make retransmits have different content than the original send, which can incidentally help if you have broken networking equipment on your path, depending on the details of the brokenness. [2] https://www.snellman.net/blog/archive/2017-07-20-s3-mystery/ https://www.snellman.net/blog/archive/2017-07-20-s3-mystery/

tialaramex 6y ago
> unless your TLS layer is padding out to (path) MTU I'd actually like to see more servers doing this. In TLS 1.3 it's actually free (in earlier versions signalling the intention to pad costs some space so it's possible you've got some free space but not enough to add padding without using a whole extra packet), but in TLS 1.3 as a side effect of other changes needed you can add any number of empty padding bytes to a record). This means an adversary loses some precision in estimates of your payload size from size of TLS transfer, which may reduce their ability to fingerprint these payloads. > That said, shaving off bytes wherever possible adds up. If this matters (and I'm not convinced it does when you aren't shaving off whole packets or making space for something else) other tricks you can do: * Arrange to obtain unlogged certificates from your issuer. To be trusted by browsers and perhaps in future other clients, your certificates must have proof they were logged in the Certificate Transparency system, most issuers will sort this out for you, log certificates and bake the resulting proofs inside your certificate. But this makes the certificate bigger, you can legitimately obtain certificates which aren't logged, log them yourself, and hand over the resulting proof only to clients that insist on seeing it, thus saving bytes * Implement the certificate compression feature RFC 8879. Many clients today don't do this, but more will over time, this TLS 1.3 feature lets you compress the certificate before sending it to a client that understands how to decompress it. * Use smaller keys (2048-bit RSA but more importantly if possible a smaller elliptic curve key) * Get short names for things, only use those names. A certificate for some.short.example and longer-name.our-company-is-famous.example is worse, because that has both names in it, but if you can get OK to just use some.short.example that's saving a few bytes even if you only have SANs and no Common Name at all. * Get issuer to disable unnecessary verbiage. Many certificates are full of disclaimer text and needless baggage. Does your issuer realise those cost you money? Does this site need to say YCombinator is in San Francisco which is in California? Does anybody who cares check the certificate? This sort of thinking is why Let's Encrypt's replacement for "Let's Encrypt X3" is just named "R3". We know which CA made it, so why waste bytes saying so twice?
- toast0 6y ago
  >> unless your TLS layer is padding out to (path) MTU > I'd actually like to see more servers doing this. In TLS 1.3 it's actually free (in earlier versions signalling the intention to pad costs some space so it's possible you've got some free space but not enough to add padding without using a whole extra packet), but in TLS 1.3 as a side effect of other changes needed you can add any number of empty padding bytes to a record). This means an adversary loses some precision in estimates of your payload size from size of TLS transfer, which may reduce their ability to fingerprint these payloads. Yeah, I think this is a good use of not entirely needed bytes. Even though it's way more bytes than repeating one of the hostnames. Of course, it puts more emphasis on path MTU working, especially if the client does it too. It seems very likely the server side of the handshake will easily fill at least one whole packet, unless you've got jumbo packets or terrible packetization.