Update – Since this was posted, Max Allan and Damion Yates have investigated further and found that BT are intercepting DNS queries and replying with doctored DNS results, which I didn’t notice when originally researching this article. The title is therefore not entirely accurate, and BT are most probably doing this without any special treatment from Google, but the point that Google is facilitating this (by performing http redirects) stands. Please keep this in mind as you read :)

–Alex 25/11/2014

As I’m currently in temporary accommodation I have found myself without a permanent internet connection. 3G service in the area is pretty spotty, so I bit the bullet and ended up purchasing a single month BT Wifi pass, effectively piggy-backing a neighbours connection. I’m guessing they see very little of the £39 I paid.

It is well-known that BT has filtering in place, supposedly for the protection of children, as required by the UK government. I don’t agree with this policy, but accept that many do.

However when it starts to affect privacy, I feel that BT’s meddling of my internet connection has gone too far.

Case in point, when using Google on BT Wifi I happened to notice a new message on the side:

SSL search is off This network has turned off SSL search, so you cannot see personalised results. The security features of SSL search are not available. Content filtering may be in place. Learn More | Dismiss

After digging into it, I’ve found that statement to be demonstrably false. In actual fact what it should say is; “We have disabled SSL search on behalf of your network provider.”

To which I say, thank you for giving me another reason to use duckduckgo.

Why

I can think of a couple of reasons to block SSL search. One is child protection and filtering. Disabling SSL search allows BT to filter searches for undesirable terms, and theoretically allows them to append “?safe=active” to the search URLs. They don’t do this though, in fact doing so would require the use of a proxy server, which would be a whole new level of intrusion.

The other reason, and the one I feel is more likely to be responsible for this policy, is data mining. It’s reasonable to expect that BT knows the location of every BT Wifi router within 10-15m, because it has a home address for every one of them. Whether or not it knows who is signed in to Google (it’s reasonable to assume it doesn’t unless it’s actually inspecting the contents of the message body, and that would be *WAY* overstepping the mark), knowing what is searched by location is a marketing gold mine.

So, I’m being data-mined. Great.

Now how do I get around this!

The “learn more” page includes a link to “SSL Search for Schools“, which describes how network administrators can disable SSL search, effectively by redirecting users to specific virtual IP addresses via DNS.

Great I thought, I can just use public DNS and avoid BT’s.

Not quite.

BT doesn’t seem to meddle with Google’s DNS entries at all. I even did a query to www.google.com from my own server, put that IP in my hosts file, opened up a fresh browser profile and SSL search was still disabled!

There’s something more to it then.

Running a request with curl shows that the redirection is happening completely within Google’s network (I’ve removed some inconsequential lines to shorten it a bit):

$ curl -vL 'https://www.google.com'

* About to connect() to www.google.com port 443 (#0)

* Trying 216.239.32.20...

* Connected to www.google.com (216.239.32.20) port 443 (#0)

* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

* Server certificate: www.google.com

* Server certificate: Google Internet Authority G2

* Server certificate: GeoTrust Global CA

* Server certificate: Equifax Secure Certificate Authority

> GET / HTTP/1.1

> User-Agent: curl/7.30.0

> Host: www.google.com

> Accept: */*

>

< HTTP/1.1 302 Found < Cache-Control: private < Content-Type: text/html; charset=UTF-8 < Location: https://www.google.co.uk/?gfe_rd=cr&ei=qPYmVL28J4vDcJbFgLAI < Content-Length: 260 < Date: Sat, 27 Sep 2014 17:40:56 GMT * Server GFE/2.0 is not blacklisted < Server: GFE/2.0 < * Ignoring the response-body * Connection #0 to host www.google.com left intact * Issue another request to this URL: 'https://www.google.co.uk/?gfe_rd=cr&ei=qPYmVL28J4vDcJbFgLAI' * About to connect() to www.google.co.uk port 443 (#1) * Trying 216.239.32.20... * Connected to www.google.co.uk (216.239.32.20) port 443 (#1) * TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA * Server certificate: www.google.co.uk * Server certificate: Google Internet Authority G2 * Server certificate: GeoTrust Global CA * Server certificate: Equifax Secure Certificate Authority > GET /?gfe_rd=cr&ei=qPYmVL28J4vDcJbFgLAI HTTP/1.1

> User-Agent: curl/7.30.0

> Host: www.google.co.uk

> Accept: */*

>

< HTTP/1.1 302 Found < Location: http://www.google.co.uk/?gfe_rd=cr&ei=qPYmVL28J4vDcJbFgLAI&gws_rd=ssl

This above transcript is indecipherable to any one non-technical, but what it shows is that Google itself is redirecting me to http by sending a 302 “Found” header when I connect to https.

It’s important to stress that I’m connecting to a Google-owned server called “GFE/2.0” (which could stand for “Google Front End”). We’re then handed off to “gws” later, which presumably stands for Google Web Search (or Google Web Server).

Thus what I’ve shown here is that the statement “this network has turned off SSL search” is false. BT can’t be doing it unless it has re-routed some of Google’s IP addresses, spoofed its SSL certs, and hosted its own implementation of GFE before handing you back to GWS.

This is unlikely, to say the least.

What we’re witnessing therefore, is almost certainly the result of a commercial agreement between BT and Google UK. One that exchanges the privacy of my searches for BT and Google’s commercial gain.

Duckduckgo it is then.