Doesn't this have the potential to interact really badly with SNI though? After all, TLS today is not "just" a security layer anymore. With SNI and ALPN it has

Doesn't this have the potential to interact really badly with SNI though? After all, TLS today is not "just" a security layer anymore. With SNI and ALPN it has also taken on quite a bit of routing functionality. E.g. suppose example.com has two subdomains, foo.example.com and bar.example.com. To simplify deployment, the site uses a central TLS gateway to terminate all connections to *.example.com and also uses a single wildcard certificate for all subdomains. The gateway then reads the SNI header to figure out which backend server it should proxy the connection to. This works perfectly fine as long as a browser only uses a connection for the subdomain that it announced in the SNI header. However, if it suddenly starts to make requests for a different subdomain on that connection, because both subdomains share the same IP (of the gateway) and cert (wildcard), requests will be routed to the wrong backend server and things will break. I'm not sure what the exact conditions for connection coalescing are in Firefox. If it's really as you say and the certificates have to be identical, then it's just a safety issue. However, if it's only required that the certs are signed for the same domain, then it could become a security issue as well: All you needed was to be on the same shared hoster as your victim and obtain a fraudulent cert for their domain and you can hijack some of their connections. Edit: Also, if the browser has a connection open to foo.example.com and wants to make a request to bar.example.com, how does it even obtain the cert for bar.example.com to decide if it can reuse foo's connection? It would have to open a new connection with SNI=bar.example.com, grab the cert - and then close the connection again and go back to foo's connection. What would even be gained by that?