4 ms·
I suppose they can already sneak it into the SSL handshake packets, right? Put something in extended client hello[0] that whoever is interested can look at, an
by scintill76 12y ago
I suppose they can already sneak it into the SSL handshake packets, right? Put something in extended client hello[0] that whoever is interested can look at, and other TLS implementations should be ignoring for compatibility. It's maybe not as easy for ad networks to consume, but where there's money to be made, there's a way.
I think this would work. Am I missing something? Has anyone checked if it's already being done?
[0] https://tools.ietf.org/html/rfc4366#section-2.1 https://tools.ietf.org/html/rfc4366#section-2.1
- zrm 12y agoThey don't even have to inject anything, it's surprising they're doing this at all. They could just use the TCP/IP source and destination addresses and ports to identify the connection. TLS wouldn't help that. VPN would though.
- scintill76 12y agoMaybe, but it sounds more messy. Verizon would have to maintain a semi-public (to their "other" customers, that is, advertisers etc.), low-latency queryable database of {source, destination, customerID} tuples, and ads and/or pages might not finish loading until that query returns. If the ID is more static, the trackers can cache the identity information for awhile after the first time, and Verizon probably has less work to track and resolve IDs.