Freigeben über

How SNI Changed the Concept of Hosting HTTPS Web Sites?

  • Artikel

In this post I will start to get in details in IIS 8 so lets start with this nice feature SNI.  Lets have a quick look what will SNI add here, usually IIS Identifies a website by an IP, Port and Host name. However, this does not happen in secure websites. The TLS handshake happens before the server receives any HTTP
headers. So in TLS handshake firstly client send request and server reply with public certificate and hence client acknowledge. And then  client send an "Encrypted Request" and server reply with an "Encrypted Reply".

 So Now we understand that the problem is that we don't know which public certificate is needed till TLS handshake finish and client send the Http Request. IIS use the host name to identify right website and hence pick up the right certificate.

 Problem Before SNI on IIS 6,7.x:

In previous versions of IIS like IIS6,7,7.5 we were not able to configure multiple Host Headers with Https on same single IP. Previously IIS only allows you to bind one site on each IP address to port 443 using an SSL certificate. If you try to bind a second site on the IP address to the same certificate, IIS  will give you an error or will not start website. As you see below screenshot IIS lets you know that there is another website using this binding and certificate. 

And if you assigned and proceeded IIS will stop site

 

The only two options to host multiple SSL sites on IIS:

1)   Assign different IP addresses to different web sites. In that case you can assign different certificates to the different web sites because IIS can separate the web sites to serve for requests using the requested site’s IP address.

2)   Use SAN or  Wildcard  certificate to host multiple web sites on same IP address and port (e.g.:443) then you need to use SSL Host Headers to separate multiple web sites.

For SAN Certificate we would add multiple host names (Domains) or subdomains like Contoso.com, DagHc1,DagHc1.Contoso.com

 

If you are using the same IP address and the same port (e.g.: 443) then when the request arrives to IIS, it cannot understand which site is requested because the requested host name is also encrypted in SSL session. So, IIS first needs to decrypt the request to have the host name, then it can identify the correct web site because it would have the requested host name. In other words, IIS understands which site to be served after decrypting the request with SSL and then is able to send the request to the correct web site. This means that when the request comes to the web server, as IIS do not know which site to serve, IIS cannot verify which SSL certificate to
decrypt the request so there is a need to have just one certificate for decryption process with only one IP address and same port.

 For Wildcard certificate for example it would be *.Contoso.com and it will secure site1.Contoso.com, site2.Contoso.com, etc. 

 

 

Let me give you an example. Consider the following scenario:

  • site1.Contoso.com on  10.1.1.1, SSL port is 443, you have Certificate 1 assigned to the site.
  • site2.Contoso.com on 10.1.1.1, SSL port is 443, you have Certificate 2 assigned to the site.
  • Request is made to site1.domain.com.

 In this scenario;

  • Request is made to site1.domain.com but the “site1.Contoso.com” name is encrypted in the SSL session.
  • IIS receives the request but cannot understand which site to serve because the host name is also encrypted and IIS don’t know if the site1.Contoso.com or
    site2.Contoso.com is requested.
  • IIS should decrypt the request first. Now, the question for IIS is which certificate (1 or 2) should be used to decrypt the request. As the IIS cannot
    determine the correct site yet, it cannot decide which certificate to use (either Certificate 1 or Certificate 2). So it is not possible for IIS to decrypt the request to send the request to the correct site.
  • So, you will use the same SSL certificate (wildcard or SAN certificate) for all sites which share the same IP address and the same port (e.g.: 443)  but SNI completely changed this concept; you will know in the next post.

 In practice, this means that an HTTP server can only host one site per IP address for secured browsing.

 Finally, SNI is the solution for that; Server Name Indication (SNI) is an extension to the SSL and TLS that will help to know what hostname the client is trying to connect and this occurs at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and port number. Therefore we can host multiple secure (HTTPS) websites to be served on the same webserver over the same IP address. The last important thing that we must consider when use SNI; we have to make sure that client browser support SNI. Most browsers support SNI but some browsers not  For example, no
version of IE on Windows XP supports SNI.

 
In my next post I will explain in details how to use SNI.

Comments

  • Anonymous
    November 11, 2012
    That is a great news! Waiting for SNI post !

  • Anonymous
    November 12, 2012
    In my next Post I will explain in details how to use and configure SNI?

  • Anonymous
    December 02, 2013
    Please put link to blog about sni. Thanks.