4 ms·
This is great. I think SNI is currently one of the most pragmatic tools to work around ipv4 exhaustion. I like the approach described here, but in practice I p
by anderspitman 4y ago
This is great. I think SNI is currently one of the most pragmatic tools to work around ipv4 exhaustion.
I like the approach described here, but in practice I prefer the convenience of having a reverse proxy to automatically handle TLS certs for me. That said, libraries like certmagic are making it more feasible for every app to manage its own certs.
- ignoramous 4y ago> I think SNI is currently one of the most pragmatic tools to work around ipv4 exhaustion. Pretty much: https://research.cloudflare.com/publications/Fayed2021/ https://research.cloudflare.com/publications/Fayed2021/ See also, DNS SVC (A/B) records (pseudo NAT at DNS layer); but not many deployments use it or understand it. Note that, SNI as a routing replacement works for TCP nicely without much (user-space) complication. With QUIC, transparently proxying connections isn't all that straight forward.
- anderspitman 4y agoThanks for the link. What exactly are the issues with QUIC? I've wondered if it's possible to do SNI routing with UDP but haven't looked into it yet.
- ignoramous 4y agoQUIC hides and encrypts everything it possibly can, and that includes server and client identities (IPs are inconsequential to a QUIC session which is instead maintained through connection-id(s) exchanged under TLS encryption or is obfuscated away; that is, there is no way for a middleware to analyse a QUIC session / flow without actually MiTMing TLS). More: https://lwn.net/Articles/745590/ https://lwn.net/Articles/745590/