0

Context: IIS website with hostname header configured and TLS certificate.

When a client initiates a connection to the specified site, is this the right flow ?

  • Client (browser) performs DNS lookup
  • TCP connection is established to the server
  • Client (browser) constructs the TLS payload where it include the SNI which is the site name and begins the handshake with the server
  • Server looks for the certificate with the specified name in its site bindings list of certificates and responds back
  • Once TLS is established, the IIS webserver routes the HTTP request to the specific site using the HOST header value.

As per my understanding, the SNI is the base information for the server to lookup for the certificate of the site.

What does it happen if after the TLS handshake I actually modify the HTTP Host header to target a different website ? Is this possible ?

Dave M
  • 4,494
  • 21
  • 30
  • 30
Mario
  • 3
  • 1
  • “I actually modify the HTTP Host header to target a different website” is not clear enough. Ask yourself where you can modify Host header, and then you should see the actual possibility. Usually you can only modify that header on browser side, then you lose control as the browser takes it over and initialize another TLS connection to the other site. – Lex Li Jun 20 '21 at 18:29

1 Answers1

0

RFC 6066 section 11.1 says, in part:

Since it is possible for a client to present a different server_name in the application protocol, application server implementations that rely upon these names being the same MUST check to make sure the client did not present a different name in the application protocol.

How web servers actually do this can vary. Apache and nginx both reject such connections outright, though strangely Apache has an option to turn this off. No idea what IIS does, but hopefully it is sane. You can easily test it yourself.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • The clause "that rely on these names being the same" is doing a lot of work here. It is sufficient to ignore the name from SNI outright and only process the `Host:` header to get a conforming implementation, and my expectation would be that this is the norm with dedicated TLS gateways where the TLS connection does not even reach the server. – Simon Richter Jun 23 '21 at 12:20
  • @SimonRichter In addition to the security issues, HTTP/2 breaks in various and subtle ways in this scenario. – Michael Hampton Jun 23 '21 at 12:25
  • The only security issue is that if you use SNI to distribute traffic across multiple machines, you can send a request to a machine that does not have that particular host name configured, that is a fairly low threat (but the most annoying to defend against). If the same machine terminates TLS and processes the request, throwing away the name from SNI does not expose any additional attack surface -- all you can do is talk to a host you could also talk to by using the right name in SNI. – Simon Richter Jun 23 '21 at 14:35