Hacker News Reader

Comment by evmar | Hacker News Reader

It's strange to read this and then simultaneously read people complaining about HTTP2 requiring SSL. It'd surely be nice if law protected us from bad actors but SSL protects from this in a way that (hopefully) can't be circumvented.

View on HN

SSL can't really stop it, I think. Here's a thread where I've speculated on a way to inject metadata into SSL handshakes[0] just like they're doing with HTTP headers. If that doesn't work (I'd be interested to hear why), someone else suggested using TCP-IP source/destination metadata queried from the ISP to resolve to a customer.

[0] https://news.ycombinator.com/item?id=8506492

No. An MITM starts changing the ClientHello, and the PreMasterSecret should change because it's all hashed in, and therefore Finished will fail - that's the case with the TLS 1.3 draft and I wouldn't be surprised if TLS 1.2, too, although I'll put it on my list to check. Fallbacks complicate that, but the fallback SCSV signals enough to correctly sound the alarm there too.

I'm specifically on the lookout for sneaky ways to (GCHQ call it) "stain" traffic like that, and try to remove them. ("Kleptography" is similar, but the endpoint is complicit - there's not a lot can be done when the endpoint is complicit, but more deterministic primitives help both.)

These can be rather subtle - with temporal differentiation as well, even 1 bit allows for a basic binary search/partitioning attack, so anonymity networks like Tor, I2P etc have to be particularly careful about that.

(You shouldn't really be using TLS 1.0/1.1 anymore, and definitely not SSL.)

I'm sure you know a lot more than I, and you're pushing the boundaries of my limited knowledge, but I read a bit on some things you mentioned... I don't follow how the PreMasterSecret incorporates the ClientHello; PreMasterSecret seems to be just a protocol version and some random bytes. As for the Finished hash check, I didn't know about that, but can't a server complicit with the MITM (i.e., a site wanting to buy customer data from Verizon) fix up the hash by ignoring the bytes the MITM inserted? They would coordinate a scheme to reversibly inject tracking bytes, and pretend the bytes weren't there while hashing for Finished.

Since you mentioned complicit endpoints, I'm really wondering if I'm being naive here. It's certainly not as simple as injecting HTTP headers, but it looks possible if the ISP and target server collude, and the ISP makes sure to only tamper with traffic bound for servers that "know" to un-tamper it.

I could probably prove or disprove this for myself by writing a proof of concept, and maybe I will, but in case it is an issue that could be mitigated, I'd rather someone more qualified think about it sooner than I will figure it out.

Good point about "SSL", I was using the term loosely.

Complicit endpoints could just work with Verizon to enable a server to server API to get the subscriber ID of a particular TCP connection. In fact, since this is non visible to end users, if Verizon is clever, that's what they'll do. Then it would not have this public visibility.

I was going for a more direct analogue, and how inserting the ID is more seamless than a backend query, and how tampering with SSL is more technically interesting to me, but yes, you're right. Good point on how it would not be detectable. I wonder how many ISPs are doing it right now...

If the advertisers and your ISP are cooperating there's nothing you can do. They can easily just redirect all IP packets going to their advertising partners through some encapsulation that encodes your customer id out-of-band, encode it in to their NAT scheme, or just provide customers with static IPs and partners with regular dumps of the database.

It's simpler then that. The advertising based site wants to show you the ad, they have no incentive to implement SSL. There's no https://espn.com, for example. Even if they did implement https it would be mixed content because the ad networks' iframes or whatever are http.

The solution is things like NoScript or Adblock on Firefox (not Chrome which downloads the ad and just hides it). Or blackholing the ad networks in /etc/hosts.

>(not Chrome which downloads the ad and just hides it)

I thought this hadn't been the case for several years now? Am I wrong?

No, it hasn't been the case since 2010: http://www.theregister.co.uk/2010/07/20/chrome_does_resource...

Agreed. An entry in the hosts file for ad dot turn dot com could be a temporary fix-- until they use a different subdomain. A combination of the above is probably the most optimal solution.

Reply on news.ycombinator.com