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."
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:
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?
Except there's a bug in IE where you cannot change the protocol (http->https) and the port at the same time. Maybe they've wised up and fixed it; I don't use IE whenever possible.
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?
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++;