Slashdot Mirror
Google's Obfuscated TCP
agl42 writes "Obfuscated TCP attempts to provide a cheap opportunistic encryption scheme for HTTP. Though SSL has been around for years, most sites still don't use it by default. By providing a less secure, but computationally and administratively cheaper, method of encryption, we might be able to increase the depressingly small fraction of encrypted traffic on the Internet. There's an introduction video explaining it."
It's not written by Google, it's just hosted by them. Big difference, misleading title.
This is not GOOGLE's Obfuscated TCP, this is a small one-man project HOSTED on Google Code.
That guy's gonna get tons of traffic for what's maybe a good idea but not endorsed or supported by Google.
All Hail Discordia. Hail Eris. Fnord.
Per definition, then you're more than an eavesdropper. Then you're actively intercepting and rewriting the connection, which is a lot more complicated to do in volume plus detectable by comparing fingerprints. Whereas just copying the stream for the NSA is trivial and without detection possibility, but hey pick no security because the other is imperfect.
Live today, because you never know what tomorrow brings
he big barrier to ssl for small sites is cost - in some cases the cost of an ssl cert will exceed all other costs.
I would disagree. One of the biggest barriers to implementing SSL on my sites is the lack of IP addresses. I only have two IP addresses, yet I host 16 web sites. My understanding is that HTTPS requires IP based virtuals which would prevent me from hosting more than two sites if I were to use SSL for all of my sites.
My understanding is that HTTPS requires IP based virtuals
Partly. There's a TLS extension that makes it work, but it looks like it doesn't work for IE on WinXP.
It's interesting how the same idea gets "reinvented" over and over. Opportunistic encryption using advertised DH public numbers is just such a thing.
ObsTCP is just a reinvention of SKIP.
See here via the Wayback Machine since the concept is long dead and buried.
http://web.archive.org/web/20021129230049/http://www.skip-vpn.org/
IPSec prevents its own widespread adoption in two ways:
1) IPSec is very much about authenticating who you are talking to on the other end. If two nodes connect for the first time, with no previous knowledge, they have no way to authenticate the other is who they say they are. This is a failure to IPSec - you'll get no SAs, and most implementations will drop traffic that would've required that SA.
2) The classic key exchange issue:
a) You can authenticate a session using certs, but now you have the same problems as signed SSL certs, except that every host participating needs to have one and know about all the other nodes' CAs.
b) You can instead opt to use a pre-shared key, but now you have to pre-share the key. This is fine when you are looking to secure specific traffic to a specific node.
For uses that aren't affected by these downsides, IPSec is a hugely popular technology. VPNs between a branch and central office as well as remote access for roaming users are very popular. Of course in these cases you can very meaningfully authenticate the other end and the key exchange isn't a problem.