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 ?

Improve this question
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. Commented Jun 20, 2021 at 18:29

1 Answer 1

Reset to default
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.

Improve this answer
3
  • 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. Commented Jun 23, 2021 at 12:20
  • @SimonRichter In addition to the security issues, HTTP/2 breaks in various and subtle ways in this scenario. Commented Jun 23, 2021 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. Commented Jun 23, 2021 at 14:35

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.