Slashdot Log In
Google's Obfuscated TCP
Posted by
kdawson
on Tue Oct 07, 2008 08:53 PM
from the shake-hands-when-you-say-that dept.
from the shake-hands-when-you-say-that dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
surveillance (Score:5, Insightful)
The video starts out saying that increased encryption is needed thanks in part to warrantless government surveillance. It then goes on to describe a system that assumes no MITM attacks can exist. The fact is, however, that governments are entirely capable of performing MITM attacks, as can telecommunications companies; and if it becomes popular we may see more techniques that allow individuals to perform MITM attacks. While this algorithm has significant merit, care needs to be taken to avoid a false sense of security.
Re:surveillance (Score:5, Insightful)
It does not "assume no MITM attacks can exist". It deliberately does not protect against them. This is not the same thing, as one is a position of ignorance whereas the other is an intentional choice not to defend against that threat.
In practical terms, MITM is considerably harder than simply listening in. Wide-scale surveillance such as what caused the big recent flap with FISA and the NSA simply can't perform MITM attacks. Protecting against pure eavesdropping while remaining open to MITM attacks is useful, it's just not a 100% solution. As long as it doesn't sell itself as one (and I see no indication that it is) then there's absolutely no problem with that.
Parent
NOT GOOGLE (Score:5, Informative)
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.
Re:NOT GOOGLE (Score:5, Informative)
He's a Google employee. [blogspot.com].
(Standard 20% time disclaimer etc)
Parent
Trusts DNS instead of CA signature (Score:5, Insightful)
So, basically we have the same concept as SSL, except instead of trusting the CA signature on the certificate, we trust DNS.
Forging a CA signature on a certificate would be a BIG DEAL.
Forging a DNS entry, especially with ISP cooperation(read government snooping), is DEAD SIMPLE.
So we replace real security with, well, a CPU hog that's only a smidge better than running everything in the clear. It only keeps out the MOST casual, lazy, and uninterested snooper.
They could have done better (Score:5, Interesting)
I read the technical details [google.com] and they talk about an advert being encoded in the CNAME, to distribute a curve25519 key and a port number. But they could have done much simpler using technology that already exists: encode the 160-bit SHA1 fingerprint of an X.509 certificate and a port number in the CNAME (only 32 chars needed in base32). Then connect to this port using HTTPS and simply verify that the certificate matches the fingerprint ! Advantages:
Reinventing ancient history (Score:5, Informative)
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/ [archive.org]
Re:The implications? (Score:5, Interesting)
Why?
If you watch the "video", one of their explicit points (#2) is that the user shouldn't be informed of this. This will not trigger the little security lock icon. From a user's point of view, you shouldn't be able to tell if the web server you are connected to is unsecured or secured this this little bit of obfuscation.
This isn't for real security, it's to make simple sniffing harder. As the video puts it, it simply raises the bar for someone who wants to read other people's traffic.
It seems like a very good idea to me. It sounds quite intelligent (from what I know of TCP/IP, etc). Some protocols have need changes (protocols where there is one connection and it isn't dropped would need some way to communicate that the encryption is OK during the first (and possibly only) connection.
Either way, it sounds like quite an improvement over what we have now.
Parent
Re:The implications? (Score:5, Funny)
This. Is. SLASHDOT!
Parent
Re:The implications? (Score:5, Insightful)
Implications?
but it can assuage untargeted, dragnet sniffing of backbones
Can you read the subtext there? Snap, how's that for an implication? Privacy. (from the government.)
Parent
Re:So, wait... (Score:5, Informative)
It's not written by Google, it's just hosted by them. Big difference, misleading title.
Parent
Re:Firefox isn't helping (Score:5, Interesting)
"simply removing eavesdroppers would be a step in the right direction."
Yes. Whereas self-signed certs let the eavesdropper send you a certificate which makes you think your connection is secure when in reality they're listening to everything you send.
Parent
Re:Firefox isn't helping (Score:5, Informative)
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.
Parent
Re:Firefox isn't helping (Score:5, Interesting)
Or distinguish between "authenticated" and "encrypted"?
Or finally admit that maybe there are more shades of grey than "secure" and "insecure" when it comes to send and fetching data over the Internet?
Parent
Re:Firefox isn't helping (Score:5, Insightful)
The point being that this is the actual security hierarchy, from best to worst:
Whereas most web browsers make it appear like this:
Any browser that warns you about self-signed certs should make at least as much of a fuss about using plain HTTP, but they don't. Firefox takes it to ridiculous extremes but they're all faulty in this respect.
And really, if browsers would save the self-signed cert and then alert me if it changes the way SSH does, then the result will be very good, nearly as good as a regular cert (and potentially even better, since there's no potential for compromising the trusted certificate authority).
Parent
Re:Firefox isn't helping (Score:5, Insightful)
So stop displaying the lock symbol! Nothing requires you to treat "real" SSL and self-signed SSL identically. It should be obvious that the current standard approach of making them look exactly the same except for a scary warning that appears the first time you hit a self-signed site is broken. But nobody cares about doing better because it's the "standard".
Parent
Re:Firefox isn't helping (Score:5, Insightful)
aka: "Whereas having a keyed lock on your door lets a thief pick the lock and steal everything inside."
Therefore we should make it less convenient to put locks on doors.
Parent
Re:Firefox isn't helping (Score:5, Insightful)
SSL without a trusted certificate provides NO additional security over communicating in the clear. AT ALL.
Bzzzt, wrong, thanks for playing.
Yes, the man in the middle attack is very real. However, it takes a great deal more work to set up than a simple sniffer, because you have to either capture/block/proxy/rewrite packets so that each side thinks it's speaking with the other, or spoof the DNS somehow.
On the other hand, a simple network sniffer can capture almost everything send in the clear, no special network tricks needed.
Authentication requires encryption. Encryption does not require authentication, but should then be considered somewhere between truly secure and just wide open. Call it a nice-to-have that prevents casual sniffers from picking up passwords to your home server, reading your webmail, and the like.
Your assertion assumes that there are no casual crackers/script kiddies out there who won't immediately escalate to some invasive and rather difficult MITM attack, or that sniffing is not a real danger. I'd argue that 90% of the insidious activity comes from just sniffing cleartext off the wire, and that more sophisticated attacks are significantly rarer. Encrypting the over the wire traffic is a way of mitigating a significant portion of that risk.
Parent
Re:Firefox isn't helping (Score:5, Interesting)
Parent
Re:Firefox isn't helping (Score:5, Interesting)
Parent
Re:Firefox isn't helping (Score:5, Insightful)
Most users are too dumb to check for SSL, good luck getting them to discern insecure, 'insecure but can't be eavesdropped', and secure.
Fair enough. So don't put the secure green lock up for self signed SSL. Put up a totally different icon in some neutral color like blue. If they click on it it says, the connection is encrypted and can't be eavesdropped but there is no gaurantee you are talking to who you think you are.
Hell, most users would be shocked to find out you can eavesdrop on their traffic in the first place.
Good point! Maybe firefox 3 should pop up a huge error screen every time you try to connect to a site with plain http. It could say something like:
The server you are connecting to is insecure. Maybe there is a configuration error on the server. Or maybe someone is trying to impersonate it. Oh, and by the way, not only that, but any communication with them maybe trivially intercepted by any 3rd party...
Are you sure you want to communicate with them?
Then it could have friendly buttons like:
"Hell no get me out of here." or "Ok, I don't mind getting pnwed!"
Parent
Re:Problem isn't computation... (Score:5, Informative)
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.
Parent
Re:Problem isn't computation... (Score:5, Informative)
My understanding is that HTTPS requires IP based virtuals
Partly. There's a TLS extension [wikipedia.org] that makes it work, but it looks like it doesn't work for IE on WinXP.
Parent
Re:Problem isn't computation... (Score:5, Insightful)
Anybody remembers what hapenned to RFC 2817 [ietf.org] ? It tried to address this very pb by introducing the "Upgrade: TLS/1.0" header and the "426 Upgrade Required" status code, but I don't think any browser or server implement them.
Parent
Re:Problem isn't computation... (Score:5, Insightful)
Running your web sites on non-standard ports is a great way for your web site not to be accessible to users accessing the internet through firewalls that limit egress traffic based on TCP destination ports.
Parent