Google's Obfuscated TCP 392
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."
The implications? (Score:1, Insightful)
Wouldn't this result in a greater amount of, say, phishing sites?
Firefox isn't helping (Score:4, Insightful)
Firefox isn't helping the lack of SSL on the web by throwing a ridiculous warning when using self signed certs. Browsers should treat self signed certs as 'unsigned with the added bonus that communications can't be eavesdropped' instead of freaking out that you might not know who you are talking too.
self signed certs aren't appropriate for processing credit cards... but not every site that has forms needs that... and simply removing eavesdroppers would be a step in the right direction.
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.
The problem is IPv4 (Score:1, Insightful)
Hosting companies get a limited about of IPv4 addresses from ripe, making it a pain the ass to assign a dedicated ip (which is needed for ssl) to every website they host.
Roll on IPv6
Re:So, wait... (Score:3, Insightful)
>
Are we supposed to like Google or not now?
I'm confused :(
Realizing that large corporations consist of many separate interests might help alleviate your confusion :-)
Project owner's page is at: http://www.imperialviolet.org/ [imperialviolet.org] if you wanted more info.
Less secure than 128bit SSL? Why? (Score:4, Insightful)
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.
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.
Re:surveillance (Score:3, Insightful)
Which is why the video states that SSL/TLS should be the only user visible transport security and their third goal is to have no visual indications and no alternative URL schemes.
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).
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.
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.
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.
Re:The implications? (Score:1, Insightful)
Why don't we use TLS with self-signed certs then? Instead of putting up these huge warnings that tell the clueless user that connecting to a site using a self-signed cert and they are going to get hacked, simply warn the user in the same fashion as any site using simple HTTP. Then, only display the secure indicators if the user is connected through HTTPS with authoritative or manually accepted certificates.
Re:Trusts DNS instead of CA signature (Score:3, Insightful)
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.
True, if it required you to forge a real CA's signature. The whole point of self-signed certs is that there is no CA - you're not impersonating being anyone other than the website and it has zero effect on anything else. I can make such a certificate up in a terminal in the time it takes me to type it. I don't know if it would be a bigger deal legally, but technically it is equally dead simple. And if it was legally a big deal I'm sure they can get some retroactive immunity for it.
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.
Re:They could have done better (Score:4, Insightful)
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".
Any commonplace encryption is helpful (Score:4, Insightful)
we might be able to increase the depressingly small fraction of encrypted traffic on the Internet.
I agree that this would indeed be a good thing for several reasons. An encrypted message in a medium where most everything is plaintext may attract the attention of attackers or, worse, be seen as "suspicious" by a government. (Certainly the U.S. and the PATRIOT Act spring to mind, but let's not forget the truly oppressive governments such as China's and any number of third-world dictatorships.) If online privacy via encryption comes to be a right that everyone gets used to enjoying—much like how almost all mail is sent in sealed envelopes, whether or not its contents are sensitive—then it will be that much harder, for technical and/or social reasons, for an authority to take away. If Obfuscated TCP is even a token step in that direction (and it seems to be a bit better than that), then it is probably a good thing overall.
Someone earlier today on Slashdot was plugging Cory Doctorow's Little Brother, and I'm going to follow that example (you can read it for free!) [craphound.com] as part of it advances the same idea.
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.
Re:Firefox isn't helping (Score:3, Insightful)
EXACTLY! With a self-signed certificate, there's no indication that a man in the middle attack is taking place.
SSL without a trusted certificate provides NO additional security over communicating in the clear. AT ALL.
Self-signed != untrusted, and CA-signed may not always = trusted. Why do people always seem to just assume that CA-signed/self-signed are equivalent to trusted/untrusted?
There are ways to verify certs other than having a site- (or attacker-) chosen CA sign them. For example, the Perspectives [cmu.edu] firefox extension relies on "you can't fool all of the people all of the time" rather than the "you can't fool any of these people ever" that the CA system relies on. And it works regardless of whether a cert is self-signed.
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.)
Re:The implications? (Score:2, Insightful)
Weak encryption worse than none. (Score:4, Insightful)
"By providing a less secure, but computationally and administratively cheaper, method of encryption, we might be able to..." give people a false sense of security.
Remember, weak encryption can be worse than none as Mary Queen of Scots found out at the cost of her life (see http://www.nikon.com/about/feelnikon/light/chap04/sec01.htm [nikon.com]).
Re:The implications? (Score:1, Insightful)
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.
Um, no. It's so that it costs more to index the web, meaning that any competitor to google has to pay more to challenge their dominant position as search engine. Microsoft has to bleed even more money trying to compete. Yahoo might have to abandon search.
The cost of indexing the web has gone down a lot, with cheaper bandwidth and cheaper storage and cheaper computers. So, adding automatic encryption raises the price back to where it was a decade ago.
As an added bonus, if TLAs can't just tap the internet backbones, if they have to do say 10 thousand times the work to eavesdrop then that makes all of the massive databases more valuable to them. For instance, google, with probably the largest user databases on the planet.
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!"
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.
Re:Firefox isn't helping (Score:3, Insightful)
What's difficult is if I'm technically capable of eavesdropping, I'm technically capable of MitM and thus a self-signed certificate doesn't add any extra security.
So have the browser treat it as being unsigned. Don't do anything special. Don't put up a big green lock. Don't make a fuss. Even if its not really MORE secure, its certainly not LESS secure, so firefox at WORST should treat it exactly the same as plain http.
Re:Firefox isn't helping (Score:5, Insightful)
I dunno. I just click "Okay" until the windows go away and I can see the website.
Re:Firefox isn't helping (Score:3, Insightful)
Bzzzt, wrong, thanks for playing. I written an app that makes the process as easy as starting a sniffer, just because you don't know of any software that automates the process doesn't mean they don't exist. The app doesn't work flawlessly due to the technical details involved, but it certainly works well enough for me to watch 'encrypted' data flow just as easy as it is for you to start tcpdump of ethreal.
Bzzzt, wrong, thanks for playing. With SSL, the authentication phase happens before the encryption phase, because the next part is negotiating the actual keys that will be used to perform the encryption and these keys have to be authenticated. The way the key exchange works makes it so typically no one in the middle knows the key used for encryption by either side, but that depends on the keys being authenticated afterwords to know no one in the middle swapped them out for their own, which would be known to the evesdropper. Take out the authentication portion and the evesdropper can just give each side its own keys so reading the encrypted data is just as easy as it is for your client or the server. The encryption in SSL is symetrical, meaning both sides have to know the keys used by the other side. Its typically AES or DES, the connection is first authenticated, then a key exchange happens, then the keys are verified, THEN encryption starts and the real data part of the connection happens. If you can't authenticate that the keys were generated by the person/machine they were supposed to be generated by, you can't assume the encryption keys have not been falsified.
Why? 9 times out of 10 there are easier ways to get to someones data than bothering with sniffing. Most of the time its far faster to just brute force some shitty password than to wait around to catch it across the wire, ESPECIALLY in a switched enviroment where you aren't going to even SEE the traffic. If you're already in control of a router along the path, then you can easily work around any certificate which can't be verified by the client, which self signed certs can't be, hence the warnings. If you distribute the cert to the client in a different (hopefully secure) way, you won't get the warnings and you'll not have the security issue since the cert CAN be verified.
Re:The implications? (Score:5, Insightful)
It may be slightly off-topic but the parent has a VERY valid point. Self-signed sites are encrypted but best of luck trying to get people to use them thanks to the 3-clicks required and SMALL text. When I used the new firefox release I was even confused at first.
Now back to obfuscated TCP: This is on par with using NAT to fix the lack of IP addresses. Just fix the damn thing properly and stop screwing around with time wasting half-fixes (yeah they admitted it).
About the only thing this is going to do is make troubleshooting problems with Ethereal or other packet sniffers a pain in the a$$. Thanks.
Just make it cheaper (Score:3, Insightful)
Just make SSL cert cheaper and get rid of all the multiple server licensing and crap.
Make the damn thing ran by a non-profit organization and cut the cost.
So fucking wrong it isn't even funny. (Score:2, Insightful)
Self signed certificates means LESS security, UNLESS you have verified the certificate (or its fingerprint) out of band.
Why?
Ranking:
1. Signed certificates are, in theory (but not in practice), safe.
2. No certificate means your communication may be sniffed.
3. Self-signed / Wrong URL certificates indicates that someone is a man-in-the-middle.
Yes, there might be some cheapass on the other end. However, that is up to you to verify. If you out-of-band verify that, and manually add the certificate on your end, then the 3 would go up to a number 1 - after verifying the fingerprint. Until that, it's an indication that it's a man in the middle.
In other words, that someone is actively sniffing the conversation.
The entire idea that self-signed certificates gives ANY security is insane! If someone is able to intercept the traffic and listen to it - they are most probably able to be a man in the middle. In other words - it provides absolutely no security what-so-ever ! ... unless it's verified out of band, but then it would be added to your local certificate store, and thus be a number 1.
That you have been rated as 5 is completely nuts. You don't understand the security model, and neither does the moderators.
slashdot needs more techies.
Re:Problem isn't computation... (Score:5, Insightful)
For a public site using non-standard ports is an easy method to shoot yourself in the foot - you immediately block all users behind proxies or firewalls that only allow communication on "standard" web ports.
Re:Problem isn't computation... (Score:1, Insightful)
doesn't work for IE on WinXP.
Unfortunately, that means it doesn't work. :-/
Re:The implications? (Score:3, Insightful)
He signs posts:
Adam Langley
Google Engineering
... not google's idea?
Re:The implications? (Score:5, Insightful)
Re:Ignorance and laziness is helping even less (Score:3, Insightful)
It should by default accept a self-signed cert transparently without any fuss. It SHOULDN'T show a big green lock. It should just be a regular connection. If the self-signed cert changes on a subsequent visit, THEN they should get a warning. That's it.
The problem is, we've tried to train users to look for the "https" or the lock, or both. Getting rid of the lock for self-signed connections is fine, but the https is still there, and it's misleading.
Re:Firefox isn't helping (Score:3, Insightful)
Re:So, wait... (Score:2, Insightful)
misleading title
It's a little-known fact that "Posted by kdawson" is Slashdot-ease for "better read TFA because TFS is FUBAR".
Arrgghh! No more videos! (Score:5, Insightful)
If you watch the video, your brain will leak out through your ears. It's terrible. Why produce a video which seems to be a black screen with a dark blue line wiggling when the person talks? Why pick a person with a crappy British accent and a speech impediment? Who's going to understand? Why flash up a couple of words here and there like "SSL" and "HTTP"? Why produce such a steaming pile of crap and call it an "introductory video"?
Instead, whoever is the video star in this could have written down their ideas in plain text. That would allow for easy reading and comprehension by people all over the world. Maybe I can read quickly. Maybe I don't want to sit around waiting for you to lisp and stammer through your presentation. Maybe I'd understand it better if I read it than if I heard it on a crappy video. Maybe I don't want to waste my bandwidth downloading several megabytes of video, where the same information in plain text might be a few kilobytes.
Re:The implications? (Score:2, Insightful)
It's so that it costs more to index the web
No.
Indexing has nothing to do with sniffing data. Obfuscated TCP is opportunistic, which means that it only happens if the client requests it. It is not required.
This doesn't change indexing at all, except that if you really wanted, you could encrypt your spider traffic when spidering compatible web servers.
Re:The implications? (Score:2, Insightful)
Re:surveillance (Score:3, Insightful)
can prevent ISPs from placing their own adverts into webpages.
Exactly - this is what Google is interested in. If ISPs start replacing Google adverts in web pages with their own (or worse, the AdWords adverts in Google search results), then Google will lose huge amounts of revenue. Luckily, but only by chance, Google's self-interest in this case is aligned with ours.
Rich.
Re:Net neutrality. user owned. (Score:3, Insightful)
You answered your own "why not?"
NSA and ISPs like to snoop, data mine and traffic shape. Traffic shaping can even be a good thing in certain situations (and I'm not talking Comcast here.) It's highly unlikely anything like obstcp will ever get standardized, since it prevents exactly what you just mentioned.
Re:Net neutrality. user owned. (Score:2, Insightful)
The point of this obfuscation is to make it harder to sniff traffic, but not have the high administrative and computational cost of actually making it impossible.
You might be protecting your traffic from the wardriving kid next door, but not from your ISP, let alone NSA.
Re:The implications? (Score:2, Insightful)
Even if you are presented by a Man in the Middle's self signed cert and accept it, you're traffic's still encrypted and secure from eavesdropping. It's just that the receipient changed without you realizing it.
So you now have one eavesdropper, while plain unencrypted HTTP would allow an arbitrary number of them without you knowing. Security would be broken either way, but encrypted, not authenticated traffic still is preferable to neither encrypted, nor authenticated traffic.
Re:The implications? (Score:5, Insightful)
you're [sic] traffic's still encrypted and secure from eavesdropping
Except from the party that did the MITM attack, which is most often the party that you want to prevent watching your traffic, you know, the one that is actually interested in sniffing your traffic..
Re:Arrgghh! No more videos! (Score:4, Insightful)
I'm glad I'm not the only one who feels this way. It takes way more time to absorb information from a video - more than I'm usually willing to give.
If you must make a video, at least provide a transcript.
Re:Arrgghh! No more videos! (Score:3, Insightful)
Maybe that's the whole reason it was put on video instead. For some ideas, understanding it and thinking it is a good idea are inversely related. This sounds line one of those.