Hi Lukas, On Fri, Apr 27, 2018 at 01:56:42AM +0200, Lukas Tribus wrote: > Hello Willy, > > > On 25 April 2018 at 12:16, Willy Tarreau <[email protected]> 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).
You're absolutely right. > 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. Totally agreed, and I remember that both of us have been warning certain people against the risks of using SNI for L7 switching. > 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. I remember following a conversation on this exact subject on the HTTP WG, though I didn't catch all the details. But it's true that in general browsers will try hard to reuse existing connections as long as possible. > 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. Please note that we were discussing about the other way around, how to automatically set SNI based on the Host header field, which is what browsers and proxies normally do. However, this discussion made me think about a case where we do not want to do this : if a browser connects to a proxy using TLS (to protect user authentication), the advertised SNI should not be the one from the Host header field but the one matching the proxy host name, which doesn't appear in the request and cannot be deduced. This is a good example showing that we can't have SNI always deduced from the request. > 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]. Agreed. In my opinion, SNI-based switching is only usable when you know that the certificates do not overlap. But in practice that's often the case initially, until someone renews the certs with multiple SANs for some purpose and starts to break everything. Cheers, Willy
