Wednesday, October 08, 2008

Google's "obfuscated TCP"

Google's "obfuscated TCP" (ObsTCP) has appeared in the news again (on Slashdot). This is a good example of something that's a bit too subtle for people to understand.

Security is a tradeoff. This means that security never comes for free, and that you must pay for it. That's why SSL isn't the default. It adds too much delay, and the additional processing power is too costly for websites.

ObsTCP is the idea is to add the maximum amount of encryption within the same amount of delay/processing budget we already have for TCP connections. That means establishing encrypted TCP connection with an additional round-trip delay or CPU power.

Why don't they use IPsec or better crypto algorithms? The answer is simply "because that would add more latency/CPU".

Can this encryption be broken? Yes, of course, that's why it's called "obfuscation". I can still break into your TCP connection if you are surfing the web in a coffee shop using ObsTCP. However, I would no longer be able to do so in a completely passive way like Sidejacking. I'd have to instead transmit some packets. This means you could catch me if you were paying attention (such as surfing to a site for which you already have a key and see if they match).

Widespread government wiretapping would have the same difficulty. They can do it now completely passively. With ObsTCP, they would either have to invest billions of dollars in breaking the ciphers, or they would have to actively transmit packets and reveal their wiretapping. ObsTCP doesn't protect the individual so much as protect society.

I'm bothered by the fact that they are avoiding some solutions because the IETF won't like them. This contravenes the principles that the IETF was based upon. It's not the IETF's job to dictate standards, but instead to document working protocols that people come up with. It's like dictionaries: their role is to document how people use words, not dictate how they SHOULD use words. The ObsTCP project should be mindful of stepping on other people's toes, but if need be, go forward. If they won't assign you a TCP option, just pick one and use it.


durrow said...

The IETF is no longer the open forum that it was 10+ years ago. Now it's lead by product marketing with a specific goal (sell more product) in mind. It's a sad state, at one point you could count on drafts documenting your solution and if they were adopted widely enough they became standards. That draft path is harder then it used to be so that method is not used as much.

All in all, your right - perhaps Google can start a new standards based group :)

Fowl said...

My thoughts exactly.

In my view this could be implemented entirely within the TCP stack and be completely transparent to applications.

It's so obvious when you think about it.

Encryption-by-default, even if it's weak, protects all of us. The same way everyone uses sealed envelopes, if it's the norm it won't standout.

Fowl said...

After further reading it turns out that SYN's with non-standard options (and/or a payload) are dropped or mangled by a non-trivial amount of hosts.