Hello Willy,
On 25 April 2018 at 12:16, Willy Tarreau <w...@1wt.eu> wrote: >> I'm not even sure that differentiate "Host" header from SNI values is >> possible on softwares like Nginx or Apache. > > It should not, that would be a violation of HTTP over TLS. I think I disagree. This is very possible and in fact happens everyday. When the certificate has SAN's for www.example.org and mail.example.org, a browser uses a single TLS connection to access both domains - SNI will be whatever HTTP request warranted the TLS session in the first place (as SNI is only send in the TLS handshake's client_hello). This only breaks when people try to content switch HTTP transactions that should be based on the Host header and look at the SNI header instead (which I'd argue is a layering violation). SNI should imho only be used for certificate selection at the TLS server endpoint/layer and best not be carried to upper layers. This is not limited to H2, I believe browsers do it in HTTP/1.1 as well, but here's the H2 RFC documenting this behavior [1]. H2 also introduces a new error code for servers unable to handle this, which is 421 [2]. Yes, at the end of RFC6066 section 3 [3] there is a SHOULD NOT about this. But it doesn't specifically address the HTTP use-case and it's not a MUST NOT. It doesn't make sense for a browser to throw away an already validated TLS sessions for which the hostname matches a SAN from the validated certificate. Let's not make the FTP mess again and pull lower layer transport (or transport encryption) variables up into the application layer. Let the TLS server endpoint pick the certificate based on SNI and then stop looking at it would be my general advice. When TCP proxying TLS traffic and content switching based on SNI, one needs to make sure that the certificates do not overlap because of this connection reuse (just to provide another perspective), see [4] and [5]. cheers, lukas [1] https://tools.ietf.org/html/rfc7540#section-9.1.1 [2] https://tools.ietf.org/html/rfc7540#section-9.1.2 [3] https://tools.ietf.org/html/rfc6066#section-3 [4] https://discourse.haproxy.org/t/sni-routing-to-servers-only-ever-sent-to-first-server/1265/4 [5] https://discourse.haproxy.org/t/h2-problem-with-multiple-backends/1650
