3 ms·

This doesn't seem like a good solution from any angle. Do we need to change TCP/IP/whatever to actually allow network traffic to be secure again?

• therealmarv 8y 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 8y ago
    What 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 8y ago
      that 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 8y ago
        Most 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.
• deleted 8y ago
  [deleted]