3 ms·
AFAIK There was some effort to make this TLS 1.3 SNI header encrypted but some influential groups blocked that (I think I read something about ability to route
by therealmarv 9y ago
AFAIK There was some effort to make this TLS 1.3 SNI header encrypted but some influential groups blocked that (I think I read something about ability to route and control traffic easily). Really sad :(
- geofft 9y agoWhat do you encrypt the header to? Options include: - Start an encrypted unauthenticated conversation with the server first: that adds at least one extra round-trip, so most people won't do it, so it's easy to block all connections that do - Encrypt it to a key you have from the previous connection: doesn't help the initial connection and you already have session resumption for the rest - Encrypt it to a well-known "private" key: doesn't help at all The actual proposal for TLS 1.3 SNI seems to involve ... domain fronting. https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 (I assume that's so that it avoids the "it's easy to block" problem)
- icebraining 9y agothat adds at least one extra round-trip, so most people won't do it Eh, people will do whatever the TLS libraries have as default. Optimizing for an extra RT is way above what most app developers do.
- geofft 9y agoMost app developers, sure, but most web server developers are definitely going to optimize for it - the cost of an extra round-trip is immediately noticeable in benchmarks. And most app developers are running a pre-existing web server to proxy to their code (whether via HTTP to localhost / within the firewall, or something else like WSGI or FCGI), not linking TLS libraries themselves.