3 ms·

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 cas

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.
  - scintill76 12y ago
    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...

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.
- scintill76 12y ago
  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...