Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google's Obfuscated TCP

kdawson posted more than 5 years ago | from the shake-hands-when-you-say-that dept.

Encryption 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."

cancel ×

392 comments

Sorry! There are no comments related to the filter you selected.

The implications? (2, Insightful)

RudyValencia (728937) | more than 5 years ago | (#25294345)

Wouldn't this result in a greater amount of, say, phishing sites?

Re:The implications? (5, Interesting)

MBCook (132727) | more than 5 years ago | (#25294409)

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.

Re:The implications? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25294459)

I just took a monster shit. It was as long and thick as Barack Obama's cock (for those of you who haven't had an opportunity to suck it, it's 7 inches, thick, and uncut). I was almost surprised there was no blood when I wiped my ass.

Re:The implications? (0, Offtopic)

Anonymous Coward | more than 5 years ago | (#25295095)

Watch it, it might be your trolly brain going down the pipe right at this moment...

Re:The implications? (1, Insightful)

Anonymous Coward | more than 5 years ago | (#25294619)

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:The implications? (1)

ceoyoyo (59147) | more than 5 years ago | (#25294743)

Yes, half of the exchange not knowing that there is "encryption" going on is definitely a plus.

That point alone seems to me a good reason to be suspicious.

Problem isn't computation... (1, Interesting)

Anonymous Coward | more than 5 years ago | (#25294381)

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.

Re:Problem isn't computation... (1)

BoChen456 (1099463) | more than 5 years ago | (#25294467)

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.

Only if Google is going to foot the bill to verify each site they are providing SSL certs for, and maintain cert revocation lists. Its pointless to use SSL if you can't trust the CA to only provide certs to genuine sites. Verisign at least verifies the requester of the certificate is the owner of the dns entry. And that is where most of the cost of a SSL cert goes to.

Re:Problem isn't computation... (1)

mzs (595629) | more than 5 years ago | (#25295001)

Those are some expensive ten lines of perl code then.

Re:Problem isn't computation... (4, Informative)

syzler (748241) | more than 5 years ago | (#25294593)

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.

Re:Problem isn't computation... (4, Informative)

Timothy Brownawell (627747) | more than 5 years ago | (#25294893)

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.

Re:Problem isn't computation... (4, Insightful)

this great guy (922511) | more than 5 years ago | (#25294985)

You have 2 solutions:
  • Run your websites on different ports, you have 65535 of them per IP. Make http://site1/ [site1] redirect to https://site1:1111/ [site1] , http://site2/ [site2] redirect to https://site2:2222/ [site2] , etc. I concede this prevents users from directly typing the https url in their address bar as they don't know the port number in advance, but again 99% of the users let themselves be redirected to the https content on most websites anyway (except paranoids like me :P).
  • Use certs with the "subjectAltName" X.509 extension that let you create a single cert valid for multiple DNS names. I do this (with a CA I created & control), it works very well. The downside is that I think commercial CAs make you pay extra bucks to sign such certs (if they even accept to do that).

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:Problem isn't computation... (1)

mzs (595629) | more than 5 years ago | (#25295033)

Or you could have the forms and what not use https://example.com/foo/action [example.com] and https://example.com/bar/action [example.com] for your different sites. There is the possibility of a MITM creating a copy of your site with the action pointing to http://evil.invalid/foo/action [evil.invalid] instead though but maybe these sites are not so important. Alternatively you could simply let everyone know that the site is really at https://example.com/foo/ [example.com] and the other is at https://example.com/bar/ [example.com] .

Re:Problem isn't computation... (0)

Bill, Shooter of Bul (629286) | more than 5 years ago | (#25294839)

Really? $400 a year for a verisign (one of the most expensive) cert is a barrier that exceeds all other costs?!? Seriously? If that's the case, then their Business Plan sucks.

So, wait... (0)

Bragador (1036480) | more than 5 years ago | (#25294385)

On one day Google is evil and doesn't care about privacy, and on the other day it cares about privacy...

Are we supposed to like Google or not now?

I'm confused :(

Re:So, wait... (5, Informative)

Anonymous Coward | more than 5 years ago | (#25294419)

It's not written by Google, it's just hosted by them. Big difference, misleading title.

Re:So, wait... (1)

mrbene (1380531) | more than 5 years ago | (#25294549)

Well, either alangley is taking advantage of the Google Hosting and sortof the brand, or he's actually a Google Employee doing this type of stuff [imperialviolet.org] on his free time.

Re:So, wait... (0)

Anonymous Coward | more than 5 years ago | (#25294463)

this is hardly them caring about privacy. It is technology that in no way restricts there annal probing into you. It does however provide a "limited" amount of security to general comms on the net, however it still gives you no protection to targeted attacks. To me the whole thing seems pointless, anyone caring enough about there security will not want such a weak security protocol and those that don't care still won't.

Re:So, wait... (3, Insightful)

cjfs (1253208) | more than 5 years ago | (#25294479)

>

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.

Re:So, wait... (1)

Bragador (1036480) | more than 5 years ago | (#25294563)

Ah thanks. See, I completely misunderstood the summary. I get it now...

Re:So, wait... (0)

Anonymous Coward | more than 5 years ago | (#25294979)

You mean my entire world can't be broken down into simple black and white? Arggg, where will it vent my angst now!!!!!! I guess I'll have to settle for overly simplistic commentators as the center of my ire....

Sounds like a bad idea (-1)

Anonymous Coward | more than 5 years ago | (#25294387)

It does sound like a bad idea. General populace doesn't care what kind of "protection" websites have, if there's some cheap mode of encryption they'll just assume it's good because it's in the use. Basically the general populace will be duped into false sense of security.

The Right Thing To Do (TM) would of course be to provide users with as much security as you can (and is actually viable. No need for 2 guards behind the user every time they log in). But oh well, companies like to save money wherever they can..

Firefox isn't helping (4, Insightful)

vux984 (928602) | more than 5 years ago | (#25294399)

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.

Re:Firefox isn't helping (4, Interesting)

0123456 (636235) | more than 5 years ago | (#25294441)

"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.

Re:Firefox isn't helping (5, Informative)

Kjella (173770) | more than 5 years ago | (#25294513)

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.

Re:Firefox isn't helping (1)

RiotingPacifist (1228016) | more than 5 years ago | (#25294569)

or provide a warning when using the lesser security so that users are aware of whats going on???

Re:Firefox isn't helping (5, Interesting)

profplump (309017) | more than 5 years ago | (#25294807)

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?

Re:Firefox isn't helping (4, Insightful)

Free the Cowards (1280296) | more than 5 years ago | (#25294519)

The point being that this is the actual security hierarchy, from best to worst:

  1. SSL with cert signed by a trusted certificate authority
  2. SSL with self-signed cert
  3. Plain HTTP

Whereas most web browsers make it appear like this:

  1. SSL with cert signed by a trusted certificate authority
  2. Plain HTTP
  3. SSL with self-signed cert

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 (1)

Sancho (17056) | more than 5 years ago | (#25294881)

The thinking behind the current browser behavior is that the while self-signed certs provide encryption, they do absolutely nothing to try to verify that the remote host is who they claim to be. Providing a lock symbol (which, over the years, security professionals have tried to train users to trust) when there is nothing even resembling validation does a disservice to the user. There is no need to make such a fuss over plain HTTP because users have been trained not to send credentials over plain HTTP. There's usually a popup that warns you about transmitting sensitive information in plaintext, anyway--and it's been like that for years.

I'm really torn on the issue. Most of the time, I think that the perception of security where there is none is worse than a blatantly obvious lack of security.

Re:Firefox isn't helping (5, Insightful)

Free the Cowards (1280296) | more than 5 years ago | (#25294901)

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".

Re:Firefox isn't helping (4, Insightful)

Zadaz (950521) | more than 5 years ago | (#25294535)

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.

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:Firefox isn't helping (0)

0123456 (636235) | more than 5 years ago | (#25294665)

I'm sorry, but anyone arguing in favor of not putting up big warnings when a browser sees a self-signed cert is a dumb-ass. It's that simple.

Encryption without authentication is worthless to anyone who cares about security; if you don't know who you're communicating with, what's the point of encryption? For all you know, they're the very people you're trying to hide from.

If you want weak, easily-eavesdropped point-to-point encryption then SSL is a lousy place to do it. You should be calling for widespread use of IPSEC and similar protocols which will encrypt everything for you automatically with at least as much security as self-signed certs (i.e. none or greater); and if you don't understand this, you shouldn't even be discussing network security.

Re:Firefox isn't helping (1)

snaz555 (903274) | more than 5 years ago | (#25295089)

IPsec is unusable for this since it also hides the headers. Firewalls need to see headers to enforce policy, and if they can't they'll rightfully reject traffic. (I.e., reject what can't be positively confirmed as acceptable.) With an open key distribution scheme as proposed in obstcp (via DNS CNAME) a firewall that lets IPsec through might as well not exist. This is one of the big reasons IPsec today is used for VPN tunnels between firewalls/routers and just about nothing else. An ISP that sees IPsec can safely assume it's a VPN tunnel and you're telecommuting.

Under the proposed key distribution scheme, a man-in-the-middle relay attack requires DNS hijacking or spoofing as well. Sure, it can be done. But this raises the bar for an ISP from "sure, just listen in!" to the legally risky. Do you think Comcast would spoof DNS for, say, a speakeasy customer? Or obs.example.com? I doubt they'd dare touch it, and if they did they'd soon find themselves in court.

Re:Firefox isn't helping (1)

mikenap (1258526) | more than 5 years ago | (#25294707)

Except breaking SSL with a self-signed cert can be automated and simple. If someone else controls any part of the path between you and the destination(read ISP, access point owner, etc), they can automatically man-in-the-middle any connection with a self-signed cert.

It's like using a sign in sheet on your door to detect if anyone has entered your house without your permission. Without locks. No effort to break, and easy to give a false sense of security.

Re:Firefox isn't helping (1)

cecil_turtle (820519) | more than 5 years ago | (#25295101)

Maybe, but listening to unencrypted traffic is even easier and more simple to automate, and you don't have to "control" any part of the path, you just have to be a peer on the wire. Larger target, easier to do. And I don't believe your door lock simile is actually representative of what's going on with self-signed SSL. If all traffic on the net were at least self-signed SSL, you completely eliminate the "low hanging fruit" and raise the bar for an attacker, requiring more and more complex tools to setup, more CPU power, etc.

Re:Firefox isn't helping (1)

bluefoxlucid (723572) | more than 5 years ago | (#25295041)

Straw man: The keyed lock argument is easier to prove false, and seems naively analogous to the SSL problem.

We are instead talking about a keyed lock where I, as an attacker, can walk up to your house after you leave and use a key with a specially shaped tip to to prime the lock for accepting a new key (in addition to the old key-- this is not technically identical, but from a user interface point it is the same interaction). I can then unlock your door with my completely random key; when you get home, your key will also unlock your door.

The "key with a specially shaped tip" is Ettercap, with a MitM spoof plug-in that rewrites self-signed SSL cert responses (it can take over the role of your wireless router with an ARP spoof, point and click); the key itself (the pin tumbler layout) is my self-signed cert (unlocks your conversation); the lock is the SSL handshake process. QED.

Re:Firefox isn't helping (0)

mikenap (1258526) | more than 5 years ago | (#25294627)

EXACTLY! With a self-signed certificate, there's no indication that a man in the middle attack is taking place. In which case, anyone that can sit between you and the server, can pretend to be the server(controls/owns/attacks your DNS server) or can beat the server in responding to you, can eavesdrop.

SSL without a trusted certificate provides NO additional security over communicating in the clear. AT ALL.

For those who haven't heard of the attack(and have lived under a rock ever since asymmetric cryptography was invented), it consists of an evil entity that you connect to instead of the server. You negotiate an encrypted connection with the evil entity, which then negotiates an encrypted connection to the real server. It then passes all the data between the two connections in addition to logging it. BAM, eavesdropping.

A certificate allows a proof that the entity you THINK you negotiated the encryption with REALLY IS the entity you have negotiated the encryption with.

Re:Firefox isn't helping (5, Insightful)

QuasiEvil (74356) | more than 5 years ago | (#25294719)

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:Firefox isn't helping (2, Informative)

jrockway (229604) | more than 5 years ago | (#25294763)

However, it takes a great deal more work to set up than a simple sniffer,

Indeed. You have to press one additional key to forge SSL connections in most "off-the-shelf" sniffers. I recall doing this with ettercap many years ago.

Re:Firefox isn't helping (0)

Anonymous Coward | more than 5 years ago | (#25295085)

So what you're saying is if I go to amazin.com and buy a book with my credit card over SSL terminating in a random certificate I should feel good because my ISP could not read my CC# en route to the hostile. I trust my ISP and the backbone providers more than I trust joe I don't know.

Re:Firefox isn't helping (2, Insightful)

Timothy Brownawell (627747) | more than 5 years ago | (#25295039)

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:Firefox isn't helping (4, Interesting)

rsmith-mac (639075) | more than 5 years ago | (#25294507)

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.

Re:Firefox isn't helping (1)

jlarocco (851450) | more than 5 years ago | (#25294509)

The problem (I think) with treating self-signed certificates as 'unsigned with the added bonus that communications can't be eavesdropped' is that it would rely on site owners not asking for sensitive information while using a self-signed cert.

Most users are too dumb to check for SSL, good luck getting them to discern insecure, 'insecure but can't be eavesdropped', and secure. Hell, most users would be shocked to find out you can eavesdrop on their traffic in the first place.

Re:Firefox isn't helping (1)

at.drinian (1180281) | more than 5 years ago | (#25294547)

Firefox 3.0's self-signed certificate system is much better than the old one because it allows you to store security exceptions, much like in, say, SSH. That way, you will get a warning that the cert has changed in the future, indicating a potential eavesdropper. It eliminates a number of vulnerabilities (although, of course, not MITM attacks on the initial certificate exchange). I don't understand all the hate for it.

Re:Firefox isn't helping (5, Interesting)

defaria (741527) | more than 5 years ago | (#25294585)

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?

Re:Firefox isn't helping (1)

MrMista_B (891430) | more than 5 years ago | (#25294649)

So, based on what you've said, would it be fair to say that Firefox's police on sielf-signed certs... is damaging internet security?

Re:Firefox isn't helping (1)

gregorio (520049) | more than 5 years ago | (#25294831)

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.

Firefox is right about this. Most people rely on the little lock icon to "make sure this is really the bank's website". If you think about it, it's probably the only way to be really really sure that the website you're visiting actually belongs to "Bank ABC". Warning the user about self-signed certificates prevents people from making keys such as "Citibank - NY" while looking legitimate.

Public certificates aren't expensive. If your site is not worth a few bucks, then those warnings are ok.

Re:Firefox isn't helping (1)

Wildclaw (15718) | more than 5 years ago | (#25294987)

In that case don't display a damned lock when there is an unsigned certificate. Really how much of an idiot do you have to be to not be able to see that simple solution?

And yes, it really is true idiocy to treat an unsigned certificate transmission worse than a plain text transmission. Point Haired Boss worthy material.

Re:Firefox isn't helping (1)

mysidia (191772) | more than 5 years ago | (#25294843)

The browsers have got it all wrong... they should be displaying no error messages at all, for an unknown CA, self-signed, or expired cert.

Only an indication that the site is insecure; just as if it were not encrypted at all.

Warning messages should only be shown when the domain name of the site disagrees with the CN of the certificate, or the cert is a revoked certificate (meaning tampering has definitely occured).

Doesn't help (0)

Anonymous Coward | more than 5 years ago | (#25294983)

self signed certs aren't appropriate for processing credit cards

VanillaMastercard [vanillamastercard.com] throws up some warning on Firefox

OE is a nice idea (1)

Plug (14127) | more than 5 years ago | (#25294403)

Opportunistic encryption was the original goal of the FreeS/WAN [freeswan.org] project. It was not realised, and the eventual forks (OpenSwan and strongSwan) are now aimed more at running IPSEC tunnels.

Re:OE is a nice idea (3, Informative)

whoever57 (658626) | more than 5 years ago | (#25294671)

Opportunistic encryption was the original goal of the FreeS/WAN [freeswan.org] project. It was not realised,

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.

You need to do WHAT? (0)

Anonymous Coward | more than 5 years ago | (#25294407)

Patched server? Patched browser? Special DNS entries? Wow. I bet all the people that found SSL too difficult to implement will jump at this.

Re:You need to do WHAT? (1)

mzs (595629) | more than 5 years ago | (#25294491)

I agree. What is wrong with self signed certs? Scary warnings from the browser? That can be educated. Too slow? Hardware is faster now.

Re:You need to do WHAT? (0)

Anonymous Coward | more than 5 years ago | (#25294699)

There's a reason for the scary warnings - because the browser can't be sure where you're connecting to. That's not really so secure.

Re:You need to do WHAT? (1)

mzs (595629) | more than 5 years ago | (#25294841)

That is why you check the cert and add it to your personal list of allowed (by checking it carefully you prevented the initial MITM). Then if the cert ever changes you get notified of the change (catching a later MITM). Again like I said, I am not against the scary warnings, I'm for user education. It is simply a user education thing.

surveillance (4, Insightful)

TheSHAD0W (258774) | more than 5 years ago | (#25294411)

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 (2, Insightful)

syzler (748241) | more than 5 years ago | (#25294517)

... care needs to be taken to avoid a false sense of security.

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:surveillance (0)

Anonymous Coward | more than 5 years ago | (#25294551)

Surveillance is often legal in certain circumstances (remember the FBI claiming e-mails can be snooped without a warrant because they didn't have to "open" them?) but MITM attacks are most assuredly illegal in all but a few circumstances. This only helps the individual against big brother.

Re:surveillance (4, Insightful)

Free the Cowards (1280296) | more than 5 years ago | (#25294555)

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.

Re:surveillance (1)

cjfs (1253208) | more than 5 years ago | (#25294567)

Again, no indicator will be given the connection is anything more secure than plain text. This is just raising the bare minimum level of security.

Re:surveillance (2, Interesting)

LingNoi (1066278) | more than 5 years ago | (#25294899)

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.

Google's Obfuscated TCP? (1)

cowbud (200323) | more than 5 years ago | (#25294415)

How is this google's? Sure it is hosted on code.google.com but I see no link to google itself doing this.

The problem is IPv4 (1, Insightful)

Anonymous Coward | more than 5 years ago | (#25294437)

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

The problem is SSL (0)

Anonymous Coward | more than 5 years ago | (#25294621)

TLS deals with this problem. It's just not widely supported, although perhaps more common than ipv6.

Re:The problem is IPv4 (1)

Sancho (17056) | more than 5 years ago | (#25294645)

That's actually a problem with OpenSSL and mod_ssl. Check out mod_gnutls and gnutls for an approach where name-based virtual hosts can each have their own certificate that validates in most current browsers (Safari, Opera, Firefox, IE7).

Damn Videos (1)

Anonymous Coward | more than 5 years ago | (#25294471)

What the hell are people thinking making information in videos like this?! There is no added value at all; it just makes it exponentially more difficult to get the information!

This one however took the cake. The video is a black screen and narration... with a few random words or tags thrown up.

I know Google owns You Tube and all... but this has to be one of the dumbest uses of the medium I have seen and continue to see.

Sad. Web, meet TV.

Re:Damn Videos (1)

agl42 (1380303) | more than 5 years ago | (#25295087)

You have a fair point there, but you would be surprised how many more people will sit through the video than would read a page explaining the same. I don't much like the video either, but I did it for the reason above. I guessed that people smart enough to get frustrated with it probably didn't need it.

NOT GOOGLE (5, Informative)

Zutroi_Zatatakowsky (513851) | more than 5 years ago | (#25294475)

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 (5, Informative)

Plug (14127) | more than 5 years ago | (#25294493)

He's a Google employee. [blogspot.com] .

(Standard 20% time disclaimer etc)

Re:NOT GOOGLE (2, Informative)

Anonymous Coward | more than 5 years ago | (#25294801)

Official Google projects use the "Google" label, including 20% projects: http://code.google.com/hosting/search?q=label%3AGoogle [google.com]

So either this wasn't a work-related process, or he forgot.

Less secure than 128bit SSL? Why? (3, Insightful)

Culture20 (968837) | more than 5 years ago | (#25294485)

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:Less secure than 128bit SSL? Why? (1)

cjfs (1253208) | more than 5 years ago | (#25294523)

As mentioned in the video - this is intended to be transparent to the user. They'll be no indicator claiming it's a secure connection, no url or port change, etc.

Re:Less secure than 128bit SSL? Why? (1, Informative)

Anonymous Coward | more than 5 years ago | (#25294721)

It is less secure because the keys are not verified, so a man-in-the-middle attack would work, but a passive attack (just listening) would not. It sounds like it uses DNS to verify the keys, so it may become (more?) secure if DNSSEC were implemented.

Re:Less secure than 128bit SSL? Why? (2, Informative)

mrbene (1380531) | more than 5 years ago | (#25294805)

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:

  • Obfuscation != Encryption
  • Cost to Encode (encrypt/compress/obfuscate) does not directly relate to the cost to decode. The relationship differs per algorithm used.
  • Cost to de-obfuscate without proper keys can be significantly more than cost to de-obfuscate with proper keys.

Trusts DNS instead of CA signature (5, Insightful)

mikenap (1258526) | more than 5 years ago | (#25294565)

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:Trusts DNS instead of CA signature (2, Insightful)

Kjella (173770) | more than 5 years ago | (#25294713)

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:Trusts DNS instead of CA signature (1)

mikenap (1258526) | more than 5 years ago | (#25294771)

SSL requires a chain of trust somewhere. If you use self-signed certificates without some process of authenticating them(say, in person), you're not using SSL as intended.

This system always trusts DNS...which is NEVER secure without some additions(like DNSSEC).

Re:Trusts DNS instead of CA signature (1)

mikenap (1258526) | more than 5 years ago | (#25294791)

Or another way of putting it...any cryptosystem can be broken if the users intentionally misuse it by sharing keys, using unauthenticated keys, sharing all their plaintext on their blog, etc. That shouldn't factor into an analysis of the intended use of the system.

Re:Trusts DNS instead of CA signature (1)

mzs (595629) | more than 5 years ago | (#25294797)

Also you need either A) a CNAME (rejig your whole site) or B) hacked DNS resolver (HA! I bet only an eighth of ISP DNS server even handle more than the common records correctly as is).

Basically what is outlined is if you own example.com, you make a web site http://www.example.com/ [example.com] and then have:

www.example.com. 30 IN CNAME 0000000abcdef.abcdef.example.com.
0000000abcdef.abcdef.example.com. 30 IN A 1.2.3.4

The hex is a key and a tcp port. It would be trivial as you said for the ISP to deliver instead:

www.example.com. 30 IN CNAME 000000011cafe.abcdef.example.com.
000000011cafe.abcdef.example.com. 30 IN A 0.6.6.6

Also I would love to see someone have used already used cafe.f00d.example.com or some such and have it spectacularly break.

Re:Trusts DNS instead of CA signature (1)

galvanash (631838) | more than 5 years ago | (#25295063)

Sorry, but that is a stupid argument. For unencrypted traffic (the vast majority of all traffic) - we essentially trust dns NOW. So your point is that this is a bad idea because someone might forge the DNS entry... They can already do that - this makes it no easier to accomplish. Its encryption, not endpoint validation...

computationally cheaper? (1)

Korbeau (913903) | more than 5 years ago | (#25294647)

oh man, if you'd seen what lays under some websites, you'd be surprised as how it's not encrypting the transmission that is computationally expensive.

And men-in-the-middle-attacks?! (1)

Korbeau (913903) | more than 5 years ago | (#25294675)

I mean ... do they really exists? Except for the paranoids ... I've never seen such attack make headlines.

Point is: I don't mind people seeing me using my free net, naked and full of anarchy ... I just don't want them to see my credit card number ... and my bank uses secure HTTP.

Re:And men-in-the-middle-attacks?! (1)

LingNoi (1066278) | more than 5 years ago | (#25294963)

I'm assuming you also don't want your ISP inserting adverts into your slashdot?

You might not mind but I do mind, encrypting all traffic means no advert inserting, no network neutrality problems, no US government reading my email, etc.

Yeah, they might break the encryption, but so what? Just plug the security hole and continue.

They could have done better (4, Interesting)

this great guy (922511) | more than 5 years ago | (#25294819)

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:

  • This technique works using standard TLS/SSL technology, no need to reinvent a poor man's TLS protocol like they did with Salsa20/8, Curve25519, Poly1305, etc.
  • It is just as secure as their "Obfuscated TCP" (both techniques rely on the DNS records not having been tampered).
  • The SHA1 fingerprint being encoded in the CNAME allows the browser to verify its validity without prompting the enduser with scary dialog boxes (and it also works with self-signed certs).
  • And as a bonus, the fact a standard HTTPS server is running allows endusers who really want true security to explicitely connect to the HTTPS URL by themselves (without relying on the CNAME trick). Doing this would make the browser verify the validity of the cert using the normal way (scary dialog boxes... or not if the cert's CA is trusted).

Re:They could have done better (3, Insightful)

this great guy (922511) | more than 5 years ago | (#25294849)

Oh and I forgot one more advantage of my technique:
  • No special "Obfuscated TCP" module needed on the webserver, just configure it for HTTPS (using a self-signed cert if you want).

Re:They could have done better (1)

thc4k (951561) | more than 5 years ago | (#25294945)

And you missed the whole point of this thing: it's for those too stupid and/or lazy to set up ssl.

Re:They could have done better (1)

agl42 (1380303) | more than 5 years ago | (#25294943)

It's such a good idea that I plan to do it. Enums for it etc already exist in the code, it's just a question of writing browser support. Disadvantages are the additional RTT and, probably, more expensive cipher suites. Another advantage is that some firewalls are more friendly to outbound 443.

Re:They could have done better (1)

this great guy (922511) | more than 5 years ago | (#25295031)

Yeah I was looking at the stream cipher, Salsa20 (never heard about it before), and I see that djbdns distributes very fast implementations (less than 1 cycle/byte on amd64 holly sh1t!). Traditional TLS/SSL ciphers like AES are indeed 2 orders of magnitude (base 2) slower.

truth? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25294859)

Do Obama and the Democrats deserve a lift in the polls as a result of the financial and mortgage problems? The answer from history is a clear NO. Here's the lead of a New York Times story on September 30, 1999:

"Fannie Mae Eases Credit To Aid Mortgage Lending" [link below]. That's 1999 folks. Clinton Administration, I believe.

Here's the lead of a New York Times story on Sept. 11, 2003:

"The Bush administration today recommended the most significant regulatory overhaul in the housing finance industry since the savings and loan crisis a decade ago. "[see link below] The Democrats killed the reforms.

McCain said in co-sponsoring the Federal Housing Enterprise Regulatory Reform Act of 2005, S. 190:

"If Congress does not act, American taxpayers will continue to be exposed to the enormous risk that Fannie Mae and Freddie Mac pose to the housing market, the overall financial system and the economy as a whole. The Democrats killed the Bill.

What was Barney Frank and fellow Democrats saying at the time of these attempted reforms? According to reports, Representative Barney Frank(D-MA) claimed of the thrifts :

"These two entities -- Fannie Mae and Freddie Mac -- are not facing any kind of financial crisis, the more people exaggerate these problems, the more pressure there is on these companies, the less we will see in terms of affordable housing."

Representative Mel Watt (D-NC) added of the reforms "I don't see much other than a shell game going on here, moving something from one agency to another and in the process weakening the bargaining power of poorer families and their ability to get affordable housing." [ See Community Reinvestment Act, link below ]

Even Bill Clinton points to Congressional Democrats failure to deal with Fannie and Freddie as a primary cause.

http://www.youtube.com/watch?v=XsynspIqAoE [youtube.com]

The link below contains a purported list of the top 25 in Congress who got contributions from the folks at Fannie and Freddie. Obama is listed third, after Dodd and Kerry, even though Obama is just a junior Senator. Obama is followed next by Clinton. Barney Frank and Nancy Pelosi are on the list as well.

http://www.investors.com/editorial/IBDArticles.asp?artsec=16&artnum=1&issue=20080918 [investors.com]

Then there is the Senate Banking Committee Chairman Christopher J. Dodd who allegedly got special mortgage deals from Countrywide, who gave preferential rates to 'friends' of company's chairman.

http://www.msnbc.msn.com/id/25140560/ [msn.com]

For an interesting article purporting to detail the House Financial Services Committee Chairs long history with Fannie Mae, See:
http://www.businessandmedia.org/printer/2008/20080924145932.aspx [businessandmedia.org]

"House Financial Services Committee Chair promoted GSEs while former 'spouse' was Fannie Mae executive."

The link below describes how some in Congress tried to use the original version of the bailout bill to divert money eventually recovered to groups like ACORN, a group Obama has a long association with. See:

http://online.wsj.com/article/SB122247015469280723.html?mod=googlenews_wsj [wsj.com]

And then there is House Speaker Nancy Pelosi, who allegedly has directed nearly $100,000 from her political action committee to her husband's real estate and investment firm.

http://www.washtimes.com/news/2008/oct/01/pelosis-pac-pays-bills-for-spouses-firm [washtimes.com] .

See also:
http://www.investors.com/editorial/IBDArticles.asp?artsec=16&artnum=1&issue=20080918 [investors.com]

http://en.wikipedia.org/wiki/Community_Reinvestment_Act [wikipedia.org]

http://article.nationalreview.com/print/?q=M2QwNDhkZTg2OGYzZjkzM2E2NDEwM2U5OGVkNTc0YzU= [nationalreview.com]

http://query.nytimes.com/gst/fullpage.html?res=9E06E3D6123BF932A2575AC0A9659C8B63 [nytimes.com]

http://query.nytimes.com/gst/fullpage.html?res=9C0DE7DB153EF933A0575AC0A96F958260 [nytimes.com]

http://www.businessandmedia.org/printer/2008/20080924145932.aspx [businessandmedia.org]

http://www.investors.com/editorial/IBDArticles.asp?artsec=16&artnum=1&issue=20080926 [investors.com]

http://online.wsj.com/article/SB122247015469280723.html?mod=googlenews_wsj [wsj.com]

Where is the article about Joe Bidens longstanding relationship with the credit card industry lobby? Is that what you call looking out for the middle class?

Imple-say! (1)

fahrbot-bot (874524) | more than 5 years ago | (#25294863)

Ust-jay se-uay ode-cay.

what's wrong with ipsec? (4, Interesting)

embsysdev (719482) | more than 5 years ago | (#25294937)

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?

Whose obfuscated TCP, exactly? (0)

Anonymous Coward | more than 5 years ago | (#25294957)

What does this have to do with Google other than being hosted on code.google.com?

bs (0)

Anonymous Coward | more than 5 years ago | (#25294971)

I'd trust Google as far as I could throw them with any keys to encryption. They're so good at privacy!

Any commonplace encryption is helpful (3, Insightful)

FilterMapReduce (1296509) | more than 5 years ago | (#25294977)

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.

Tags: Post, Comment, Reply (1)

zigmeister (1281432) | more than 5 years ago | (#25294999)

So not one but two tags as "story," huh?

NOT Google's, just their code hosting (1)

agl42 (1380303) | more than 5 years ago | (#25295023)

NOT Google's, just their code hosting. Title says it all.

Reinventing ancient history (5, Informative)

PhilK (20847) | more than 5 years ago | (#25295029)

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]

Load of nothingness (1)

ZeroNullVoid (886675) | more than 5 years ago | (#25295047)

Wow, just like many keynote presentations.

There was very little useful meat to it.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?