Destructive, invasive, and dangerous behavior by UK ISP TalkTalk (aka StalkStalk)
Today I spent several hours trying to figure out what was going wrong with a web service I’ve been building. The service uses websockets to let browsers and the server send messages to each other over a connection that is held open.
I built and tested the service locally and it worked fine. But when I deployed it to a remote server, the websocket connections were mysteriously dropped 30-35 seconds after they were established. The error messages on the server were cryptic, as were those in the browser. Google came to the rescue, and led me to the eye-opening explanation…
It turns out TalkTalk, my ISP, are also fetching the URLs my browser fetches, after a delay of 30-35 seconds! I guess they’re not doing it with all URLs, probably because they figure the sites are “safe” and not full of content that might be deemed objectionable. All the accesses come from a single IP address (62.24.252.133), and if you block that address or otherwise deny its connection attempts, the websocket problem goes away immediately.
Dear TalkTalk – this is a very bad idea. Here are 3 strong reasons why:
- First of all, you’re breaking the web for your own customers, as seen above. When your customers try to use a new start-up service based on websockets, their experience will be severely degraded, perhaps to the point where the service is unusable. Time and money will be spent trying to figure out what’s going on, and people will not be happy to learn that their ISP is to blame.
- Second, there’s a real privacy issue here. I don’t really want to go into it, but I don’t trust my ISP (any ISP) to securely look after data associated with my account, let alone all the web content I look at. I have Google web history disabled. I don’t want my ISP building up a profile of what the people in this house look at online. There’s a big difference between recording the URLs I go to and actually retrieving their content.
- Third, it’s downright dangerous. What if I were controlling a medical device via a web interface and TalkTalk were interfering by killing my connections or by replaying my requests? What if there was a security system or some other sensitive controller on the other end? There’s no way on earth TalkTalk should be making requests with unknown effects to an unknown service that they have not been authorized to use. The TalkTalk legal team should consider this an emergency. Something is going to break, perhaps with fatal consequences, and they are going to get sued.
If you want to read more opinions on this issue, try Googling TalkTalk 62.24.252.133. Lots of people have run into this problem and are upset for various reasons.
See also: Phorm.
You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.
December 12th, 2012 at 2:02 pm
One could also argue that anything done over HTTP is in the open and thus fair game for replay.
Either use HTTPS or add something to the protocol that avoids these replay attacks?
December 12th, 2012 at 2:13 pm
Hi Holger!
Yes, I guess you could argue that. But to me the following analogies are pretty close to what TalkTalk are doing:
1. I leave the backdoor to my house open, and let my friends wander in whenever they please. Should I think it’s fine for strangers to follow them down the street and also wander into my house?
2. I put a combination lock on my back door, and tell the combination to a friend. The friend comes to visit and lets him/herself in, but is tailed by a stranger who looks over their shoulder as they enter the combination. The stranger then comes into my house sometime later using the combination. Is that OK? The combination lock that is opened with the expectation of privacy is like an obscure URL with an MD5 sum in it – in theory no one should be able to re-use it. But an eavesdropper can.
TalkTalk will probably argue that they have to protect the children, protect us all against phishing, etc. Who knows?
I agree with the HTTPS comment, of course. And re protocol, there is a pending patch on the socket.io repo to 404 subsequent connections that don’t come from the same IP address (or maybe just ones that don’t upgrade the connection protocol, I’m not sure exactly).
Terry
December 12th, 2012 at 2:46 pm
Another way to look at it is from the POV of reasonable expectation of privacy.
When I make a phone call, the number I have called is known only to me and the phone company. My expectation is that they will record the number I called, perhaps for legal purposes, perhaps for billing, etc. Even though anyone in the world *could* immediately call the number I just called (it’s “fair game” in a sense), no one else knows I called it. If the phone company were not only keeping track of all the numbers I called, but also calling them 30 seconds after I called them (and asking whoever answers for the exact same thing I asked for when I placed my call) that would be a pretty big violation of our (current, default) expectations re privacy.
TalkTalk is both my internet provider and my phone provider – maybe soon they’ll start recording what I say on the phone, auto-dialing all my numbers, and playing my voice down the connection too!!??
December 12th, 2012 at 3:46 pm
Oh, I agree that what they do is wrong and despicable (but hey, they *are* Talk Talk after all so you get what you ask for).
My argument was that yes, don’t be surprised that people open your lock if you openly show the combination to dodgy characters like Talk Talk. The net is a hostile environment (more so with certain ISPs and/or countries you are dealing with).
December 12th, 2012 at 3:50 pm
Yeah…. I guess I learnt something from all this. I’m probably going to fork out for an SSL cert for the site I’m building :-(
December 12th, 2012 at 3:53 pm
https://www.startssl.com/ ?