SNI :: Why not?
SNI or Server Name Indication is a technology that would allow hosting providers to service many SSL Virtual Web Hosts on a single IP with out resorting to proxies or hackish use of non-standard https ports. It is described by RFC 4366. It was submitted in 2003 and finalized in 2006. The extensions in some implementations are added on to TLS 1.0 and in others TLS 1.1 must be enabled.
More info here.
I am interested in this technology because it will ease provisioning and server portability immensely, and save IPv4 address space, which everyone should be concerned about right now. *cough* no move to IPV6 in sight *cough*
So why is deployment unrealistic at this time?
Culprits:
ASF (Apache Software Foundation) :: Apache Httpd mod_ssl
Bug has been filed since 2005-04-25
Workable patches were submitted and committed to trunk (2.4) on 2007-12-21
Patch for 2.0 was rejected shortly there after patch for 2.2 backport was submitted on 2008-01-09
Apparently support wasn’t gained for a backport to either 2.0 or 2.2
There was one more request and backport patches submitted on 2008-01-11
This was met with silence
The saga is here.
So I guess we can hope for 2.2.11, or just wait for 2.4.
UPDATE: AS OF 2.2.12 SNI WORKS IN APACHE YAY!
Micro$oft :: IIS
Pretty strange that IIS doesn’t support SNI considering the fact that IE 7 on Vista (not XP) does. So apparently this is implemented in some system level DLL that no one wants to touch.
SUN :: Java System Web Server
Does not have support for SNI. This is an odd one, I can’t believe the most feature packed web server on the planet doesn’t support SNI.
It is worth noting that server uptake doesn’t much matter, unless of course you want to take advantage of the feature, and your Http server of choice doesn’t support it. Mine just happens to be Apache.
Apple :: Safari 3 on Mac OS X (works on Vista) UPDATE: AS OF 3.2.1 and OS X 10.5.6 SNI WORKS IN SAFARI YAY!
Most major browsers have had support for SNI since 2006. Why it has taken Apple nearly 3 years to implement it is beyond me. But they do have a bug filed in their internal system (which isn’t public), and those of us that are ADC members can track it with bugID: 6062854
Micro$oft :: IE 6 on Windows XP
This is a problem mostly due to the massive failure of Vista in general (Vista + IE 7 supports SNI). If Vista uptake had been better we would probably be seing the end of XP workstation deployments. Since the reverse is true (XP downgrade anyone?) we are going to have to wait even longer for SNI uptake because it doesn’t look like MS will backport support to XP.
Perhaps some of you Microsofties out there can file bug reports in the appropriate places and make something happen.
KDE :: Konquerer
Might support it and might not depending on the OpenSSL version it is linked against? Hard to tell from the filed bug.
Lynx
UPDATE lynx2.8.7pre.2 onwards contains SNI support if built against OpenSSL which supports SNI
Sun Java :: JSSE
I list this because there is a lot of web related stuff written in Java. Sun plans to add support in JDK7. Hopefully that is not far off. There is partial support in JDK 6 so that is good. I found this out by browsing through the Java source code, how sweet of them to have it searchable online!
Micro$oft :: .Net
UPDATE .NET’s SSLStream class will send SNI and other TLS extensions on Windows Vista and later (see comment below)
After digging through the mess that is MSDN it looks like the native .Net 3.5 ssl provider does not have support. Which once again I find to be odd considering that Vista has support for it. I am not 100% on this because I can’t look at the TLS handshake code so someone correct me if I am wrong.
Who/What Does Support SNI?
OpenSSL 0.9.8f+ must be compiled with enable-tlsext
gnuTLS 2.0+
curl 7.18.1 or later
Mozilla NSS
Mozilla Firefox 2.0
IE 7 Vista only
Safari 3 Vista – Safari 3.2.1 + Mac OS X 10.5.6+
Opera 8.0
Google Chrome
Apache with mod_gnutls
Cherokee (going to have to keep an eye on this guy)
lighttpd 1.4.x and 1.5.x
Nginx if linked against OpenSSL compiled with support
So give those fellows a pat on the back!
What can you do?
Well you can visit the appropriate bug systems and mailing lists and ask for support. If you are a member of the respective communities you can vote for the bugs listed. If your bug/feature system is private you can file a feature/bug request.
Seriously we are about 3/4 of the way to making this usable by most individuals. If the big players listed above step into line, all the little utilities and libraries will follow.
This technology will enable us to really up the usage of SSL/TLS by lowering the provisioning costs and simplifying configuration. So help make the Internet a better place!!! Complain to someone today!!