3 ms·
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
by 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 agoComplicit 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 agoI 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...