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."
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.
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.
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.
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.
>
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/ if you wanted more info.
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.
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.
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!
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:
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:
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.
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?
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!) as part of it advances the same idea.
Anybody remembers what hapenned to RFC 2817 ? 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.
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/
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.)
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
At least watch the video before asking questions that it answers.
"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).
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
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.
This suggestion is insanity!
This. Is. SLASHDOT!
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.
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.
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 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.
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?
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.
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.
He signs posts:
Adam Langley
Google Engineering
... not google's idea?
This is stupid. Nobody crawls the web by sniffing traffic. Google and everyone else connects to webservers the same way you do. For your post to make any sense we have to assume that this would make sites using Obfuscated TCP inaccessible by default, which goes against its entire design philosophy.
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.
"Well kids, you tried your best, and you failed. The lesson is, never try."
misleading title
It's a little-known fact that "Posted by kdawson" is Slashdot-ease for "better read TFA because TFS is FUBAR".
'a';DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%'... if you're reading this, it didn't work.
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.
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.
This is NOT "security through obscurity". It is a form of what's called "Better-Than-Nothing" security. This topic is even worked on in the IETF for IPSec. (btns working group). The idea is that, with a gnashing of teeth, you should admit that the deployment barrier for proper security, which solves all your problems, is too high for general adoption. Then, after having made up your mind in that respect, try to figure a method that only solves a subset of problems, but for a significantly lower price. Obfuscated TCP seems to provide the property of confidentiality, but not endpoint authentication. You are right that you can still do MITM, but still it is better than nothing. I proposed something similar for wireless LANs to some vendor some time ago, which I called WPA-NoAuth, where the traffic between STA and AP gets encrypted, but none of the two endpoints authenticates to each other. This would typically cater for "web-portal" authentication, where the authentication happens after associating with the AP, and no proper security schemes like IEEE 802.1X or WPA-sharedkey can be used. Wasn't picked up with great enthusiasm though. Let's see if obfuscated TCP does. (Disclaimer: I have nothing at all to do with the obfuscated TCP proposal, nor do I work for Google)
Continuous positive slashdot karma since... uh, maybe next year.
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++;
I think you are confusing encryption with authentication.
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.
Truth arises more readily from error than from confusion. -Francis Bacon
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..
c++;