Server Name Indication (SNI)

I was browsing through Yusuf’s blog today and read in his post about enabling cheaper SSL hosting for the first time about Server Name Indication (SNI), as specified in section 3.1 of RFC3546.

Anyone who’s had to set up an TLS/SSL (let’s say secure) site knows that currently, a secure site must be hosted on a unique IP. If you need to host more than one SSL site, you need to have separate IPs for each secure site hosted. This requirement is present because pre-SNI, the server name is negotiated based on the DNS hostname only. SNI elegantly works around this requirement by adding another step to TLS negotiation. As part of the TLS handshake, the client tells the TLS server which hostname it is trying to connect to, and the hostname thus knows which certificate to present to the client. This is explained a lot more elegantly by Paul Querna.

SNI makes life better because secure hosting becomes more affordable. The cost of a secure certificate is often no longer the largest cost that secure sites must bear to be secure. One can get a certificate for $20/year. However, dedicated IPs are expensive. On a host such as Dreamhost, unique IPs cost $4.95/month. Add this up and it’s almost $60/year. If this extra cost can be eliminated a lot more businesses might be tempted to go secure, and this is a good thing for everybody.

So what’s the current state of browsers?

• Opera: Already has full support for SNI as of 8.0
• Internet Explorer: Windows Vista adds full support for SNI
• Gecko/NSS: Not yet, but bugs 116168 and 116169 have been filed.

It’s no secret that as far as end users are concerned, backend features are not as sexy as features which are exposed in the UI, but I wonder whether if SNI support is added to Gecko/NSS before IE, if Firefox will suddenly become a lot sexier to businesses who don’t have an arbitrarily large IP space but are looking to standardise on a browser, or recommend one to their clients. Hey, it’s a much better solution than forcing an upgrade to Vista.