Google Creating A Killer App For IPv6?

| 9 Comments
Google recently released a SSL enabled version of their main page, which is no bad thing. However it turns out there's a bit of a nasty side effect for companies doing search analytics. When you go from an SSL site to a site without SSL, most modern browsers will stripe out the referrer data. In the case of going from an SSL enabled Google to a normal non-ssl site, it means that the non-ssl site will have no idea of what search terms were used.

Of course there is a way around this. The simplest is just to SSL enable the site. If you go from one SSL enabled site to another SSL enabled site, the referrer data is retained. There are other such as Google appending something like ?query="search term" to each url it returns, however even if this is implemented I can see it being an optional for the user.

Of course the problem with SSL certs is that you need a dedicated IP Address for each SSL enabled site. There's extensions to TLS which would mean that you could host multiple name based virtual hosts on one IP, see Section 3.1 of RFC3546, but I have yet to see significant support for this. As it stands at the moment, IPV6 is probably better supported than the Server Name Indication extension of TLS.

So, if a company wants a fast way of getting the referrer from an SSL Google query, the handiest method is probably to SSL enable their site, which means a dedicated IP address. Anyone who has got this far in the post probably already knows that IPv4 addresses are slowly running out. If every SEO in the place suddenly wants to enable SSL on their customer's sites, there's suddenly going to a lot of pressure on the IPv4 address space.

I know that if a relativity small percentage of shared hosting sites at work wanted to SSL enable their sites in the morning, we'd run out of available IPv4 addresses in a flash. However, we do have ~4,000,000,000 IPv6 addresses available which should be sufficient! It's just a pity that most ISPs wouldn't be able to get to them at the moment.

The big winner in this would be the companies selling the SSL certs. People could use a self signed cert, but do they really want customers/potential clients to have to click through the various warnings. There's other options such as CACert, but not all browsers will recognise them as a valid cert.

My own opinion is that the lack of referrers is no bad thing. It might force sites to stop using under hand tricks and just put up proper content.

9 Comments

Caveat lector: Mass use of SSL would be flaming death for the Internet. It'd defeat all non-browser caching, which would mean massively increased bandwidth usage. Of course, this could partly be averted through the use of CDNs, or not serving static content over SSL, but even *then*, it'd suck. And then there's the increase in server load that SSL for everything would mean.

So, bandwidth providers and hardware providers will be happy as well!

Support for TLS SNI;

http://en.wikipedia.org/wiki/Server_Name_Indication

- which obviates the need for multiple IPs - is far outpacing the rate of IPv6 deployment.

Last time I looked the support wasn't near that good, so I apologise for out of date info.

However, there are two places for which support is lacking:
1. Windows XP. On a fairly techy oriented side, W3Schools.com (first public browser stats I found), 56% of the hits were from XP last month. IPv6 support isn't great in XP, but it is possible.
2. Control Panel support. Just after doing a quick check, and none of the control panels we're using at the moment support SNI. Then again, IPv6 support isn't the best either in the same control panel.

IIS also seems to be lacking SNI support. Apache has only support it since 2.2.12, which is recent enough.

I've also failed to find a single SNI deployment, I use IPv6 daily in the office.

Come to think of it, perhaps this post should be redone as "Google Creating A Killer App For SNI"!

An interesting observation on what Google using HTTPS for search may mean for wider internet community, thank you.

Apache and Nginx have SNI support for a year or two. But there is other site of the coin: none of major browsers will support SNI on Windows XP. Thanks to Windows XP, every new year on the Internet is the same year again: 9 years old operating system, of course, does not support any modern technology.

Alternative to SNI is port forwarding which is quite difficult to set up for most people and companies.

For better or worse, Windows XP is good enough for most people, and until they're forced to replace their PC due to hardware failure or similar, that's not likely to change.

The only way port forwarding would work is if something like SRV records were used, for example something like:

_https._tcp.blog.moybella.net. 3600 IN SRV 10 0 32443 blog.moybella.net.

However, there again you'd run straight into the issue of client support.

About 40% of real-world https connections contain an SNI option in the TLS handshake. That's definitely beating - hands down - IPv6 adoption. By a long long *long* way. There's no reason to believe this trend won't continue, in spite of XP.

@Michael Using ports to disambiguate SSL endpoints is pretty unreliable, too many orgs allow ports 80 and 443 and nothing else.

Can you give me some real world examples of people using SNI? Other than a few test sites I can't find any.

I don't see any major sites using SNI as long as the majority of their clients are unable to use it.

About this Entry

This page contains a single entry by Niall Donegan published on May 25, 2010 4:27 PM.

Selection Bias In Virtualisation Marketing was the previous entry in this blog.

Default Search Domains On Ubuntu is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Pages

OpenID accepted here Learn more about OpenID
Creative Commons License
This blog is licensed under a Creative Commons License.
Powered by Movable Type 5.02