Hacker News Reader

Comment by grepular | Hacker News Reader

If somebody can sniff the HTTP traffic of a website you're visiting, that seems to be a much bigger issue than them being able to see what the search term you googled for was.

The ideal scenario would be for both google and the website you're visiting to be SSL protected. That way you can see the referer, but nobody can sniff any of the information.

It's usually pretty easy to see what website somebody is visiting over a HTTPS connection purely because you can only host one website per IP/Port combination (I'm ignoring SNI because pretty much nobody uses it yet)

View on HN

SNI is currently supported by about 50% of browsers in the wild. The vast majority of the non-supporting population are IE users on XP or earlier.

Since there's almost no chance that Microsoft will ever update XP, we'll probably have to wait for years until we start hitting useful numbers like 90%+ :(

Can you name any websites which have deployed SNI?

For that matter, does Googles bot support websites which use SNI?

HTTPS is slower, though; Google has been pounding into our heads for the past year that any milliseconds you can shave off your load time will result in significant improvements in page views and time spent on a site. I don't see this ever happening, although I do hope that the SPDY protocol (or something similar) becomes the standard one day, as it's both secure and fast.

I've never found that argument very convincing. I just sat here and ran the following two commands a bunch of times:

time wget -q -O /dev/null http://www.google.com/

time wget -q -O /dev/null https://www.google.com/

There is no obvious difference in time taken to serve those requests.

Obviously there is an overhead, but to me it seems insignificantly small in comparison to the overall request.

I bet 99% of websites out there could convert to SSL, and then pull back the performance lost by just doing a little site optimisation.

The performance difference between https and http depends on a ton of factors. The reason you don't see a performance difference between these two requests is most likely because:

-Google's servers are big enough they can easily handle the extra load of encryption without breaking a sweat

-One of the many factors that makes SSL slower is that assets will not be cached in a shared cached (e.g. a proxy server), and will also not be cached in a browser beyond a single session (usually). So, stylesheets, javascripts, and images, must be downloaded to the browser much more often.

Note that your wget test completely ignores this last point, because it is not trying to cache anything for either https or http.

Regarding your second point. I'd be interested to see figures for how many web requests globally are fulfilled by a shared cache. My gut feeling is that it is a very small proportion of the total.

Yeah, I'd be interested too. Though, entire web requests wouldn't be fulfilled by a shared cache, just cached assets with proper Expires headers, such as javascripts, stylesheets, etc.

I actually wouldn't be incredibly surprised to learn that shared caches in proxy servers are quite efficient at serving cached content. If you think about it, it's in internet providers' best interest to make their proxy servers good at caching, because it would allow them to provide more content to their customers with less bandwidth, which of course affects their bottom-line.

We (Google) are working hard to reduce the round trips needed for SSL/TLS. We hope to be publishing several draft specs in the next couple of months.

Reply on news.ycombinator.com