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."
The problem isn't computation - its a training thing. People who will encrypt will encrypt. Those who wont, wont.
Something better they could do: give out http ssl certs for free under their own root cert (which major browsers trust). The big barrier to ssl for small sites is cost - in some cases the cost of an ssl cert will exceed all other costs.
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.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
"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.
Every time a Firefox or SSLTLS article comes up, we go over this again and again. SSLTLS is both an encryption and authentication scheme; it sucks but that's what the spec says it is. Firefox can't go off and do its own thing, least someone starts exploiting the fact that their implementation of SSLTLS is no longer an authentication scheme and starts taking advantage of people who expect otherwise. The W3C needs to separate authentication and encryption in the standards themselves, that's the only proper and safe way to change things.
There's an ambiguity to SSL certs. They do two things at once. They 1) prove that the person who has the cert is that person through a certificate authority and they 2) provide for encryption. Why not simply have grades of SSL? A self signed cert could then allow encryption and say perhaps show a yellow padlock whereas a CA signed cert could provide for encryption and provide CA authentication and give a green padlock or whatever. What's so freaking difficult about that?
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?
I read the technical details 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:
That's not really the point though. It raises the bar of work needed to implement these snooping systems and can prevent ISPs from placing their own adverts into webpages.
Seriously, not trying to troll, but wasn't this problem solved more completely by IPSEC back in 2000? Why hasn't IPSEC been adopted more? Why should this solution fare any better?
This is SNI ( http://en.wikipedia.org/wiki/Server_Name_Indication ) and it is not supported on Safari (any version I am aware of I just tried a nightly build on an intel iMac) nor on any version of IE on XP or earlier. You can verify by visiting https://sni.velox.ch/ and see if you get a warning.
Also you don't need gnutls for SNI since support for SNI has been backported into OpenSSL 0.9.8: http://cvs.openssl.org/chngview?cn=16435
Comment removed based on user account deletion
If the objective is to prevent large-scale keyword sniffing, then you can obfuscate it with compression.
The support is already built into the browsers.
Yes I know its not encryption, but if everything was gzip'd then it would cost the listener more to decrypt it. Plus gzip'd data would not invite any added attention.
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.
TFA explains how Obfuscated TCP is both opportunistic and transparent. Servers will provide encrypted transmission only when the client requests it, and unlike SSL/TLS there is no additional handshaking required to setup the connection.
A car analogy. Suppose you use regular unleaded fuel in your car and it drives fine. High octane fuel then becomes available at a higher cost. Your car continues to drive fine on regular unleaded, but you have the choice to fill up with high octane at any petrol station that serves it.
This costs you more, how?
The problem is you can't not display the "https". Also, the security of existing links (bookmarks, for example) using the "https" scheme is affected. Right now if you have an https link you know before even clicking it that either it will be fully secure or rejected. Adding a third option that requires checking the lock icon and making a judgement about the likelihood of man-in-the-middle attacks is a non-starter for browser vendors. Educating everyone in the world about man-in-the-middle attacks and when to worry about them is simply not an option.
Maybe what is needed is a new URL scheme (httpi://?) for self-signed SSL. That way the security of existing https links is unaffected. It would be really nice, though, if you could just use "http" as the scheme and automatically get self-signed cert security when both the server and client support it. Hey! That's exactly what the article proposes! Imagine that!
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
What's wrong with the SSH approach? First time you see a cert, inform the user. If it changes in the future, freak the hell out. It works great for ssh and solved the whole key distribution problem. It's magnitudes better than the current situation in browsers.
No, This is about making the net more neutral.
ISP cannot look into obfuscated traffic, and thus cannot traffic shape it. (note that torrent/eMule is also obfuscated enabled)
ISP/NSA cannot datamine obfuscated traffic. Only targetted traffic can be obfuscated.
State censors cannot block traffic based on keywords. (chinese wall)
It is more a "why not?" statement.
Self-certified certificates are worse than plain unencrypted traffic because of psychological reasons, not because of technical reasons.
Your ISP can easily and automatically intercept self-signed certificates and present their own certificate, which you will gladly accept. Now you think that you are less secure than a verified certificate but still "somewhat secure". Technically, you are however protected as much as plain unencrypted HTTP.
Now, this is where humans fail. Because you still think you are "somewhat safe", you will take higher risks, write things that you would normally not write, click on links that you perhaps wouldn't click on over a plain non-encrypted page. The famous false sense of security, which actually does nothing except making you feel good.
c++;