5 ms·

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 bu

by evmar 12y ago

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.

scintill76 12y ago
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 https://news.ycombinator.com/item?id=8506492
- guelo 12y ago
  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 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.
  - eunice 12y ago
    >(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?
    - magicalist 12y ago
      No, it hasn't been the case since 2010: http://www.theregister.co.uk/2010/07/20/chrome_does_resource_blocking/ http://www.theregister.co.uk/2010/07/20/chrome_does_resource...
  - julianj 12y ago
    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.
- AlyssaRowan 12y ago
  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.)
  - scintill76 12y ago
    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.
    - MichaelGG 12y ago
      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.
- deleted 12y ago
  [deleted]
- nly 12y ago
  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.

by evmar 12y ago

scintill76 12y ago

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 https://news.ycombinator.com/item?id=8506492

guelo 12y ago
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 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.
- eunice 12y ago
  >(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?
  - magicalist 12y ago
    No, it hasn't been the case since 2010: http://www.theregister.co.uk/2010/07/20/chrome_does_resource_blocking/ http://www.theregister.co.uk/2010/07/20/chrome_does_resource...
- julianj 12y ago
  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.
AlyssaRowan 12y ago
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.)
- scintill76 12y ago
  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.
  - MichaelGG 12y ago
    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.
deleted 12y ago
[deleted]
nly 12y ago
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.