|
Reasoning
Reasoning behind ObsTCP.
Reasoning behind ObsTCPHigh value secrets are reasonably well protected when being transmitted these days. Most users are aware of TLS (usually in its guise of HTTPS) and have some awareness of that credit card details etc should be encrypted. SSH has deracinated telnet. However, there is no solution to the plethora of low value secrets which are still carried, unprotected, vulnerable to sniffers. These include searches, web histories, and sometimes IM and email. Evidently, the this information is of sufficiently low value that strong encryption isn't used. This suggests that we should investigate a very low cost system to protect these low value secrets. Low cost systems are commonly an anathema to security, especially cryptography, where attacks are measured in universe lifetimes. Low cost implies that compromises have to be struck. Most of the secrets listed above are carried over HTTP so we can reasonably start by considering how to secure just HTTP. It's not immediately obvious how to add even oppitunistic encryption to HTTP, but I believe that the point is moot because, however it might be done, it will require at least another round trip's worth of latency. I'm going to claim that this would immediately be too costly. "In A/B tests (at Amazon.com), we tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue." (source) "would you like 10, 20, or 30 results (from a Google search). Users unanimously wanted 30. But 10 did way better in A/B testing (30 was 20% worse) due to lower latency of 10 results. 30 is about twice the latency of 10" (source) It's hard to find good results on the effects of user latency, but these quotes suggest that large companies would have a strong incentive /not/ to support any system which added some protection to HTTP at the cost of an extra round trip. For example, here are some of the round trip times to some major websites. Keep in mind that I'm in the San Francisco area, so very well connected and physically close to many datacenters:
So, if we accept that adding a round trip is too costly, the only place that we can put this is in the TCP stack itself. To cut a long story short - we can't, the IETF rejected the idea and they control the registry of TCP options. So we exploit other side channels to get the server's public key and the alternative port number for the obfuscated server. One of those side channels are DNS TXT records, the other is previous connections to the same host. |