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.
That depends on your definition of "not realized". Before the FreeS/WAN project was abandoned, opportunistic encryption had been implemented and was in use. Adoption was probably quite small, but it existed.
The real "Libtards" are the Libertarians!
It is less secure because the keys are not verified, so a man-in-the-middle attack would work, but a passive attack (just listening) would not. It sounds like it uses DNS to verify the keys, so it may become (more?) secure if DNSSEC were implemented.
Indeed. You have to press one additional key to forge SSL connections in most "off-the-shelf" sniffers. I recall doing this with ettercap many years ago.
My other car is first.
If the encryption is computationally cheaper, then the decryption is computationally cheaper. I'd rather people know that what they're sending over the 'net can be sniffed than have them think that because example.com uses Rot13 encryption their traffic is private.
A few key points:
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/
One of the main points of this is that it's faster, however you didn't mention any comparison.
If you'd listened to the video, you'd have learned that the proposal uses Elliptic curve cryptography which is considered to require smaller keys to provide a similar level of security to the integer methods used in SSL. It does not automatically follow that, "If the encryption is computationally cheaper, then the decryption is computationally cheaper." If you'd listened to the proposal, you'd also have learned that it does not intend to replace SSL/TLS for strongly authenticated transactions, but only replace currently unencrypted traffic.
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.
Self signed certs can not be authenticated...
I really wish you people would stop whining...
Signed,
Someone with an actual clue about cryptography.
Oh?
You are so clueful about crypto that you don't know what fingerprints and out-of-band authentication are?
My.
Self-signed SSL certs work marvelously in a number of use cases:
A) When an admin or user adds the cert to a client machine (like a laptop) in a secure environment.
B) When fingerprints are verified out of band, such as over the phone, over alternate sites and protocols, printed correspondence, etc...
C) When its only necessary to know that you are communicating with the same party you were last time.
Granted that 'C' may be a rare and less secure case, but the first two are easy to perform and can meet a high standard for authentication.
It works great for ssh and solved the whole key distribution problem.
It works great after the initial conection, but you're vulnerable to a man in the middle attack on the initial connection attempt. It doesn't solve the key distribution problem at all. Or did you not read the warning message that ssh prints out on initial connections? You're accepting a risk, just as there is a risk in accepting a self-signed certificate. The difference is that your average SSH user can understand the risk, whereas unless you go the extreme route Firefox has gone, the average Web user will still see that the lock icon is there and just ignore any warnings. The CA system DOES solve the problem, but it relies on trusted authorities. There is no chance of a man in the middle attack with a trusted signed certificate.
"Well kids, you tried your best, and you failed. The lesson is, never try."
The person who wrote Obfuscated TCP works for Google.
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images