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

Comments

The implications?

[RudyValencia]

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

Re:The implications?

[MBCook]

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?

[Anonymous Coward]

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?

[ceoyoyo]

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.

Re:The implications?

[Anonymous Coward]

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

Re:The implications?

[19thNervousBreakdown]

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?

[Anonymous Coward]

At least watch the video before asking questions that it answers.

Re:The implications?

[cryptoluddite]

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

[beav007]

This suggestion is insanity!

This. Is. SLASHDOT!

Re:The implications?

[rainsford]

That would be a good theory if this was actually Google's idea. But if you look at the link, it's on Google Code, which is a way for ANYONE to create a project and put it online. The guy writing this probably has nothing to do with Google.

Re:The implications?

[NFN_NLN]

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.

Re:The implications?

[osu-neko]

... So, adding automatic encryption raises the price back to where it was a decade ago.

*cough*bullshit*cough*

You either have no idea of the relative computational intensity of the problem vs. the other issues you mentioned, or you're imagining some bizarrely expensive algorithm be used that's far beyond what's generally used today in terms of time and memory required.

Re:The implications?

[enoz]

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?

Re:The implications?

[GigaplexNZ]

Implications?

...we might be able to increase the depressingly small fraction of encrypted traffic on the Internet

Wouldn't this effectively make the Internet illegal in countries like France where encryption is illegal?

Re:The implications?

[cryptoluddite]

He signs posts:

Adam Langley
Google Engineering

... not google's idea?

Re:The implications?

[Anonymous Coward]

The French may have gotten it right: I know quite a few Slashdot users who bought into the whole casual encryption fad and encrypted their virginity. It is unlikely to be brute-forced in their lifetimes.

Casual Encryption....
....Not Even Once.

Re:The implications?

[BitHive]

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.

Re:The implications?

[FisherRider]

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?

[Hurricane78]

To me, it sounds exactly like the security theater of "security trough obscurity" that we here at Slashdot criticize at every moment. And for good reasons. If the method has a detectable pattern that the receiving browser can decode on the fly, without a password or something alike, so can everybody else, and with the help of some scripts, you have a man-in-the-middle attack.

I think, this obfuscation will hold as long, as a standard software for the obfuscation of executables will hold back the crackers. This can take some time if it's very good, or it can be cracked at the zeroth day. And from then on, it's worthless forever.

I'm surprised someone at Google even mentioned it, because it sounds like the typical false logic of DRM and the like.

Re:The implications?

[kickdown]

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)

Re:The implications?

[hobbit]

Everyone at Google gets to work on their own project one day out of five.

Re:The implications?

[pipatron]

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.

Re:The implications?

[neumayr]

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.

Re:The implications?

[BronsCon]

And. I. Am. SPARTA!

Re:The implications?

[The_Wilschon]

No, you're BronsCon.

Re:The implications?

[pipatron]

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

[ShieldW0lf]

I think this is the wrong direction. I don't want it to be made harder to find out what is going on, I want to be let in on what is going on, and I want all of you to be let in on what's going on. The big problem with the way things are now isn't that privacy is gone, it's that only a select few have access to a clear picture while we're all muddling around ignorant in the dark.

False security through obscurity. That's what our desire for privacy has brought us.

Re:The implications?

[locofungus]

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.

This is true. However, if someone with that level of access is that determined then they'll have other means including spy beams on windows, breaking in and installing keyloggers etc.

The most plausible threat is a large scale wiretapping with the data all stored. Only later will someone decide that a particular connection is "interesting" and go back and (try to) read that traffic.

If the government is that desperate to eavesdrop on me then I don't really care. It's going to cost them a lot of money and they're going to have to keep everything secret otherwise I'm going to realize that there has been eavesdropping.

If the government (or ISP) wants to trawl through everybody's data then I want it to be hard for them. In particular, when they lose a few tapes of the traffic though my ISP I'd like my stuff to stay private. It's the same with TLS on SMTP. I deliver direct to MX (where it's allowed) and negotiate TLS wherever possible. Almost everybody uses self signed (or at least "unknown" CA signed certs.) I lose nothing at all by allowing that and I'd certainly gain nothing by rejecting TLS whenever I couldn't recognise the CA and falling back to normal SMTP.

Tim.

Re:The implications?

[MimsyBoro]

I agree with your point, but it seems to me that the overhead of handing out the fake certificates and decrypting the data will make it a lot harder to datamine/traffic-shape.

Re:The implications?

[Tony Hoyle]

So it's actually useless.. for a MITM attack all you have to do is stop the client requesting it, or even knowing that the server is capable of it, and everything drops back to plain text.

Hell, if it gets up the nose of ISPs they'll probably do exactly that with their proxies.

Re:The implications?

[Tony Hoyle]

Also the technique in TFA has *exactly* the same issues.

If you want encryption without any endpoint authentication self signed certificates are the way forward - they're supported by every browser and it's a small change for them to work transparently/remove the lock icon if that's deemed necessary. At the moment only firefox has the major issue with them.. and I'm sure that'll be fixed soon.

Re:The implications?

[ultranova]

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.

Wrong. Just like Middleman A intercepted your attempt to contact Site X, Middleman B will intercept Middleman A's attempt, C will intercept Middleman B's attempt, and so on.

Security would be broken either way, but encrypted, not authenticated traffic still is preferable to neither encrypted, nor authenticated traffic.

Encrypted, not authenticated traffic is almost exactly identical to plaintext traffic. The only thing it makes more difficult is stateless packet sniffing - that is, you have to intercept the whole connection from the start. Since we can assume that any potential attacker is watching either you or your target website, you gain absolutely no security whatsoever from encrypted but not authenticated traffic.

Encryption without authentication is the Information Technology equivalent of armour made of grey-painted cardboard.

Re:The implications?

[I cant believe its n]

But if you are refering to the NSA as being the M.I.T.M., they most likely already have access to U.S. issued keys. If they managed to get hardware installations set up at carrier locations, why would they not be able to ask CA:s for private keys?

Someone mentioned the DMCA earlier. Wouldn't the DMCA make decryption illegal for ISPs? I'm not from the U.S. so perhaps a native could explain if an ISP would be able to legally engage in M.I.T.M. activities? They couldn't very well base trafic shaping on an illegal step.

Re:The implications?

[aztracker1]

How about using something other than a "lock" for sights with self-signed certs. This way people aren't as "secure" in using them, but people who want them on their servers can still use them, without the three clicks, and your first born option in today's browsers. I think a simple "yield" icon in the corner, where the lock normally is, with a click for more information option would work out better in terms of usability, and security. That, or get a couple of the free CAs out there in the browser by default.

Re:The implications?

[jalefkowit]

So the odds of it being a Google project are only 80% then. Reassuring!

Re:The implications?

[neumayr]

Wrong. Just like Middleman A intercepted your attempt to contact Site X, Middleman B will intercept Middleman A's attempt, C will intercept Middleman B's attempt, and so on.

Yes, every MITM attack creates the opportunity for another one. But security is based on maximizing the effort needed to circumvent it. Every MITM attack decreases the total distance the packets have to travel, decreasing the probability for further attacks.

Encrypted, not authenticated traffic is almost exactly identical to plaintext traffic. The only thing it makes more difficult is stateless packet sniffing - that is, you have to intercept the whole connection from the start. Since we can assume that any potential attacker is watching either you or your target website, you gain absolutely no security whatsoever from encrypted but not authenticated traffic.

Except it raises the bar. You aren't vulnerable to the wardriving neighbor's kid anymore. Thus, security is increased.
You're not going to be secure from people targeting you or the website you want to go to, yes. Like I said, security is broken. But still increased.

Encryption without authentication is the Information Technology equivalent of armour made of grey-painted cardboard.

This analogy is only valid when the attacker has to watch the creation of the armor, has to know it's just cardboard in order to take advantage of it.

Re:The implications?

[hobbit]

That might be the case if it were at labs.google.com, but this is code.google.com...

Re:The implications?

[hobbit]

Someone mentioned the DMCA earlier. Wouldn't the DMCA make decryption illegal for ISPs?

That was me, and that's what I am hoping, but then again, IANAAL either.

That said, I think my ISP (Virgin Media UK) starves my connection when I run BitTorrent not by inspection of the contents, but by the traffic profile (i.e. many small uploads to many different IPs).

Re:The implications?

[chunk08]

From what I understand the DMCA makes decryption of copyrighted content illegal, but not decryption per se. However, there have been cases of this being applied to mean anything which could be applied to the decryption of copyrighted content.

So as is far too common in legal systems, something which isn't and shouldn't be technically illegal is in fact illegal in practice.

Re:The implications?

[petermgreen]

Encryption with self signed certs does several things that make life harder for an evesdropper.

1: The attacker has a much higher chance of getting caught. There is no way for the middleman to know for sure if the users are checking the certificates or not.
2: The attacker will require much greater rescourses since they must intercept, decrypt and reencrypt and retransmit the traffic rather than simply sniffing it.

Sure if the attacker has high rescourses and is after you personally it probablly won't help much.

Re:The implications?

[DikSeaCup]

My first reaction is to say "Yes, great idea!" However, I then get concerned about the "Lowest Common Denominator", where people just look at the https and not the lock icon. They can be kinda small and go unnoticed.

Really, I think a warning dialog is needed. The original click-through was good enough, I thought. Now, as everyone says, it's like having to sacrifice your firstborn to get to a self-signed site.

One wonders if the cert authorities have told the browser companies "Make it harder for self-signed certs to be used or we won't allow your browser to use our service."

Re:The implications?

[Sloppy]

The video (BTW, video sucks for these kinds of things, compared to a simple web page) kind of glosses over it quickly, but it looks like they're bitching that TLS has a performance cost.

Which is irrelevant on the browser end, but I guess for Google's servers that cost is multiplied by a large number. Even so, computers are awfully fast and still getting faster. What a shame to do things wrong, all to save a few pennies in 2008 -- pennies that are shaved every year thanks to Moore's law. Lame.

Re:The implications?

[Sloppy]

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.

No, you're more protected, because your opponent just took a risk of detection. You can't actively MitM on a mass scale and get away with it forever. The active snooper does not know whether or not you have validated this self-signed cert out-of-band. If they guess wrong just once, they are detected and exposed.

Now, this is where humans fail. Because you still think you are "somewhat safe"

Why would the user think they're safer? Don't present, say a padlock icon, unless real authentication has happened (i.e. you know you're MitM-proof).

This bullshit all goes back to the regrettable decision by browser makers that use of encryption is "secure" and must be presented to the user as such. Reverse that stupid decision and these problems go away.

Re:The implications?

[Sloppy]

Encryption without authentication is the Information Technology equivalent of armour made of grey-painted cardboard.

By the time someone has found out that your armor is made of cardboard, they have already attacked. Until they swing their sword (and see your reaction), they don't know if it's cardboard or steel.

Now suppose you have validated a self-signed cert out of band. The attacker has no way of knowing whether or not you have done this. Oops, it turns out your apparently-cardboard armor is actually made out of steel. And it's too late for the attacker to suddenly cringe and scream, "Eek! I didn't mean to do that!" as you chase them down and put their head on a pike.

Re:The implications?

[Anonymous Coward]

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.

Tell that to the NSA and AT&T.

Besides, they use HTTP because it's what most people use most regularly, and it's a quick win.

Re:The implications?

[Sloppy]

Making attackers switch from risk-free passive snooping to active MitM is not security theater. You are raising your opponent's costs and risks, and virtually eliminating any chance that they can pull off massive untargeted attacks.

Sure, I favor authenticated connections. Who doesn't? But in situations where you can't do that, it's better to encrypt (with MitM vulnerability) than to send plaintext.

Re:The implications?

[Dolda2000]

Then again, CA-signed certificates also suck. I've already written about it here, so I won't reformulate the problem in this post, but I'll quote the most relevant part:

---

The problem, then, is that this implies that you need to trust Verisign and Thawte to properly validate all the certificate requests that they get—people in an extremely large, bureaucratically weighed-down enterprise that process thousands of certificates daily using automated processes. What are the chances that they wouldn't let one single mistake slip through, and issue a certificate to a cracker for a site that he does not own? The problem does not end there, however: The certificates pre-installed on new PCs are not limited to Verisign and Thawte. They commonly ship with the certificates of around 50 different certificates organizations. Even if you feel secure in trusting Verisign and Thawte (which you should not, but more on that later), what are the chances that all of these can be trusted to consist entirely of incorruptible people and flawless processes? And, even if they did, what are the chances that all of them are completely secure and cannot themselves be cracked to produce faux certificates? For this reason alone, I, for one, would consider the entire process flawed and untrustworthy, and I would implore you to do the same. Therefore, Haven and Hearth uses its own, self-signed SSL certificate, bypassing the certificate authorities. To further clarify our stance, the following three points of policy are noteworthy:

• I do not want to convince you to distrust people. This is a problem of statistics; it would be almost weird if, somewhere in any of the many organizations whose certificates are installed in browsers worldwide, there did not exist anyone who was untrustworthy or just one computer system which is crackable, and the system is designed in such a way that just one is enough to break it.
• Sure enough, there have not been many major security breaches through this route (though it is not unheard of, either), so you might think that I am merely being alarmist, but I would still argue that the flaws in the system is enough reason to boycott it.
• Last, but not least: As I mentioned above, the certificate authorities more often than not charge quite obscene amounts for their services, which emanates an attitude that "The web is for corporations, not for individuals"; a statement that we resent.

But hold on, there is more to this. You may have read the preceding paragraph and still thought it all right to trust all these diverse organizations. However, you really should not: it is well documented that Verisign actively produces faux certificates for various purposes, especially for law enforcement agencies, so that they can perform MITM attacks. You can see Verisign's own home page if you doubt it. What Verisign's faux certificates mean in practice, is that their holder can impersonate any web site, to listen to the traffic between them and their visitors, modify their content arbitrarily and catch any and all sensitive information. And by that, I really mean any web site, not only those with certificates signed by Verisign in the first place. See, when the browser performs its certificate authenticity check, it checks the web site's certificate against any of its installed certificate authorities, and it does not even warn you if the web site's certificate has changed since the last time you visited it, as long as it is signed by just one of the certificate authorities it knows of. Of course, it is not only Verisign which is bestowed with this power – any of the certificate authorities can do th

Re:The implications?

[Anonymous Coward]

If it isn't fixed soon, I bet third-party patches will be along shortly to fix it for them.

Re:The implications?

[Anonymous Coward]

Go read up on web crawling, search engine spiders. Now go read about packet sniffing and eavesdropping. Post when you understand the difference.

Re:The implications?

[w0mprat]

This is exactly the trap with Tor.

Re:The implications?

[GWBasic]

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.

Which is the point! SSL is a pain to enable when using SOAP on a LAN, because the man-in-the-middle attack isn't as much of a risk as Ethereal being used to sniff a password.

Re:The implications?

[BronsCon]

Only SPARTA can call me out on that.

Until then...

I am SPARTA!

Re:The implications?

[MSZ]

Well then, let's make ourselves a CA and use it to sign certificate for "*". Then import it to FF, IE and whatever else browser you like. "*" will match any site (so why not add it as a default to Apache?) and CA will be recognized since it's on the list.

No authentication, but encryption would work. (Tested with FF and IE)

NAT helps with more than just lack of IP addresses and while it's not the ideal solution, the alternative is worse. v6 sucks.

Re:The implications?

[damium]

CAs don't have, nor have they ever had, the private keys (well, most CAs anyway). The private keys are generated on the client side (the client being the webserver in many cases) and the public keys are signed by the CA.

Now, if the FBI/NSA/Whatever wanted access to the encrypted traffic they could do a man-in-the-middle by getting the CA to issue a signed cert saying that they were the webserver in question but it would have a different set of keys (not that the client would notify the user of this).

Re:The implications?

[The_Wilschon]

Very well.

I am Spartacus!

Problem isn't computation...

[Anonymous Coward]

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

[BoChen456]

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

[syzler]

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

[Bill, Shooter of Bul]

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.

Re:Problem isn't computation...

[Timothy Brownawell]

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.

Re:Problem isn't computation...

[this great guy]

You have 2 solutions:

• Run your websites on different ports, you have 65535 of them per IP. Make http://site1/ redirect to https://site1:1111/, http://site2/ redirect to https://site2:2222/, 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 ? 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...

[mzs]

Those are some expensive ten lines of perl code then.

Re:Problem isn't computation...

[mzs]

Or you could have the forms and what not use https://example.com/foo/action and https://example.com/bar/action 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 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/ and the other is at https://example.com/bar/.

Re:Problem isn't computation...

[Anthony_Cargile]

I was gonna suggest using iframes to make it seamless and less "whats that strange URL", but then we're right back at square one, and even if it somehow would work, Internet Exploiter would just complain about "some items insecure". At this stage in the process, the user clicks through several dialog boxes, each one +=ing 1 more amount of dislike for the website. Or you could just use TCP obfuscation (my GOD, I think I see how Google thought of it in the first place...).

Re:Problem isn't computation...

[Cramer]

The problem isn't computation ... The big barrier to ssl for small sites is cost...

Bulls***! How many RSA keys can your computer generate per second? I've worked with SSL for some time. Even with modern day, beafy GHz CPUs, the process is absurdly slow. Every new ssl connection requires both sides to generate a "master secret" -- that process is computationally expensive; subsequent connections can resume the previous session if both ends remember it. While that CPU core is doing the math, it's not doing anything else... like figuring out what you've asked for.

So, the problem is entirely cost... a recognized certificate isn't free, and ssl accelerator cards are just as expensive. SSL quickly becomes extremely computationally expensive, making "small" very small indeed.

Re:Problem isn't computation...

[Cramer]

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.

Re:Problem isn't computation...

[BitZtream]

I would say if your barrier to SSL is lack of IPs you should probably find a provider who isn't running out of their moms basement and has a few they can give you.

Re:Problem isn't computation...

[Cramer]

When you're paying $5/month for "cheap web hosting", yes, yes it is. Unless your business is doing things that actually needs the security, it's an unnecessary expense. (and you might be horrified to know what many sites do with the data you sent them securely via https. My personal fav was a certain newsreader software company emailing purchases from the server to their billing department. Plain. Text. I know because I was postmaster. And they were bouncing.)

Re:Problem isn't computation...

[pv2b]

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

[lysergic.acid]

that's more than a lot of small business sites' annual web hosting costs. and a lot of college students who are trying to start up their own online business don't have a lot of money to throw around on stuff like $200/month dedicated hosting or $400/year TSL certs. not everyone has VC funding, and some people just don't have a lot of money to waste when they first start their business.

besides, i don't think it costs Verisign more than $10 (one time fee) to verify a site's credentials. so the $400 price tag is just abusing their monopoly. really, this kind of thing, like domain name registration & TLD assignment, should be handled by a not-for-profit organization.

if the U.S. government cares about security, they should set up free (or reasonably priced) public CA. it would be more useful than the Cyber Command discussed in the other /. story.

Re:Problem isn't computation...

[coolsnowmen]

But what about all the people whose firewalls block port 80 outgoing?! What are they to do?

Seriously, selectively blocking outgoing ports is the most useless form of TCP/IP security, if the user has control over the server [s]he wants to connect to. If they do, then they will just connect over the ports you allow out.

The only useful egress port to block would be port 80, because the vast majority of the web operates on those ports. Then again, there are proxy servers etc...

Re:Problem isn't computation...

[enoz]

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

[Anonymous Coward]

doesn't work for IE on WinXP.

Unfortunately, that means it doesn't work. :-/

Re:Problem isn't computation...

[Bill, Shooter of Bul]

If you are starting any business you need more than $400. If its a business that you expect to make money, $400 should be nothing. If the price of the cert is preventing stupid businesses that had no chance of every making money from being created, that might not be a bad thing.

Re:Problem isn't computation...

[lysergic.acid]

first off, no you don't. secondly, not having $400 to waste is not the same as not having $400.

besides, the amount of money you have to start your business has no correlation to whether or not your business plan is sound. that's a complete non-sequitor.

perhaps you heard of this thing called the "dot com bubble?" plenty of stupid businesses have no problem raising tons of starting capital. and conversely, a lot of successful businesses started with very humble beginnings, particularly companies whose founders were really young when they first went into business.

Re:Problem isn't computation...

[NitroWolf]

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.

Your understand is incorrect, but it's understandable that you'd have that impression.

SSL encryption itself does not require a unique IP address ... What you're misunderstanding is the browser messages that pop-up when you have a self signed cert or a cert mismatch. You can SSL encrypt all 16 of your sites on the same IP, but 15 of them will have a mismatched certification. THIS IS OK if your goal is encryption only. The problem is, people view the security warning for a mismatched or self signed cert as something unconditionally bad. Yes, it can be bad if a site has been hijacked. Your bank should have a valid key, signed by a trusted authority that has verified that business entity.

Joe Bob's Ebay store does not need a certificate that's signed by TurboSSL - since there's little to no verification done for the party anyone can go out and buy a cheap cert. A signed cert proves exactly nothing - so you might as well be using a self signed one. The only thing a cheap cert does is keep the browser from popping up the warning - it does nothing to enhance security beyond what a self signed cert will do.

So - that was a round about explanation of why you don't need a unique IP to use SSL. The short explanation is, you only need a unique IP if you don't want a browser warning to pop-up. Otherwise, you can use SSL for just about everything.

Browser handling of SSL warnings are really what has prevented widespread adoption.

Re:Problem isn't computation...

[TRS-80]

RFC 2817 is pretty badly broken - basically you can MITM and drop the Upgrade: header, and various other problems. The real solution for random sites that just want to protect passwords is RFC 5054 SRP-TLS, however it's not well supported at the moment, and Mozilla don't seem to be interested in pushing it, preferring to make excuses about why they're sticking with 10-year old technology.

Re:Problem isn't computation...

[spydir31]

Strange, I've been using HTTPS over alternate ports in IE for a while now. always worked in IE 5 and up.

Re:Problem isn't computation...

[this great guy]

Thanks for the links. It looks like the best solution for virtual HTTPS hosting in the long term is maybe this TLS extension mentioned by someone else: http://en.wikipedia.org/wiki/Server_Name_Indication

Re:Problem isn't computation...

[Fruit]

You have 2 solutions:

• 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).

We use this a lot at our company and it works well in both Firefox and MSIE. The only drawback is that you need a single certificate for all sites.

Re:Problem isn't computation...

[Cramer]

you missed the point: an http url that redirects to https on a nonstandard port fails (or used to)

Re:Problem isn't computation...

[yabos]

Godaddy's domain only cert just requires you to have an email address at that domain to verify who you are. It only costs about $20-$30 last time I got one and this is fine because I don't need anything more like a verified address in the cert etc.

Re:Problem isn't computation...

[JediTrainer]

Option 1 won't work. Lots of organizations (mine included) have non-standard ports firewalled. Most users won't have the smarts to run an external proxy, leading them to believe that the site just doesn't work.

I second the subjectAltName solution. It works very well for what you are hoping to accomplish.

Re:Problem isn't computation...

[petermgreen]

Be that as it may lots of enterprises want to do thier best to block everything except web browsing. Since there is no easy way to identify https traffic by packet content that means they pretty much have to allow unfettered connections to the standard https port (443). On the other hand they may not want to allow access to arbitary TCP ports because that would allow use of IRC bittorrent etc.

You may or may not think this is a good idea (personally I can see why they do it even though I know that it allows easy workarrounds if you control a box on the outside) but it is reality and if you ignore it you will block lots of people from accessing your site.

Re:Problem isn't computation...

[TRS-80]

Yeah, SNI is where it's at.

So, wait...

[Bragador]

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

[Anonymous Coward]

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

Re:So, wait...

[Anonymous Coward]

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

[cjfs]

>

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.

Re:So, wait...

[mrbene]

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 on his free time.

Re:So, wait...

[Bragador]

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

Re:So, wait...

[Anonymous Coward]

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

Re:So, wait...

[Anonymous Coward]

exactly...So should we devote a day at /. with headlines like "sourceforge's innovative p2p client or bittorent client"

Re:So, wait...

[Nutria]

restricts there

Where?

annal probing into you.

What are they going to do? Excise a bit of my thigh bone and count my tree rings?

Or do you mean:

restricts their anal probing into you.

Re:So, wait...

[Legion_SB]

misleading title

It's a little-known fact that "Posted by kdawson" is Slashdot-ease for "better read TFA because TFS is FUBAR".

Re:So, wait...

[hobbit]

Realizing that large corporations consist of many separate interests might help alleviate your confusion :-)

Adopting British grammar in which Google are linguistically recognised as such might be a useful first step :)

Firefox isn't helping

[vux984]

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

[0123456]

"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

[rsmith-mac]

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

[jlarocco]

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

[Kjella]

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

[Free the Cowards]

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

[Zadaz]

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

[at.drinian]

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

[RiotingPacifist]

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

Re:Firefox isn't helping

[defaria]

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

[mikenap]

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

[MrMista_B]

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

[0123456]

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

[mikenap]

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

[QuasiEvil]

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

[jrockway]

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

[profplump]

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

[gregorio]

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

[mysidia]

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

Re:Firefox isn't helping

[Sancho]

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

[Free the Cowards]

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

[Wildclaw]

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

[Timothy Brownawell]

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

[bluefoxlucid]

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

[Anonymous Coward]

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

[snaz555]

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

[cecil_turtle]

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

[Timothy Brownawell]

What, the protocol spec says "thou shalt have such-and-such a user interface"? It completely forbids the application determining "the protocol can provide X and Y, but in this case we only have X and not Y", and telling the user what we actually have rather than what the protocol we're using could theoretically provide? If so... that's really very stupid, and maybe people should ignore it.

Re:Firefox isn't helping

[nsheppar]

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?

Because not every site on the Internet is particularly at risk of being targeted. There is such a thing as acceptable risk. Also, because performing an all-out attack of impersonating a host is a signficant bit more difficult than simply eavesdropping on traffic.

Re:Firefox isn't helping

[DiegoBravo]

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

Your point is valid for the Internet. But maybe inside an intranet or extranet? some policies force to "encrypt everything" in the network, but using true CA-certs is a lot of extra burden (and cost) so it make sense to auto-sign. The rationale maybe that it is more difficult for corporate users to install -for example- a fake DNS/Web Server than just running some Windows sniffer.

Re:Firefox isn't helping

[Poltras]

That distinction is exactly what is being proposed here. Encrypted TCP would solve the eavesdropping problem (mostly, not totally) and the X509 certs would solve the authenticity problem. Best of both worlds.

Re:Firefox isn't helping

[bluefoxlucid]

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.

The "Default Gateway" IP address allows your computer to send an ARP for your gateway (i.e. 192.168.0.1) and get its MAC address; to send a packet to be routed, it determines that the destination IP isn't on this subnet and so sets the MAC address for the frame to the MAC of the default gateway (hardware drops any frames destined for anything beyond its own MAC or broadcast), which looks at the IP address and uses that to route, setting the MAC to the next hop. There is no encapsulation of packets to route them or anything; they're sent bare, with the MAC address always pointing at the next hop (which, on the subnet of the destination address, is that computer's MAC; otherwise, it's the next router's MAC).

Send an ARP response across the network (broadcast MAC or target the next hop router towards the SSL server), and anything listening to it will update its ARP tables automatically. Update the IP of the router with your MAC and you'll receive all packets outbound through that router. If you do nothing, you just broke the network; packets won't route out that way anymore.

Now that you have packets, route them; simply change the MAC to the router's MAC and resend them, and they'll route properly.

When you see something interesting like an SSL session with a self-signed cert, stop it. Do the handshake, construct and answer back with a self-signed cert on the fly (doesn't have to be cryptographically secure, so don't use awesome entropy; use random()), and proxy.

Ettercap does just that. If you're at a coffee shop with a wireless access point, you can do nasty things to everyone. You can even rewrite bank certs to be self-signed, so the users go "Huh what's this? I dunno. *yes*" and you have their bank stuff now. MySpace doesn't even use a cert; but if you coerce it into using https://secure.myspace.com/ instead of http, it uses a self-signed cert and you win anyway.

The process isn't as simple as eavesdropping, technically. It's not, however, as difficult as hacking into The Pentagon or something; you won't find, every day or every new network you touch, that the problem is completely different and you need to expend hours of human intervention thinking and searching and investigating. It's like cracking DVD encryption: you do it once, then distribute the program and it works on everything.

Re:Firefox isn't helping

[Timothy Brownawell]

Because it tells you that there is an error and the site is broken, rather than clearly warning you that the site isn't really secure? Because it has a priority inversion, where it treats self-signed as less secure than completely unsigned?

Re:Firefox isn't helping

[Anonymous Coward]

It may be one key, but how many thousand times more system resources are you using? Now the attacker needs 10000 computers to do the job of formally one sniffer.

Re:Firefox isn't helping

[bluefoxlucid]

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.

It's very difficult to provide an explanation. Think about car locks, right? Car locks aren't secure; I can brick your window and steal your shit. People don't, so the (straw man) argument is that there's increased security, and self-signed SSL certs will increase security.

But if you consider the differences here you should notice that someone can see or hear me smash your car window and run off with your shit; and if not, you'll notice the broken window and the missing shit when you get back. On any network I can eavesdrop on, I can just as invisibly MitM you without being noticed if the certificate is self-signed anyway.

You won't notice broken glass, you won't notice your account numbers and passwords missing. Oh sure, you'll notice when I start buying things with your credit card or transfer the money out of your bank accounts; but that's the same security mechanism as plain text. So this is essentially different from bricking a car window, yet essentially the same as vanilla eavesdropping on plain text.

Re:Firefox isn't helping

[Bill, Shooter of Bul]

Yeah, I don't either. No one has ever explained to me why a legitimate site that needs ssl couldn't afford a legit signed cert. They always raise the issue of cost. To me its like a potential restaurant owner complaining that the board of health won't let him opperate a restaurant because it costs too much to comply with the regulations. I don't ever want to eat at any restaurant where the health code was not followed. This may cause unsanitary restaurateurs to go underground and server even less sanitary food off of garbage heaps, but I don't give a crap. I won't eat there. No one should. The solution is not to lower the standards. I don't ever want to shop at a site that doesn't have a legit cert.

Re:Firefox isn't helping

[djshaffer]

No, the real hierarchy is:
1. SSL with cert signed by a trusted certificate authority.
2. SSL with cert signed by the current public certificate authorities.
3. SSL with self-signed cert
3. (again) Plain HTTP

They key point is that both number 3's are equally easy for script kiddies to compromise.

Re:Firefox isn't helping

[jrockway]

If I want to spy on everyone on the Internet, you're right. But if I just want to steal email from someone at the coffee shop, that's trivial.

But the point is, it doesn't matter what sniffer I have if you are verifying the authenticity of your SSL certificates.

Re:Firefox isn't helping

[vux984]

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

[vux984]

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

[BitZtream]

Dear clueless,

Self signed certs can not be authenticated. You use a self signed cert, I can intercept your traffic, use my own self signed cert that would appear to be exactly like yours, read your traffic, and pass it along to your server as if nothing happened and neither side will know the difference.

I really wish you people would stop whining about how Firefox alerts on self signed certs. EVERY browser does, FOR A REASON. Just because you don't understand cryptography and have no idea why a self signed cert is practically useless doesn't mean the people working on the security related parts of the code base don't either. An unvalidated self signed certificate will just require a different approach to evesdropping, it does almost nothing to prevent it. The whole point of the CA is to verify that it IS a valid certificate so you know no one in the middle is capable of intercepting the stream, take away the verification, you defeat the entire purpose. Anyone in the middle can easily do the key negotiation portion of the connection and be able to decrypt the traffic both ways.

If you have something that needs encrypting at all, self signed certs aren't going to be useful outside of testing. You might as well not encrypt it in the first place and quit wasting CPU power.

If you need to do SSL internal to an organization you can create a CA cert, sign the rest with that, and then make sure the CA certificate is distributed within your enviroment, which is what many organizations with a clue do when they need stuff internally and don't want to pay for it or have other reasons to avoid an external CA. As an example, MS ActiveDirectory distributes its own CA cert to all machines joined to the domain automatically. I use this for the organization I work for for anything that isn't public, works great, everyone is happy and life goes on just fine.

Signed,
Someone with an actual clue about cryptography.

Re:Firefox isn't helping

[vux984]

Firefox is right about this. Most people rely on the little lock icon to "make sure this is really the bank's website".

So don't show a lock, or make a big show out of self signed certs. Treat them the same as plain http. There is no reason to treat them as 'worse' than plain http. That's just absurd.

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.

Not if the browser treats self-signed certs as identical in value to plain http.

Or put another way, why not show errors for EVERY plain http site as well, telling users that the server hasn't been authenticated, there is no gaurantee it actually belongs to who you might think it belongs, and on top of all that, 3rd parties can trivially eavesdrop too.

By your logic why exactly shouldn't we have THOSE errors?

Re:Firefox isn't helping

[BitZtream]

The reason self signed certs are treated like they are is because its assumed that if you aren't attempting to encrypt the connection at all then there isn't a need for it, rather than pretending to be secure when you aren't.

Plain HTTP gives no false sense of security, it isn't.

Self Signed/unverifiable certs give a false sense of security that can easily be compremised, hence why they are red flagged.

If you want to use self signed certs you should distribute them in a secure method to the browser in which case you will get the result you want, no warning and a verified certificate.

You like the way SSH works for most people, which from a security perspective, its just as dangerous as using a self signed cert and should not be trusted in the least, just because its easier for you to deal with, doesn't mean its the right thing to do. Large organizations and groups who are extremely security concious DO NOT trust the finger print provided by the server on first connection, they distribute the finger print using other secure channels FIRST, then check it for verification on connection.

Re:Firefox isn't helping

[Timothy Brownawell]

No one has ever explained to me why a legitimate site that needs ssl couldn't afford a legit signed cert.

• What about sites that don't need ssl, but would like to at least make the three-letter-agencies spend a bit more on their eavesdropping hardware (and risk getting caught if someone checks the fingerprints)?
• Who says that CA-signed === legit? A CA is for mapping cert -> meatspace identity, but they only actually do that for the "extended validation" certs. What if I only care that I'm talking to the same site I was talking to last week, and don't care who's behind it in meatspace?

Re:Firefox isn't helping

[MobyDisk]

You point out that SSL with a self-signed cert tells you that either you are safe, or the attacker is smart. Telling me "If you are being scammed, the attacker are doing a good job" is little consolation!

Re:Firefox isn't helping

[KermodeBear]

I dunno. I just click "Okay" until the windows go away and I can see the website.

Re:Firefox isn't helping

[BitZtream]

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,

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.

Authentication requires encryption.

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.

I'd argue that 90% of the insidious activity comes from just sniffing cleartext off the wire

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

[Cramer]

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

Having done this very thing... No. It. Doesn't. *cough*paros*cough* We've done this a few times to setup application monitoring systems for banks (etc.) who could not give us the required information or access to it without being on site -- we like to set it up before shipping otherwise we'd need to put someone in the box with it to do setup on site, or spend all day on the phone trying to walk them through configuration when they don't know how their own web applications work (and they wrote them.) The public ssl certificate isn't known to any human -- it's safely tucked away inside a FIPS certified crypto processor board. (the complicated "tls over floppy" transfer process is the only thing we have to walk them through on the phone, and they usually know how to do that already.)

Re:Firefox isn't helping

[vux984]

Self signed certs can not be authenticated. You use a self signed cert, I can intercept your traffic, use my own self signed cert that would appear to be exactly like yours, read your traffic, and pass it along to your server as if nothing happened and neither side will know the difference.

plain http can not be authenticated. You use plain http, I can intercept your traffic, pass it along to your server as if nothing happened and neither side will know the difference.

Where is the dire warning each time I connect via plain http?

All the browser SHOULD do in the event of a self signed cert is ABSOLUTELY NOTHING SPECIAL. Its no worse than plain http. It may not be any better, but its absolutely not worse. I agree that we should not confuse users or mislead them into thinking their connection is MORE secure, but there is no reason to make them think their connection is LESS secure.

To use a car analagy, the car door can be open, ajar, or securely locked. Ajar isn't secure, and we shouldn't mislead people into thinking it is, but for some reason we are treating ajar as dangerously worse than open.

That's idiotic.

Signed,
Someone else with a clue about cryptography

Re:Firefox isn't helping

[BitZtream]

SSL certs don't provide encryption. They provide authentication, that authentication provides a secure method of negotiating the keys that can then be used for encryption without sending those keys across the wire where they can be sniffed and used by the evesdropper.

Whats difficult about it is that you, and most of the other people who bitch about the way web browsers handle non-verified certs, don't actually understand the process or how SSL really works.

Until everyone actually understands it, we'll continue to go over it again and again and nothing will change because fortunately, the people writing the software DO understand how it works.

Re:Firefox isn't helping

[Anonymous Coward]

Sorry, you are incorrect, the correct DEFAULT security hierarchy is the second. Users should be alerted to the fact that accepting a self-signed cert is potentially extremely and could result in a false sense of security.

Any users who are sophisticated enough to know when a self-signed cert is, in fact, perfectly secure is also sophisticated enough to ignore a warning from their browser.

Re:Firefox isn't helping

[hksdot]

One possible solution is to put notary schemes on top of the certificate check to help deal with the conflict between MitM vulnerability and the convenience of self-signed certificates.

Re:Firefox isn't helping

[Timothy Brownawell]

Self signed certs can not be authenticated.

Do you know what the "fingerprint" of a cert is?

I really wish you people would stop whining about how Firefox alerts on self signed certs. EVERY browser does, FOR A REASON.

And that reason is STUPID, because plain http is always at least as insecure.

An unvalidated self signed certificate will just require a different approach to evesdropping

[emphasis added] There are ways that self-signed certificates can be validated, do you know what "out-of-band" communication is? This can even be automated, if you're willing to reduce your security to only a little bit better than the current CA system.

Re:Firefox isn't helping

[Anonymous Coward]

Use of the padlock icon should be restricted to authenticated sites. The self-signed certs could use a question mark connected to a bicycle lock.

Really though without authentication you got nothing. It's harder to proxy a SSL connection but you know that could be canned in an app that any ass could run on an unencrypted wifi connection if the door were opened by the browser.

The secure/nonsecure binary situation is really the best. Grey areas are confusing to an already stupid and uninformed public. The people that know to ignore a self-signed warning are exactly the people that don't need to be coddled by their browser with new icons.

Re:Firefox isn't helping

[Anonymous Coward]

Your reasoning is so flawed that forming an argument against it is actually boring. Please realize that while everyone has a right to their opinion, yours is dumb.

Re:Firefox isn't helping

[BitZtream]

Do you know that I have to GET that fingerprint somehow? Do you know that because you only get the warning when you are dealing with a certificate that the browser isn't already aware of that you have no way to validate that the fingerprint is actually the one its supposed to be?

Plain HTTP is less secure, it also doesn't give a false sense of security, with plain HTTP you know instantly that anyone can access the data, you can then make the decision to send it or not. If you think the data is secure then you are likely to transmit information that you consider confidential, and since it really ISN'T secure with unverified certificates it IS more dangerous than when you are FULLY aware that plain HTTP can be sniffed.

Did you miss the part where I specifically stated an out of band method to distribute the self signed cert or were you just being STUPID?

Please quickly add yourself to the list of clueless people whining about Firefox because you don't actually understand secure communications.

Re:Firefox isn't helping

[TheLink]

"anyone arguing in favor of not putting up big warnings when a browser sees a self-signed cert is a dumb-ass"

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

I prefer the browser to give me big warnings if the cert (whether self-signed or CA signed) is a NEW one, or it has CHANGED since the last time (and the browser should keep copies of the previous certs for comparison).

Once it does that it might even be safer than the normal process with CA signed certs. Do you trust all the CAs whose certs are installed in your browser? If you don't but you still keep their certs installed just so you don't get "prompts", then you're not very different from the people who ignore those warnings and prompts.

With my suggestion you could go "hey, my bank is using a new cert, and hey it's a different CA from some obscure country, hmmm maybe I better not log in".

That won't happen with most popular browsers - you get no warning that the cert has changed as long as it's a valid CA.

Re:Firefox isn't helping

[Free the Cowards]

That's just plain wrong. If I'm anywhere that your traffic passes through, then HTTP will expose your passwords and any other information you're transferring to me by simply running a sniffer. SSL with a self-signed cert requires me to actively run interference on your connection, with something like DNS or ARP spoofing, and running active software on my computer, and all of this is detectible to some degree. It's all doable, certainly, and not extremely hard, but it gives you a great deal over a raw unprotected connection like HTTP.

Re:Firefox isn't helping

[Timothy Brownawell]

Plain HTTP is less secure, it also doesn't give a false sense of security

Users don't interact with HTTP, they interact with the browser. And the browser can choose when to provide the appearance of security, based on more than just what protocol it happens to be using to talk to the server.

If you think the data is secure then you are likely to transmit information that you consider confidential

And since plain HTTP doesn't throw all those errors about being insecure, it must be perfectly safe to transmit whatever you like...

Please quickly add yourself to the list of clueless people whining about Firefox because you don't actually understand secure communications.

I'm not clueless, I just don't see why everyone is so set on assuming that all CAs included in every browser are infallible, and on insisting that the only way to be "legitimate" is to join in on the (flawed, IMO) assumption.

Re:Firefox isn't helping

[Free the Cowards]

Self-signed certs only give a false sense of security because they're stupidly implemented. Remove the lock icon! Stop treating it like a secure connection! If you do these things, then people will not assume the connection is secure. There's absolutely no reason to treat it as worse than HTTP.

SSH is not just as dangerous as using a self-signed cert. A self-signed cert can be spoofed at any time with no difficulties, unless the user is being extremely paranoid and actually recording what the browser says every single time. With SSH, if you spoof me then you must always spoof me, and always have spoofed me, in a manner which is 100% consistent or else you will be discovered. In practice, that means that it's impossible to spoof SSH without being discovered unless you can intercept traffic at a point very close to the server.

Re:Firefox isn't helping

[Free the Cowards]

Nonsensical. SSL with a self-signed cert is more secure than HTTP. It's less secure than "real" SSL, sure. But the only reason there's any kind of "false sense of security" is because the browsers give it to the user, and instead of taking that away, they try to fight against themselves by adding warnings. It's bizarre.

Re:Firefox isn't helping

[rabbit994]

With today certs, you can get a cert for 20 dollars and no verification except your email address is listed on Whois. Your website will show up with green padlock in Firefox and IE. This doesn't really help anything as you can't expect the user to analyze the cert and make sure name matches up with what they expect.

Re:Firefox isn't helping

[BitZtream]

And these providers should not be included in the list of trusted root CAs that are distributed with browsers. You want to argue for removing them from the built in list, I'll be right next to you, but that won't make self signed certs any more useful.

Making it so self signed certs don't show up as a bad thing doesn't help that problem, it just adds another one.

Re:Firefox isn't helping

[Burz]

SSL certs don't provide encryption. They provide authentication...

Try again.

The only usage of certs that matters within a web browser is HTTPS, which employs both authentication and encryption at the same time.

Your splitting of hairs is so contrived that one has to forget everything about the use cases involved for your explanation to make any sense.

Re:Firefox isn't helping

[TwilightXaos]

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.

I reject your false dichotomy, and suplant my own. Just because the browser doesn't display large warnings everytime a site uses a self-signed cert, doesn't mean that SSL with self signed certs and certs signed by a CA have to be displayed the same. I agree with you that SSL certs signed by a CA are more secure, and provide authentication where self signed certs do not.

However, clearly self signed certs are better, even if only marginally so, than unencrypted HTTP. Current browsers make it seem like self signed certs are less secure than plain HTTP trafic.

Re:Firefox isn't helping

[Spy Hunter]

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!

Re:Firefox isn't helping

[jlarocco]

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.

After thinking it over a little more, wouldn't eavesdropping in that situation be a pretty straightforward man-in-the-middle attack?

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

Well, you could always submit a patch... ;-)

Re:Firefox isn't helping

[Bill, Shooter of Bul]

1) If a site doesn't need a ssl, but wants the three letter protection they need to determine just how much that protection is worth. If its not worth the price, they probably had nothing to fear from any three letter organization.

2) I only meant legit as a synonym for a cert signed by an approved ca. Its legit cause its not signed by JoeSchmoe.org and the browsers recognize it as such. That's the only meaning I apply towards it.

Re:Firefox isn't helping

[felipekk]

I think it's pretty safe to say that the Firefox team is very innovative.

Just now people are starting to complain loudly about self signed certs and the security warning. Give them some time.

The last problem that was echoed all over the internet was memory leak, which was fixed on this major release.

Maybe create a bug report suggesting a different behavior for this to make things faster?

Re:Firefox isn't helping

[LnxAddct]

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.

Re:Firefox isn't helping

[nmx]

It works great for ssh and solved the whole key distribution problem.

It works great after the initial conection, but you're vulnerable to a man in the middle attack on the initial connection attempt. It doesn't solve the key distribution problem at all. Or did you not read the warning message that ssh prints out on initial connections? You're accepting a risk, just as there is a risk in accepting a self-signed certificate. The difference is that your average SSH user can understand the risk, whereas unless you go the extreme route Firefox has gone, the average Web user will still see that the lock icon is there and just ignore any warnings. The CA system DOES solve the problem, but it relies on trusted authorities. There is no chance of a man in the middle attack with a trusted signed certificate.

Re:Firefox isn't helping

[The Moof]

Trying to get average computer users to understand "Encrypted" vs. "Authenticated" would be the biggest problem.

Re:Firefox isn't helping

[Anonymous Coward]

That's just plain wrong. If I'm anywhere that your traffic passes through, then HTTP will expose your passwords and any other information you're transferring to me by simply running a sniffer. SSL with a self-signed cert requires me to actively run interference on your connection, with something like DNS or ARP spoofing, and running active software on my computer, and all of this is detectible to some degree. It's all doable, certainly, and not extremely hard, but it gives you a great deal over a raw unprotected connection like HTTP.

Er. No it doesn't. You're confused.

To sniff your HTTP traffic, I will need to man in the middle your connection, using something like ... you guessed it .. ARP spoofing to redirect your traffic to me from the local LAN -- or controlling one of the routers en-route. Once I'm doing that, adding MITM SSL is a walk in the park.

It's pseudo-security. Your connection is no more secure than it was when you were using plain HTTP, since I, as the attacker, have to take only one more very simple step using readily available tools to MITM your self-signed HTTPS connection.

Self signed certificates DO NOT make a difference to someone who can sniff your HTTP traffic. Being able to sniff your traffic means that they are, BY DEFINITION, the man in the middle

Re:Firefox isn't helping

[xous]

It doesn't really make sense to use a separate url scheme because your really using the same protocol.

Secondly the same people that don't care to be educated in man-in-the-middle attacks probably wont notice the difference between 'httpi', 'https' and probably even 'http'. It's the lock picture they look for if they look for anything.

Re:Firefox isn't helping

[FrangoAssado]

That's not the point; it doesn't matther what the protocol says.

What matters is the user's expectation. Unfortunately, today people expect "https" to be secure enough to send their bank password or credit card number. It's very hard to explain the nuances of encryption and authentication to someone who just wants to shop online.

My unrealistic solution that will never be implemented: create a new protocol that uses SSL/TLS exactly as https, but silently accepts non-verified certificates. Maybe call it httpe ("e" means encrypted). Then teach people than "https" is for using banks and online shopping, "httpe" is for other stuff that is nice to have encrypted but nothing too bad will happen if someone happens to see.

Re:Firefox isn't helping

[the_womble]

The problem is that there is no money to be made in selling certs that way.

SSH is unprofitable and therefore communist encryption that destroys the profits of companies that could otherwise sell SSL type certs for that as well.

You could just tunnel http over ssh, but there is no browser support for that so it is something each user has to set up for themselves, rather than a method that can be generally used.

Re:Firefox isn't helping

[FrangoAssado]

I know you're exaggerating, but didn't browsers do that for forms submitted via POST? I don't know if they still do (it's been a while since I don't install a browser in a new computer), but I remember that one of the first things to do then using a new browser was to mark the "don't bug me about this anymore checkbox" and click OK.

By the way, I don't completely dislike the idea of allowing self-signed certificates but not showing the green "secure" icon. But I think it might be better to make that a "new" protocol that behaves exactly as https except that it accepts (perhaps silently) self-signed certificates (maybe call it "httpe", for "encrypted"). That way, there's less possibility of confusion between sites that are really secure and sites that just use encryption but are theoretically vulnerable to MITM attacks.

Re:Firefox isn't helping

[Anonymous Coward]

Begging the question a touch, there?

Re:Firefox isn't helping

[mrbobjoe]

A self signed cert could then allow encryption and say perhaps show a yellow padlock

A yellow padlock would look like gold and thus sort of imply goodness. Not that this invalidates your point, it's just difficult to show some icon that represents a more nuanced kind of "secure".

Re:Firefox isn't helping

[Anonymous Coward]

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

And that's exactly the way it's supposed to be. MITM attacks become trivial once self-signed ssl is considered "safe". Probably you and me won't fall for it. But any luser that clicks "yes" on a "are you sure you want to run the attachment britney nude.mp3.exe" WILL fall for this.

Re:Firefox isn't helping

[mvdwege]

A CA is for mapping cert -> meatspace identity

No. Just plain no.

A certificate is for asserting that the URL you just requested is being served by the server whose hostname is mentioned in the URL. That's all SSL can prove. No matter what the CA's marketing department tells you, it cannot verify the ownership of the server with 100% accuracy.

Mart

Re:Firefox isn't helping

[mrbobjoe]

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.

Didn't Netscape once use blue for their padlock? Ah yes, here, and also shows the gold IE one (in response to someone else's yellow suggestion).

There are some nuances that aren't going to come across from a color. Maybe if they're contrasting with another color, particularly if the user is expecting to see either no lock or a green one, but still not something certain to be noticed.

Or are you suggesting a picture of some other object? Something intended to get attention rather than a simple palette shift (say, a red exclamation point) would be more likely to get that click you're suggesting. But I think the full screen warning message is sort of the natural conclusion of this line of reasoning, in that it requires attention. Under what circumstances would it make sense to ignore the flashing warning sign rather than clicking it and getting the details? If none, why should it be allowed by the interface?

Re:Firefox isn't helping

[Spy Hunter]

There are lots of situations where it makes sense to use a different url scheme for the same protocol. However, I think the method of certificate verification could legitimately be called part of the protocol.

There are certainly plenty of people who don't know what https is, but I believe there's a huge middle ground of people who don't have a cryptographer's understanding of man-in-the-middle attacks, but do know that "https" is supposed to be secure. It wasn't that long ago that secure sites were instructing people to look for "https" in their URLs; some still do. Further argument on this point is rather pointless without some actual data.

"httpi" wasn't a serious proposal anyway; I think we can all agree that the article proposed the best solution. If all traffic was encrypted by default, self-signed SSL (SSSSL?) would become irrelevant.

Re:Firefox isn't helping

[Eivind]

If self-signed where treated like ssh does it; ask the first time, then complain loudly later if things change, it WOULD be useful. True enough, you could have a man-in-the-middle from the get-go. But assuming you don't, you're safe against it later. Just knowing that "This is definitely the same site I've been using for a year-and-a-half" provides better than zero security.

Re:Firefox isn't helping

[Anonymous Coward]

https with self-signed certificates is not "lesser security" than plain http.

This is the impression that Firefox gives. "Oh noes, this site is using self-signed certificates. Better close the window immediately, and find a different site that uses plain http".

Re:Firefox isn't helping

[vux984]

After thinking it over a little more, wouldn't eavesdropping in that situation be a pretty straightforward man-in-the-middle attack?

Yes and no. Yes if it was the first time you'd connected to that server. But if the browser cached self-signed certs, it would be reasonable to flag that it had changed with a message. Self-signed certs also have the potential to be verfied "out of band".

That aside, if I were to agree that self-signed certs offered no security whatsoever, then the browser should just ignore them and treat the the connection plain http (ie do nothing special), nothing more, nothing less.

Re:Firefox isn't helping

[Anonymous Coward]

The problem is you can't not display the "https"

Oh really? Because that's exactly what Chrome does.

After the stupid warning, unfortunately.

Re:Firefox isn't helping

[vux984]

Or are you suggesting a picture of some other object?

Yes, but not a red exclamation point.. something neutral like a brown circle or an orange square. Something that they can click on it if they want, to get the information about the connection but that's it.

Given that unless you've verified the cert, its as unsecure as http, it should look nothing like, nor even hint at being 'secure'.

But I think the full screen warning message is sort of the natural conclusion of this line of reasoning, in that it requires attention.

It requires much special attention as a plain http connection does - that is to say: none. Users shouldn't have to do anything special, in fact, if they aren't paying attention they'll treat it like a regular insecure http connection, which for all intents and purposes, it is.

If they go to the trouble of manually verifying it, and then adding it, THEN and only then does it have any MEANING, and then on subsequent visits, they'll get the green and the lock, and the horrible warnings if the cert has changed and doesn't match.

But the point is, the default behavior of the browser should be to treat it as nothing special.

Re:Firefox isn't helping

[vux984]

I know you're exaggerating, but didn't browsers do that for forms submitted via POST?

I'm not really exaggerating; check out the error message FF3 throws up for a self-signed cert:

http://centrim.mis.brighton.ac.uk/more/h/tutorial/sscert-freeman-ff3/resolveuid/e90db9262cef2ca16bd4d9d16a939fa3

It really does say "Get me out of here!" and very nearly the other nonsense I suggested...

Re:Firefox isn't helping

[Anonymous Coward]

Yes, if you can listen in, you can usually also technically do MITM. It's not by definition and certainly not automatic, but the capability usually exists. Encryption is still better than no encryption: Passive attacks are almost undetectable. An active attack can be found, and while passive eavesdropping is legal in some cases, active attacks never are. Another benefit of unauthenticated encryption is that simply gathering raw communication for post-factum analysis is impossible. You have to intercept, decrypt and reencrypt the communication while it's happening. That is a huge problem for mass-surveillance operations, especially if they try to stay covert.

Re:Firefox isn't helping

[xous]

I think the best solution would be just implementing TLS everywhere were security is wanted/needed. The latency and cpu time would be the major issues with this solution but cpu time is becoming cheaper.

This would allow to optionally use http for cheap and insensitive content or use a full https if you are paranoid. I think pressure needs to be put on service providers to protect users from themselves.

i.e. I can't see why service providers are still allowing smtp, imap, pop, and ftp when TLS or ssl is available.

To implement TLS for a large amount of sites you need to pick IPv6 or SNI.

Browsers that support SNI:
Opera 8.0+
Firefox 2+
Internet Explorer 7+

According to wc3 22.3% are still using IE 6.

So as much as I hate to say it the sooner Vista becomes the norm for Windows users the sooner this becomes a viable option.

IPv6: due to the slow rate of adoption I don't think this would be viable for years.

The problem with the article's proposal is that it requires that the encryption functionality to be built into EVERY protocol that wishes to take advantage of it. IMHO this seems to be going against exactly that the OSI model was intended to prevent.

If you want to add a Diffie-Hellman key exchange to only http why not just extend the protocol instead of the headers non-sense?

Re:Firefox isn't helping

[Anonymous Coward]

Err - what? In both cases you have:

Malicious person is between you and the server and sees all your traffic.

But in the second case a self-signed SSL certificat is used, which they can switch for their own self-signed cert because they are between you and the server.

> I'd argue that 90% of the insidious activity

Yep well these numbers are made up.

> mitigating a significant portion of that risk.

(Based on made up numbers, again)
It moves the risk somewhere else, it doesn't do anything apart from buy a little time.

Re:Firefox isn't helping

[Anonymous Coward]

the whole point of encrypted comms is to stop man in the middle- the mim can make a self signed cert

Re:Firefox isn't helping

[Ed Avis]

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?

Or realize that if you do have a black and white division into 'secure' and 'woo woo insecure danger Will Robinson', then unencrypted http traffic falls into the latter category and deserves a scary warning at least as much as a self-signed certificate.

Re:Firefox isn't helping

[cortana]

Browsers should treat self signed certs as 'unsigned with the added bonus that communications can't be eavesdropped'

Except that that would not be correct!

Re:Firefox isn't helping

[Anonymous Coward]

SSL with self-signed cert is most likely to occur when there is a man-in-the-middle attack, as only cowboys use self-signed certs.

When I visit a site that says https at the top, I want to know /real/ strongly that I haven't got a connection signed by a trusted authority. If I don't trust the authority I don't trust the connection. That is the definition of trusted authority - so if you trust a website's signing authority then just add that authority to your list.

Re:Firefox isn't helping

[vux984]

Except that that would not be correct!

You are right. I realized this shortly after posting. Allow me to amend to:

Browsers should treat self signed certs as 'unsigned' no different than plain http, but giving the user some unobtrusive option to inspect and add the certificate so that future connections to the same site will be 'trusted'.

But the default behaviour of the browser is to do nothing special. No big green lock icons, no giant error messages.

Re:Firefox isn't helping

[darkfire5252]

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.

So use the same approach as SSH... Silently accept a self-signed cert for a website that I have had no prior contact with (but do not indicate that the site is 'secure'), but if I have contacted a site with a CA signed cert previously and it now has a self-signed cert then sound all the alarm bells. Hell, Google, Microsoft, or the CAs can relatively easily create a directory that allows me to look up the last known cert used for a domain and the CA signing status.

Re:Firefox isn't helping

[Fruit]

It IS worse: it gives a you false sense of security.

Re:Firefox isn't helping

[darkfire5252]

Oooh, this is fun. Let me play:

Authentication requires encryption.

Bzzzt, wrong, thanks for playing. With SSL, the authentication phase happens before the encryption phase [...] 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.

Bzzzt, wrong! Authentication does in fact require encryption. The authentication uses asymmetric (public/private key) encryption, because my authentication key is somewhat useless if, once I authenticate myself to you, you are able to repeat the key I gave you and falsely authenticate as me to any other party.

You are right that the authentication occurs before the symmetric encryption keys are exchanged. However, this stage of the communications clearly needs to be encrypted as well; if someone eavesdrops on the key exchange then the whole scheme is somewhat useless. The reason that authentication occurs using asymmetric encryption and then negotiates keys for symmetric encryption is that asymmetric encryption is much more computationally intensive than symmetric encryption.

Thanks for playing, though.

Re:Firefox isn't helping

[Fruit]

It's impossible for a browser (or a user, for that matter) to see the difference between a site with a CA issued certificate and that same site with a hijacked connection (and a dummy self-signed cert inserted by the eavesdropper). It HAS to give a fuss about that certificate or the entire CA-certification system is useless.

The real question is: why is it so goddamn hard/expensive to get a CA to sign your certificate?

Re:Firefox isn't helping

[Jamie Lokier]

Not just the lock icon. Users have long been trained to look for "https:" as a sign of security too.

Personally my eyes lock onto "https:" and don't notice the lock icon, probably because in older browsers the lock icon was present for uncrypted connections too - just unlocked which is visually nearly the same. Things have improved in Firefox, but the training persists and is quite automatic now. 10 years of web use will do that, I cannot be the only one.

If "https" is presented without the lock icon for unauthenticated sites, that creates a false sense of security too.

Re:Firefox isn't helping

[Anonymous Coward]

> Really though without authentication you got nothing. It's harder to proxy a SSL connection but you know that could be canned in an app that any ass could run on an unencrypted wifi connection if the door were opened by the browser.

No, a simple laptop SSL proxy can not realistically be used to simply grep for all passwords sent over a 100 MBit connection, while without SSL it could probably even manage 1 GBit.
Yes, that makes a difference, namely that if your government/ISP/secret service can monitor almost all traffic or not - among other things.
If almost all sites used it, it would also mean that e.g. China's firewall would mostly break down, the Internet become even slower, or almost all pages unavailable.

Re:Firefox isn't helping

[jurgen]

There are various ways in which even self-signed certs can protect your communications effectively even against MIM (man in the middle) attacks....

0) You simply might not be worried about MIM attacks. For example, on certain communications your threat model might be only about an attacker who is passively sniffing your wireless traffic. This is a real threat model... with airsnort against unencrypted HTTP over a wireless link my kid sister can steal my webmail password, and I'm really more worried about that than about major govenments spying because the latter presumably have many other means of reading my email if they really want to.

1) Assuming that there was no MIM on your initial communication, you now have a cert... a MIM on subsequent communications will raise an alarm. Often (obviously not always) this is a reasonable assumption, as to capture initial communications the attacker may have to maintain his MIM infrastructure for a long time, and cost is proportional to time (and increases much faster than linearly, because MIM infrastructures tend to be hard to hide for longer time periods.)

2) You exchange self-signed certs out of band. If you know me and I personally hand you a disk with my self-signed cert, there is no risk of MIM.

3) You can verify self-signed certs out of band, i.e. I send you self-signed cert, you call me on phone and ask "is cert with fingerprint blah-blah really from you?". Less secure than above, but now the MIM has to install himself both in the primary comm channel and in the verification comm channel to succeed.

So as you can see, to claim that self-signed certs provide no advantage over communications in the clear "at all" is an overstatement. As with all security mechanisms it depends entirely on your threat model and on how you use them. :j

Re:Firefox isn't helping

[Kjella]

Or realize that if you do have a black and white division into 'secure' and 'woo woo insecure danger Will Robinson', then unencrypted http traffic falls into the latter category and deserves a scary warning at least as much as a self-signed certificate.

To what end? I think actually IE does this (if not so scary) when you submit any information anywhere, be it posting as AC on slashdot, searching on google or whatever. Obviously 99.99% of the people check "don't show me this warning again" if it isn't checked by default as I can't remember, it would be the ultimate case of crying wolf.

Re:Firefox isn't helping

[Kjella]

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,

Bzzzt, wrong, thanks for playing. I written an app that makes the process as easy as starting a sniffer,

So if my browser has stored the previous key, your app would work how? Were you planning to catch everyone on initial connection? Good luck doing that on a major scale, someone on some server would compare fingerprints and a major stink would be raised. Your app, while I'm sure it's easy, would only work in the narrow window where you want to wiretap a specific site before it even goes live and at the same time uses self-signed keys. Good luck with that.

Authentication requires encryption.

Bzzzt, wrong, thanks for playing. With SSL, the authentication phase happens before the encryption phase

To be authenticated, each packet must be indirectly authenticated and the only useful way of doing that is encryption. You can do the handshake, but if the following packets were plaintext you could simply replace the contents... So there's no authentication without encryption, but thanks for playing.

I'd argue that 90% of the insidious activity comes from just sniffing cleartext off the wire

Why? 9 times out of 10 there are easier ways to get to someones data than bothering with sniffing.

We're talking about sniffing vs MITM, but thanks for changing the subject. Yes, AES can be broken with a baseball bat but that's a different discussion.

Re:Firefox isn't helping

[RiotingPacifist]

Encrypted TCP would solve the eavesdropping problem (mostly, not totally)

only it doesnt, a MITM attack can easily defeat the entire scheme with a single forged dns request.

unencypted data is unenecrypted so can be tampered with
this can be set to unencrypted or compromised by MITM
self-signed ssh is vulnerable to MITM attacks as unencrypted
ssh is secure but underused

Re:Firefox isn't helping

[haapi]

Good on ya. That's well put. Your ordering is right. And, being notified in the change of status is a self-signed cert is simple, but vital.

Mozilla -- please add that half page of code.

Re:Firefox isn't helping

[djshaffer]

Most machines are on switches these days. This limits the number of places that a simple sniff will see your packets to:

a) people near your insecure wireless network.
b) people on the same machine
c) people at your ISP
d) people working at the backbone networks
e) people working at the server's ISP
f) people on the same machine as the server

If you are worried about a, b, and f then you have issues that SSL will not solve. For c through e ARP tricks are no real hurdle. These guys probably do that just as easily as they do sniffing. Anyone else has to do ARP tricks just to give their sniffer a look at your packets.

Re:Firefox isn't helping

[garett_spencley]

I like this idea. Instead of changing the SSL protocol we implement an encrypted but non-authenticated http protocol. The trick to adoption would be the browsers. Servers can be updated easily and web sites that support httpe can change their links. Sites that support httpe can even redirect their http traffic to httpe, same way banks do when you visit their login page through http rather than https.

The only problem is browsers. Browsers need to support it and sites can't switch over entirely until their users all upgrade their browsers. But it seems like once a protocol is accepted and finalized that it would be one of the easier things to change. I would personally use httpe for everything and https for banking and shopping, and see no reason why browsers couldn't use it by default.

Re:Firefox isn't helping

[Sancho]

I agree that that functionality would make things a bit better. Of course, certs need to be revoked. They expire. There are all sorts of reasons why a site might use one cert today and another one tomorrow, and then you'll have people crawling out of the woodwork crying about how unfair Firefox treats changed certs.

The real truth is that trust on an anonymous network is hard. We use certificate authorities for precisely this reason. We trust them to be uninterested third parties, because we assume that their reputations are important enough to keep from breaking that trust. You'll never get the same level of trust from a self-signed certificate without some form of out-of-band validation.

Re:Firefox isn't helping

[Anonymous Coward]

Security heirarchy should start with:
SSL with hand-delivered keys.

Re:Firefox isn't helping

[Anonymous Coward]

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.

This certificate for chase.com, wellsfargo.com, and wamu.com was self signed, do you want to accept as it means your conversations can't be evesdropped!

Re:Firefox isn't helping

[petermgreen]

or provide a warning when using the lesser security so that users are aware of whats going on???
The problem is that browsers provide a scary warning when using weak security but they provide NO WARNING AT ALL when using NO SECURITY WHATSOEVER.

Which means websites that don't want to scare away thier users are faced with an all or nothing choice on security.

Re:Firefox isn't helping

[arkhan_jg]

Yes, but pages sent in the clear are definitely capable of being sniffed by anyone in arpspoof or mitm range. self-signed pages are only possibly being sniffed by someone actively trying to break in from the start.

Nobody is saying that self-signed certificates should be elevated to the same level as properly signed certs, you do need a clear UI difference between in-the-clear, self-signed and recognised- CA-signed.

Self-signed cert sites should not be substantially more difficult and annoying to visit than unsigned sites. There's a lot of mailing list servers out there self-signed, and a lot of web-based management pages for hardware that are self-signed. Expecting all of them to go and spend money on a needless CA cert - especially since it really has to be one IP per site - just to shut firefox up is arrogant and misguided.

I switched from netscape to mozilla, then to phoenix. I've been a firefox advocate for a very long time, and even I'm starting to look at alternative browsers as a result of this issue. I use 4 or 5 machines regularly (plus a whole other bunch occasionally), and having to add manually every single fecking site every fecking time is becoming a real pain in the ass.

Re:Firefox isn't helping

[DJCater]

A false sense of security is worse than no sense of security.

Re:Firefox isn't helping

[Anonymous Coward]

I think the parent is much closer to the reality of the situation than you are.

In practice, it's extremely easy to pull of MITM attacks nowadays, it's not really any harder than sniffing... at least when your target is joe public.

Sitting on a switched network or wifi, you have a variety of methods available to you, all easily supported by up to date modern tools, to automatically mitm everyone on all common protocols and harvest passwords and other valuable information.

It's by no means something done only by sophisticated attackers.

Encryption without authentication DOES protect you from casual sniffing.. certainly - so perhaps if someone like the NSA was middling an entire country, we'd catch them. What it does not do, however, is protect you from using your computer, well, anywhere public, anywhere where someone might be able to get a common, off the shelf, pushbutton middling tool between you and your destination.

I"m all for casual encryption of everything, it's a GOOD idea... it would take all the sniffing, traffic shaping, deep inspection..a ll these things that are done passively and would force other parties to have to actively interfere in order to MITM the connection (which they could easily do) in order to mess with our communications.. and that's more clearly illegal.. it's something we could detect, and defend against when it happens.

What casual non-authenticated encryption does NOT do is protect your data from being seen. You will get middled, and unless you are paying attention, you will not notice.

Re:Firefox isn't helping

[TheBig1]

My associates may be the exception here, but I don't think that any non-technical people that I know look at the HTTPS; instead, they look at the lock, the URL bar color, etc. (Yes, this is antecdotal, non-scientific data, YMMV).

Cheers

Re:Firefox isn't helping

[Free the Cowards]

Absolutely false. The browser could use any number of ways to indicate that a CA-issued cert is much more secure than a self-signed cert. There's no need to put up a big warning for the self-signed cert, any more than there's a need to put up a big warning for a plain HTTP connection.

Re:Firefox isn't helping

[Free the Cowards]

At least someone on here is sane! It astounds me how many replies I'm getting saying that it's somehow proper to make more noise about self-signed SSL certs than plain HTTP. People are nuts!

Re:Firefox isn't helping

[Free the Cowards]

Most machines are on switches these days.

Heh! Most machines are on wifi these days.

Re:Firefox isn't helping

[Sloppy]

Whereas self-signed certs let the eavesdropper send you a certificate which makes you think your connection is secure

If you think your connection is secure, then your browser's UI is broken. Why not just fix that bug?

Re:Firefox isn't helping

[Sloppy]

Users have long been trained to look for "https:" as a sign of security too.

Perhaps there's a way to retrain the users: Never, ever show "https" in the URL bar, regardless of whether you have an authenticated connection or not.

Re:Firefox isn't helping

[Ifni]

Sniffing and MITM are magnitudes apart in difficulty. Yes, if you have COMPLETE control of the network, they may be trivially different, but if you are sniffing a wireless connection you don't control, it requires significantly more effort (and risk) to do ARP poisoning so that you become the gateway across which all traffic flows as opposed to simply listening in.

For a wired network, it is easier to SPAN a port and listen passively than it is to find a way to make a hardware based router do a MITM, or (again) do ARP spoofing so that your computer that has all that MITM software acts as a gateway.

So, yes, if you already have the traffic flowing through a device which can load some MITM tool, they are just a button press apart. But the reality is that whether the network is private or public, it is much more difficult to ARP poison or own a vital piece of network equipment (and install the proper software on said equipment) than it is to just flood a MAC table or create a SPAN port on a switch and listen in passively.

Now, if you are the NSA or some other TLA agency, it might be different, but to my knowledge all of the monitoring equipment that they place at ISP is out of band - which is to say that it listens passively and cannot manipulate the traffic. So again, though using the sniffing and MITM software may be almost identically difficult, setting up the circumstanced to enable the use of one over the other is not.

Or am I missing the MITM software that comes stock in a Cisco firewall or router?

As far as the use of self-signed certs, I think that it is far better than plain-text, but yes, there needs to be more awareness on the part of the users as well as the site operators. The infamous "lock icon" should be locked and green for trusted certs, unlocked for unencrypted traffic, and locked but red or yellow (and possibly flashing for a brief interval after each page load to draw attention to it), and users educated on what exactly the risk is when the lock is yellow or red.

Optionally, users can be trained on the difference between encrypted and authenticated and there can be a lock icon for encrypted, and a separate icon for authentication. Either way, it comes down to user education.

Another option is to have the self signed website provide an image that displays the hash for a self-signed cert, so that the user can check it against the cert being offered. If that site is being targeted, the MITM can create his own image, sure, but if it is simply an automated tool like most of the ones today, it would not know what the image name was, or if there was one, for it to replace in transit. Again, I use an image so that an automated tool can't just look for a character sequence that matches the fingerprint for the site's cert and replace it with its own.

Re:Firefox isn't helping

[Anonymous Coward]

Bzzzt, wrong, thanks for playing.

Douchebagometer: [----------/--]

Re:Firefox isn't helping

[Ifni]

On any network I can eavesdrop on, I can just as invisibly MitM you without being noticed if the certificate is self-signed anyway.

Not to nitpick, but this is patently false. To MitM, you HAVE to be in-band, which is far from invisible in the vast majority of cases. To eavesdrop, you can be out of band, which is significantly more difficult to detect, and easier to achieve (practically, theoretically, and technically).

Other than that, I mostly agree with the rest of your post.

Re:Firefox isn't helping

[bill_mcgonigle]

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?

So true. Most people aren't as dumb as security software writers would like to so narcissistically think. The locked-unlocked paradigm is a least-common-denominator approach and really hampers the 80% of the people who could understand better security.

My contention is that the lower 20% aren't going to do any worse with a better scheme. I knew the whole paradigm was crap in 1994 when Netscape adopted the inverse lock semantics as Kerberos clients had (there when your TGT was 'unlocked' you were encrypting).

Re:Firefox isn't helping

[gregorio]

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?

If know-all idiot geeks like you hadn't "educated" users about how "https means safe, so look for it", this wouldn't be necessary. It's all part of the past now, the users are already "damaged", so you're going to have to deal with it.

Re:Firefox isn't helping

[muckracer]

> 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

So where's that extension for our favorite browser anyway?

Re:Firefox isn't helping

[muckracer]

> So use the same approach as SSH... Silently accept a self-signed cert
> for a website that I have had no prior contact with (but do not indicate
> that the site is 'secure')

I wonder why it all has to be a black or white approach. How about adding another shade of color (pun intended) into the mix, namely:

HTTPS (CA verified): green
HTTPS (self-signed): checker-board-style white-green
HTTPS (self-signed but *user-verified fingerprint*..what a concept!!): green
HTTP: white

Add SSH-style authentication of tracking certificate changes into it with mild warning on first connection etc. and you got a pretty decent scheme serving just about all needs.

Re:Firefox isn't helping

[bluefoxlucid]

Not to nitpick, but this is patently false. To MitM, you HAVE to be in-band, which is far from invisible in the vast majority of cases.

You seem to be under the impression that getting in-band is hard, or typically even searched for by detection systems. To detect me getting in-band, you have to be snooping for ARP replies, and matching them against known values. Failing that, you need to recognize when something other than a router has the MAC address for a packet destined for a host not on the local segment.

Now tell me what step along the way this sort of detection exists on. I'm probably not maliciously hijacking your ISP (in fact, if I did hack your ISP, I'd be in a position where MitM and eavesdropping are basically the same). I might be on the same segment of a corporate/home network (worm!), or connected to your wireless access point (coffee shop!). In any of these cases, it's woefully unlikely something would have the software capability or the proper configuration to detect my in-band hijinks.

ICMP redirects are largely ignored, but also provide a way to do this.

Re:Firefox isn't helping

[kestasjk]

But what if the man in the middle is there before the first connection begins, and also intercepts my wireless communication on all the wireless hotspots I use? A false sense of security is even worse than no security at all.

-- A deeply concerned VeriSign employee

Re:Firefox isn't helping

[Spy Hunter]

Well, it displays the https, but in bright red with a huge strikeout line over it. Which is an interesting solution. It still doesn't address the problem that the security properties of the https url scheme will change if browsers start accepting self-signed certs. If you change the meaning of the "https" scheme, there will be no way to specify that a link should be protected against man-in-the-middle attacks. That's why you need to either introduce a new URL scheme that doesn't promise man-in-the-middle attack protection, or implement opportunistic encryption for http links like suggested in the article.

Re:Firefox isn't helping

[idontgno]

per definitionem, MITM != eavesdropping. You keep changing the terms. Stop it.

OTCP will interfere with passive eavesdropping. OTCP does not foil MITM-based attacks, but those are a significant step up in technical complexity and attacker risk.

Any discussion of MITM is offtopic. Deal with it.

Re:Firefox isn't helping

[mrbobjoe]

Given that unless you've verified the cert, its as unsecure as http, it should look nothing like, nor even hint at being 'secure'.

Ok, that sounds like a good idea now that I understand your reasoning. Do we even need an icon, then, or could someone interested just notice the https in the url? I guess the icon makes for an easier click target than the alternative (messing with menus).

You could go a bit more intrusive and have something like the password popup (or the bar that FF3 uses now), "Do you want to remember this certificate?", but you seem to be advocating no action unless the user requests it. And considering that almost all users will have no way of verifying a certificate, this seems like a reasonable conclusion.

So maybe just leave it somewhere in the menus and don't even bother with the icon.

Re:Firefox isn't helping

[BitZtream]

Again, SSL certs do not provide the encryption. They provide a means to authenticate and help out the key negotiation process. Certs specify how they are 'allowed' to be used, they specify they CAN be used as part of the encryption process, even that however can simply be ignored. The only reason the big CAs charge different prices for the certs is because software respects these flags by design, there is nothing that prevents someone from making an SSL library ( or more simply modifing an existing one ) to ignore these 'rules'.

Yes, in the browser context SSL certs are used to facilitate encryption, but the arguement about WHY the warnings are bad depends on ignorance of how they REALLY are used in this context. It IS important to understand what they REALLY do to understand WHY the browser warnings exist. Its not a matter of splitting hairs, its a matter of understanding how they are used in the process, that understanding makes the arguement retarded. So I feel its rather important that people understand what role they play in the process to understand why the warnings are there and why you want them.

Re:Firefox isn't helping

[BitZtream]

And since plain HTTP doesn't throw all those errors about being insecure, it must be perfectly safe to transmit whatever you like...

Except you happen to be missing the nice little lock icon and you DO get a warning that you are transmitting information that may be intercepted because it is not being encrypted. Just because the first thing you did was click the checkbox that says don't warn me again, doesn't mean that users don't get alerted. YOU don't get alerted, I do, and my browser is using a default configuration.

Re:Firefox isn't helping

[Daniel_Staal]

Actually, that's what Firefox is doing, effectively.

The problem is twofold:
1. We expect it from ssh, and not from a browser.
2. ssh users are usually people who know computers, browsers are general public.

Re:Firefox isn't helping

[KZigurs]

Any technology where there is an upper tier of security automaticaly implies to user that lower tiers are just as fine. Hence firefox decision that only upper tier goes thru okay.

Re:Firefox isn't helping

[Ifni]

My point of contention is where you claimed that MitM was just as invisible as eavesdropping. I did not argue with your assessment of the technical skill required (though there are many more points in a network where you can compromise a system that allows for eavesdropping - like a managed switch - that you cannot use for MitM, making MitM at least some amount more difficult). However, the fact that some networks will have IDS that looks for ARP poisoning and ICMP redirect attacks means that being noisy makes MitM considerably riskier. And malware, though possible to consider it MitM, is outside the scope of this argument as at that point you may as well just use a keylogger, making just about any network level countermeasure useless.

Re:Firefox isn't helping

[bluefoxlucid]

The networks that have those will be deep inner secured networks. The target for sniffing credit cards from banks is sit at Panera Bread looking at Gmail. Who the hell has a live IDS and supporting security team (of 1 coverage during all open hours) on their home Wifi or a coffee shop hot spot? How would they locate the culprit physically? Why do they care?

We have nukes and armed guards, burglary is very difficult to pull off and you can't run from an atomic explosion. Most if not all burglaries are not going to target Area 51, and who the hell is going to lob a (200 foot area damage) tactical nuke at your ass while you're running through the desert anyway?

Robbing a jewelry store is safer and will make me richer (how the fuck do you get away with selling government classified shit?); robbing houses is safer still, but will make me less rich. In your general security system design, you should consider your attacks and weigh their effectiveness; robbing a house is way better than robbing Area 51, and picking up MySpace/Facebook log-ins (reuse for Paypal) and bank information is pretty fucking easy when that's pretty much all people do at hot spots.

OE is a nice idea

[Plug]

Opportunistic encryption was the original goal of the FreeS/WAN 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

[whoever57]

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.

Re:OE is a nice idea

[Anonymous Coward]

You are technically correct and as we know THAT IS THE BEST KIND OF CORRECT. congrats on your anal retentive 'observation' that did not need to be said.

Re:OE is a nice idea

[Plug]

I couldn't find the exact page I wanted (closest I came was their ending letter), but I believe the authors pretty much gave up because they couldn't get political backing for OE. They solved the technical issue (and built a better mousetrap), but could not convince the world to use it.

Re:OE is a nice idea

[whoever57]

They solved the technical issue (and built a better mousetrap), but could not convince the world to use it.

I don't know about "could not" -- FreeS/WAN was closed down very shortly after OE was released to production -- perhaps only 6 months, maybe a year. I had implemented OE and was disappointed to see the project die.

You need to do WHAT?

[Anonymous Coward]

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?

[mzs]

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?

[Anonymous Coward]

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?

[mzs]

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

[TheSHAD0W]

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

[syzler]

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

[Anonymous Coward]

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

[Free the Cowards]

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

[cjfs]

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

[LingNoi]

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.

Re:surveillance

[Richard W.M. Jones]

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:surveillance

[LingNoi]

What are you talking about? This has nothing to do with Google. The fact that the title mentions Google is a dumb mistake.

Re:surveillance

[Richard W.M. Jones]

The person who wrote Obfuscated TCP works for Google.

Rich.

Re:surveillance

[PitaBred]

Governments are capable of performing MITM attacks, but it is non-trivial computationally. Which means listening to EVERYTHING becomes an impossible problem, which forces them back to the concept of needing suspicion.

Encryption may not be 100% secure, but it forces the attacker to use many orders of magnitude more resources to accomplish any kind of subterfuge, which is a good thing when you're talking about systems that can currently casually listen to almost all communication over the network.

Re:surveillance

[GWBasic]

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.

There is a commercial need for encrypted HTTP that doesn't need SSL's complicated certificate system. For example, when using SOAP on a LAN, encryption is a requirement to deter casual sniffing of passwords. The MITM issue just simply isn't a risk that justifies certificates.

Google's Obfuscated TCP?

[cowbud]

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

Re:Google's Obfuscated TCP?

[Anonymous Coward]

The guy who created it works for Google. It's not obvious, but I think it's enough to call it Google's project.

dom

The problem is IPv4

[Anonymous Coward]

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:The problem is IPv4

[mzs]

I had hosting at provider that did this:

them: http://example.com/
me: http://foo.bar.invalid/

them: https://example.com/
me: https://example.com/bar/foo/

They paid for the example.com cert.

Re:The problem is IPv4

[Sancho]

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

Re:The problem is IPv4

[mzs]

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

Re:The problem is IPv4

[afidel]

Yeah and IPv6 makes this particular scheme unneeded by universally supporting IPSEC.

Re:The problem is IPv4

[Sancho]

Oops, you got me on Safari. Though IE7 on Vista apparently supports SNI. I guess it's not supported on XP due to library support.

Re:The problem is IPv4

[Jamie Lokier]

Ironically I just visited https://sni.velox.ch/, and all I got was Firefox warning me that I might not want to trust this site :-)

Damn Videos

[Anonymous Coward]

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

[agl42]

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

[Zutroi_Zatatakowsky]

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

[Plug]

He's a Google employee..

(Standard 20% time disclaimer etc)

Re:NOT GOOGLE

[Anonymous Coward]

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

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

Re:NOT GOOGLE

[Anonymous Coward]

Although no support of the idea by Google, as a company, is implied.

So why call it "Google's"? Does Google own everything its employees do? Are we back to serfdom?

Less secure than 128bit SSL? Why?

[Culture20]

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?

[cjfs]

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.

Trusts DNS instead of CA signature

[mikenap]

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

[Kjella]

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

[mikenap]

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

[mikenap]

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

[mzs]

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/ 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

[galvanash]

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

Re:Trusts DNS instead of CA signature

[IMightB]

Umm AFAIK all SSL/TLS certs require them to be signed by a CA even "self-signed" certs. The difference between a self signed cert and a cert you get from Verisign is that a self signed cert is signed by a CA that you created yourself. Your CA cert is NOT included in any browser by default. You can make a self-signed cert act just like a Verisign cert by adding the CA cert to your browsers "Trusted CA's" store. The problem is that all your visitors must add your cert to their browsers "Trusted CA" store as well

A unsigned cert is called a Certificate Request, and is unusable by anything until it is "signed" by a CA.

An official CA like Verisign can be thought of as a notary. The reason you pay them to sign your Certificate Request is that they're supposed to verify you are who you say you are.

Re:Trusts DNS instead of CA signature

[shaitand]

'It only keeps out the MOST casual, lazy, and uninterested snooper.'

In other words, almost everyone attempting to snoop.

'Forging a CA signature on a certificate would be a BIG DEAL.'

No kidding, why do all that work when you can get a cert from a lax CA in 15minutes or less anyway?

Re:Trusts DNS instead of CA signature

[Tony Hoyle]

Without endpoint validation you're back to it being no different to self signed certs, which already work and don't require everyone to adopt a new protocol.

The problem is SSL

[Anonymous Coward]

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

computationally cheaper?

[Korbeau]

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.

Re:computationally cheaper?

[afidel]

Exactly, for most sites today encryption would be a rounding error in their CPU budget.

And men-in-the-middle-attacks?!

[Korbeau]

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?!

[LingNoi]

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.

Re:And men-in-the-middle-attacks?!

[Korbeau]

I repeat: I mean except for the paranoids ...
My ISP has never inserted adverts and I've never seen such case (except free ISP where you willingly want adverts or free mail etc.) And if they did I'd resign and start a rebellion.

And I don't send f***ing credit card numbers in plain text. Nor sensitive conversation for that matter. What I type right now they can kiss my ass with it.

So what? Why would I want encrypted connection to cnn.com or cracked.com or slashdot.com or whatever?

I WANT to be traced back ... else I'd be posting via Anonymous Coward.

And if I were to post to Secure-Slashdot through Anonymous Coward ... they'd know Who I Was with or without encryption if they wanted to.

Re:Less secure than 128bit SSL? Why?

[Anonymous Coward]

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?

[mrbene]

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.

They could have done better

[this great guy]

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:

• 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

[this great guy]

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

[agl42]

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

[thc4k]

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

[this great guy]

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.

Re:They could have done better

[LingNoi]

One of the main points of this is that it's faster, however you didn't mention any comparison.

Re:They could have done better

[this great guy]

s/djbdns/djb/

Re:They could have done better

[Ash-Fox]

No special "Obfuscated TCP" module needed on the webserver, just configure it for HTTPS (using a self-signed cert if you want).

HTTPS certificates are specific to one hostname per IP address.

Re:They could have done better

[Tony Hoyle]

Good idea. OTOH you're still relying on DNS not being compromised (anyone capable of an MITM can compromise both DNS and Web at the same time), so whether it really gives you anything over a self signed cert on its own is debatable.

Re:They could have done better

[this great guy]

No, because it would be possible to use the subjectAltName X.509 extension.

Re:They could have done better

[this great guy]

The original author's method, my method, and self-signed certs are all vulnerable to MITM attacks. The advantage over self-signed certs is: no annoying pop-up, and no need to explicitely use the HTTPS URL (which are the original goals of obfuscated TCP).

Re:They could have done better

[MbM]

Interesting; it also has the advantage that with the port number included in the CNAME you could actually run multiple https servers -- something you can't do with port 443 since the cert is sent to the client before the hostname is established.

Imple-say!

[fahrbot-bot]

Ust-jay se-uay ode-cay.

Re:Imple-say!

[Anonymous Coward]

In Pig Latin, words that start with a vowel remain unchanged.

Idiot-ay.

what's wrong with ipsec?

[embsysdev]

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?

Re:what's wrong with ipsec?

[Anonymous Coward]

IPSec prevents its own widespread adoption in two ways:

1) IPSec is very much about authenticating who you are talking to on the other end. If two nodes connect for the first time, with no previous knowledge, they have no way to authenticate the other is who they say they are. This is a failure to IPSec - you'll get no SAs, and most implementations will drop traffic that would've required that SA.

2) The classic key exchange issue:
  a) You can authenticate a session using certs, but now you have the same problems as signed SSL certs, except that every host participating needs to have one and know about all the other nodes' CAs.
  b) You can instead opt to use a pre-shared key, but now you have to pre-share the key. This is fine when you are looking to secure specific traffic to a specific node.

For uses that aren't affected by these downsides, IPSec is a hugely popular technology. VPNs between a branch and central office as well as remote access for roaming users are very popular. Of course in these cases you can very meaningfully authenticate the other end and the key exchange isn't a problem.

Re:what's wrong with ipsec?

[Frogbert]

Ever set up IPSEC? Yeah, that's why.

Re:what's wrong with ipsec?

[spinkham]

It IS the same idea as opportunistic encryption, already supported in FreeS/WAN and OpenSWAN IPSEC .
The FreeS/WAN project died out specifically because the creator was disappointed that no one started using the Opportunistic Encryption portion of the software. See the FreeS/WAN history page for details.
It's great technology, but:
1)not secure until we have secure DNS.
2)somewhat computationally intensive
3)somewhat complex setup

We can fix the first part with DNSSEC. Unfortunately that standard is not getting uptake primarily due to the political issue of who will be in control of the signing key for the root servers.

The 2nd and 3rd issues are what this new project is trying to solve. Unfortunately, by not using already deployed and tested standards like IPSEC, they face an even harder uphill climb then FreeS/WAN did.

I'm of the cypherpunk persuasion, and am doing all I can to push DNSSEC to help enable cool technologies like this, but I realize the rest of the world quite honestly doesn't give a crap. Here's to keeping the dream alive though!

Whose obfuscated TCP, exactly?

[Anonymous Coward]

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

bs

[Anonymous Coward]

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

[FilterMapReduce]

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.

Doesn't help

[Anonymous Coward]

self signed certs aren't appropriate for processing credit cards

VanillaMastercard throws up some warning on Firefox

Tags: Post, Comment, Reply

[zigmeister]

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

NOT Google's, just their code hosting

[agl42]

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

Reinventing ancient history

[PhilK]

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/

Re:Reinventing ancient history

[life atom]

Lorite.

Re:Reinventing ancient history

[Anonymous Coward]

"IANAL, but" also an ass?

Load of nothingness

[ZeroNullVoid]

Wow, just like many keynote presentations.

There was very little useful meat to it.

Weak encryption worse than none.

[BlackSabbath]

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

Re:Weak encryption worse than none.

[willyhill]

as Mary Queen of Scots found out at the cost of her life

Agreed! Poor Mary should have gone all the way and none of that would have happened.

Oh wait, wrong period.

Never forget

[Anonymous Coward]

Google is entering 2 areas it shouldn't. 1, Al Gore invented the internet as we all know. 2, the pirate bay just announced their plan to encrypt the entire internet, and as they've stuck to their other projects I eagerly await the day they follow through with their encryption plan, which as of now is a great idea... and thats about it. But I'm sure we'll see more....

Ignorance and laziness is helping even less

[fm6]

The warning is not ridiculous. An SSL connection doesn't derive its security solely from the fact that it's encrypted. It's equally important that the web site actually belongs to the entity it claims to belong to.

No, I take that back. It's a lot more important. How many identity thieves rely on packet sniffers? And how many rely on phishing? The ratio must be something like a million to 1. And any phisher can create a "secure" web site.

It might be convenient if there were a separate mechanism for sites that need to verify their identify, and sites that just want an encrypted connection so hackers can't sniff passwords. But there isn't. The inconvenience isn't a big one, because setting up a certificate just isn't that hard. The only reason nobody does it it because of the useless mechanism (those little approval boxes all computer users are programmed to ignore) that makes the whole certificate mechanism a joke.

Somebody needed to invent a mechanism to make sure that naive users don't open security holes. Somebody at mozilla.org invented one, and it works. The fact that it's a PITA is proof that it works. Deal with it.

Re:Ignorance and laziness is helping even less

[vux984]

No, I take that back. It's a lot more important. How many identity thieves rely on packet sniffers? And how many rely on phishing? The ratio must be something like a million to 1. And any phisher can create a "secure" web site.

Using a self signed cert doesn't make it 'secure', so all the browser has to do is treat it the same as any of the MILLIONS of regular insecure sites around.

"It might be convenient if there were a separate mechanism for sites that need to verify their identify, and sites that just want an encrypted connection so hackers can't sniff passwords. But there isn't."

Yes, there is.... paid for root authority signed certs provide the former, self signed certs provide the latter. It would be trivial for the browser to treat the two DIFFERENT types of cert appropriately.

The inconvenience isn't a big one, because setting up a certificate just isn't that hard. The only reason nobody does it it because of the useless mechanism (those little approval boxes all computer users are programmed to ignore) that makes the whole certificate mechanism a joke.

The browsers is at fault. 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.

Re:Ignorance and laziness is helping even less

[nmx]

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:Ignorance and laziness is helping even less

[vux984]

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. That's a fair comment actually.

Re:Ignorance and laziness is helping even less

[fm6]

In other words, you want browsers to treat sites with invalid certificate the same as sites with no certificates at all. Contrary to what you seem to think, browsers have never done that, and there's a reason. It stems from why SSL was invented. It was Netscape's attempt to sell online solutions that provided a level of security that institutions like banks could live with. And that meant coming up with a comprehensive solution that prevented not just packet snooping, but also man-in-the-middle attacks.

As often happens in the software biz, the product was designed to meet the needs of a few customers with a lot of money to spent. The needs of the small scale webmaster who just wants to protect a few passwords from packet sniffing were not considered. These webmasters didn't see this as an issue, because using self-signed certificates had no real consequences, since they weren't usually subject to MITM attacks (I emphasize "usually") and their users treated the resulting warning dialogs as part of the constant technical noise (are you sure that you want to delete that file? are you sure you want to install that? you last accessed your online account on ...) that computers users have been trained to ignore.

What was fine for those webmasters was not fine for the people for whom SSL was actually invented. They need users to actually pay attention when somebody is trying to get them to accept a self-signed certificate. And that's what Firefox provided.

Firefox's solution is not really different from the warning mechanisms browsers have had all along. It's just harder to ignore. Yes, it creates a usability problem. But there's a simple solution to that problem: web masters can stop using self-signed certificates. It's not that big a change, and it leaves an important security advance in place.

Equivalent to SSH/TLS with self-signed certs.

[Animats]

This is equivalent, in a security sense, to SSH/TLS with self-signed certs. There's no protection against man-in-the-middle attacks, but there is some protection against passive eavesdroppers.

Unfortunately, man-in-the-middle attacks are most likely in the same situation that allows easy passive eavesdropping - public WiFi access points.

Also, they've chosen completely different cryptographic standards than SSH/TLS uses, with different key handling. Until many qualified people have gone over exactly how that all works, it can't be trusted. There's a long history of botched crypto schemes. Is this, for example, subject to playback attacks? We don't know. Worse, it involves putting more trust in DNS, which is already a problem.

If something like this is desirable, it might be worthwhile to have a version of Apache that generated a random self-signed SSH/TLS cert for every hosted domain, and a version of Firefox which tried to use an SSH connection for every connection and accepted self-signed certs, but displayed a weaker icon than the "lock" icon; perhaps a picture of a knot. That would use existing technology and wouldn't be hard to do.

Re:Equivalent to SSH/TLS with self-signed certs.

[agl42]

> Is this, for example, subject to playback attacks?

Yes, it is (there's no server nonce). It's designed that way because it eliminates latency. This is a low security, low cost scheme after all. It's also vulnerable to truncation attacks and, until I implement authenticators, blind corruption.

vote for kdawson to be fired

[spir0]

kdawson, you are a king(queen?) among idiots. And the submitter, agl42, is a bastard prince(ss).

how did it escape both of you that google code != Google?

Re:vote for kdawson to be fired

[agl42]

It didn't escape me - I didn't write the subject line. To be clear: this has nothing to do with Google.

Re:vote for kdawson to be fired

[spir0]

very good. you are duly forgiven.

kdawson on the other hand deserves nothing short of an infinity of recieving chinese burns by gay zombie midgets.

Re:Less secure than 128bit SSL? Why?

[afidel]

If the encryption is computationally cheaper, then the decryption is computationally cheaper.

Not at all true, 3DES is much more secure than about 90% of the more computationally expensive encryption options.

Re:Less secure than 128bit SSL? Why?

[Anonymous Coward]

If you'd listened to the video, you'd have learned that the proposal uses Elliptic curve cryptography which is considered to require smaller keys to provide a similar level of security to the integer methods used in SSL. It does not automatically follow that, "If the encryption is computationally cheaper, then the decryption is computationally cheaper." If you'd listened to the proposal, you'd also have learned that it does not intend to replace SSL/TLS for strongly authenticated transactions, but only replace currently unencrypted traffic.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Here we go:

[PineGreen]

...we might be able to increase the depressingly small fraction of encrypted traffic on the Internet

Here we go: American paranoia again. I just don't get this country...

Re:Less secure than 128bit SSL? Why?

[Anonymous Coward]

Not true. Go read up on elliptic curve encryption.

Why not use mod-gzip?

[Marrow]

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.

HTTPS works on domain not IP number.

[Anonymous Coward]

You can even move host mid certificate and it will still work if you install it correctly on the new host.

You can use SSL for multiple domains on a single IP number, but you will have to get a cert for each domain.

And you can get certs quite cheaply.

Just make it cheaper

[Twillerror]

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.

[arcade]

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:So fucking wrong it isn't even funny.

[vux984]

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.

This list is BS.

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.

Until that, its completely meaningless.

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 !

self-signed certs have the potential to be secure if they are verified out-of-band. otherwise they are really NO DIFFERENT to plain http.

That you have been rated as 5 is completely nuts. You don't understand the security model, and neither does the moderators.

No, what is completely nuts is treating "absolutely no security whatsoever" to use your words any differently than plain http, which also has absolutely no security whatsoever. Our browsers don't freak out when they encounter a site with no cert, why should they freak out when they encounter a cert that is meaningless?

Given they BOTH offer absolutely no security they should treat self-signed certs the same as regular http... ie do nothing.

CA certs also give a false sense of security

[TheLink]

What I want is for the browser to give me a warning if the cert (self-signed or CA signed - separate warning controls) is a NEW one, or it has CHANGED since the last time (and the browser should keep copies of the previous certs for comparison).

CA signed certs give a false sense of security too.

1) Verisign have already proven they can't be trusted to do things right.
2) AFAIK with popular browsers you don't get a warning if the cert changes or even the CA changes as long as the cert is signed by a CA installed in the browser.

Of course in the greater scheme of things your banking and other sites probably have bigger security holes in practice that make all these cert problems look like "small potatoes".

SQL injection. "Mother's maiden name" to reset password (yes I know you can use something different from your mother's maiden name - but people who forget their passwords regularly will forget that too ;) ).

silly

[Anonymous Coward]

That's a silly argument. The fact is that self-signed certificates are more secure and more useful than plain HTTP, therefore, browsers shouldn't put up the silly warnings that they do.

Browsers could simply indicate http, https-with-self-signed, and https-with-authentication differently in the user interface.

Re:Less secure than 128bit SSL? Why?

[Anonymous Coward]

Not necessarily. It's my understanding that 256 bit elliptic curve keys give about the same security as 2048 bit RSA ones... at a substantial computational discount.

(Whether this understanding is true or not you'll have to look up yourself, but it seems plausible on the surface.)

Parent is Trolling.

[Burz]

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.

Re:Parent is Trolling.

[nmx]

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.

Yes, and in the cases you have described, Firefox will not show any warnings at all. It will treat it as trusted since you've already verified the certificate. What's the problem?

Re:Parent is Trolling.

[BitZtream]

Its funny that you talk about distributing the certs in a secure enviroment while calling me clueless ... considering I talked about doing just such a thing in the last paragraph and how thats the one way self signed certs are safe to use.

In the context of this discussion there is no out of band verification, if there was, the warning wouldn't matter since you'd see it once, verify the cert and save it. In that case the 'firefox is bad for its warnings!!!!' argument wouldn't exist. And seriously, telephone and print? You'll waste more time doing either of those things than just dealing with a CA who's already trusted.

So ... You may not be clueless about cryptography, but your ability to read the entire post and understand it is rather lacking.

Tagging

[Idiomatick]

Why is this tagged as story?....fine fine there is a type tag done by the system. Which really should be hidden until it is actually used for something... But this is tagged story again. It happend a few stories down as well. Is there really a need to tell us it is an article twice ontop of the fact that it is a site full of stories?

Why was that a video?

[SMS_Design]

It was just some dude talking with the occasional text showing up on the screen. YouTube as a medium for information dissemination is for complex ideas that require a visual aid. Not for making me stop my music to "read" an article.

Re:Less secure than 128bit SSL? Why?

[tqbf]

If the encryption is computationally cheaper, then the decryption is computationally cheaper. What four Slashdot moderators voted this stupid comment up?

Arrgghh! No more videos!

[Anonymous Coward]

If you watch the "video"

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:Arrgghh! No more videos!

[Keeper Of Keys]

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!

[ultranova]

Maybe I'd understand it better if I read it than if I heard it on a crappy video.

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.

Re:Arrgghh! No more videos!

[hesaigo999ca]

So true, I agree in giant amounts with you on this, and find that there is way too much of this going on on the web, with the illusion that by hearing the sound of someone's voice, you are more apt to think it is worth listening to, instead of skimming through the text for keywords and eliminating what you don't want to read (which is usually half if not more of the article)

Just give us the choice, if I want the video i will download it, have also the text version, so I can not waste my time with a 56k connection trying to download your stupid 30mb. videography.

"Power to the penguins"

Re:Arrgghh! No more videos!

[MadMidnightBomber]

Speaking as a Brit, may I be the first to apologise for our 'crappy' accents. I have written to our prominent thinkers asking them all to pretend to be from New York when delivering speeches in future.

Thanks for drawing this shortcoming to our attention.

I know; we all know

[Nicolas MONNET]

But seriously, you'd be amazed at the amount of FUCKTARDED nonsense "enterprises" do in the name of "security." (Need I mention TSA?)

Even DNSSEC doesn't have the whole answer!

[mcrbids]

It strikes me as fundamentally STUPID that SSL-like technology hasn't been fully incorporated into DNS. When I register a domain name, the person who can most authoritatively state who I am is me. DNS is the universal mechanism for me to declare what host(s) are qualified to represent my domain, so why do we have a completely separate, cumbersome, and counter-intuitive infrastructure for SSL?

Explaining what a signed SSL certificate is to most (non-techie) people takes several hours, if you want them to actually understand it. It's stupid that this complex, expensive, cumbersome security framework is basically all we have to secure sites on the Internet. It's no wonder that few sites do it!

But if, when you registered your domain, you automatically received a root-signed wildcard SSL certificate that you installed into your DNS server, you would instantly eliminate nearly all DNS spoofing attacks, and improve the security of the entire Internet.

You could still use the current SSL certificates system for additional security, but why not start with a reasonably secure system by default? It's just dumb that we aren't doing this already. Benefits of such a aystem:

1) When you pick up the DNS record for the domain, it would have a public certificate for the domain in the response. All DNS replies would come with a signature accompanied. This would effectively eliminate DNS spoofing.

2) When the browser hits the website, the browser already has the signed certificate (from the DNS query) and so is already "pre-set" to view the website. As a result, the website just has to either kick out the response (when not using encryption) with a signature in the headers (so you at least know you're getting the real deal) or you can use some encryption. Either way, the header should be present. You know you have the real deal, whether or not others can view it. This all but eliminates website spoofing, even if you don't encrypt the whole connection.

Either way, either with or without encryption, you still have improved the security of the connection simply by adding a small header.

Why isn't anybody doing this?

Net neutrality. user owned.

[leuk_he]

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.

Re:Net neutrality. user owned.

[ORBAT]

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.

[neumayr]

All those "cannot"...
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:Net neutrality. user owned.

[hobbit]

You might be protecting your traffic from the wardriving kid next door, but not from your ISP

Quite. But let's wait until they've rolled out Obfuscated TCP to all their equipment before sending them a DMCA takedown notice :)

depressingly small fraction of encrypted traffic

[Paleolibertarian]

Just a side comment. A consulting client, an accounting firm, asked about using encryption for emails etc... so I explained the steps necessary to generate a key pair, get the public key signed by a CA while getting their clients to do the same thing. This is BEFORE doing anything else. The reply? "Forget it!"

Another client, a medical clinic uses an insurance clearing house to process claims. The clearinghouse uses an ssl site for the clinic to upload their data. Unfortunately while the site uses ssl the actual data is sent using ftp and the data is in plaintext!

It gives me such a warm fuzzy feeling to know that programmers can be tech savvy enough to construct an ssl site but not competent enough to figure out how to transfer files over the ssl connection.

I am unfortunately culpable because I'd rather keep my clients rather than stand on principle. Even after I brought the situation to the clinic's attention the situation hasn't changed.

blanket MITM surveillance is not practical

[js_sebastian]

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,

Bzzzt, wrong, thanks for playing. I written an app that makes the process as easy as starting a sniffer,

Really? and what kind of hardware does it require to play man in the middle to all connections on a multi-gigabit line?

This is what we are talking about. Whether it is illegal mass-surveillance from the government, or just your isp trying to inject targeted advertisement in the web pages you browse, man in the middle is just not an option for blanket surveillance at the moment.

Also, it is detectable, while sniffing is not. If all users are intercepted with a MITM attack, as soon as one of them verifies the key fingerprint through a side channel it will become public knowledge that everyone is being intercepted.

Re:blanket MITM surveillance is not practical

[BitZtream]

Really? and what kind of hardware does it require to play man in the middle to all connections on a multi-gigabit line?

The same hardware that Sandvine and others already use for their DPI appliances that people like Comcast use to monitor and limit BitTorrent users. Saying its not an option is rather ignorant. Hardware designed to do this sort of thing isn't a pipe dream, it already exists. I'm sure that most people won't be in the position to do this, but I can already tell you that there are goverment security branches directly connected to major ISPs that monitor the traffic already, they most certainly do have the hardware horsepower to do EXACTLY this sort of thing. Its not NEARLY as hard as you would hope.

Also, it is detectable, while sniffing is not. If all users are intercepted with a MITM attack, as soon as one of them verifies the key fingerprint through a side channel it will become public knowledge that everyone is being intercepted.

True, but how many times have you verified the fingerprint on certs? I personally, even with my tin foil hat on, have only verified signatures on software that we develop and have uploaded to the public web server. I can not recall a time when I've ever verified a certificate manually for a browser connection.

security through obscurity!

[nimbius]

ask novell, microsoft, or cisco...what could possibly go wrong with hiding a poor authentication scheme from a user?

Re:security through obscurity!

[Ash-Fox]

ask novell, microsoft, or cisco...what could possibly go wrong with hiding a poor authentication scheme from a user?

You want us to ask Microsoft who still use md4 hashes for passwords over the network with no salt?

Correction

[marcosdumay]

The user interface gives you a false sense of security. Or, better yet, the unimaginative developers can't invent an interface that doesn't give the user a false sense of security. Don't mind that those same developers have complete control on the interface and can access quite well how secure the page is, and thus, they could tell the user exactly how much security he has.

On this case, a self signed page is exacly as secure as an unencrypted one. So what is stopping Firefox to present both situations on the same way?

C is big

[marcosdumay]

Case 'C' happens all the time. Let's say somebody out there creates a site where people goes to read articles and post comments. Now, those comments can be signed, but you'll need a login and a password. Also, you don't want to let somebody else gather your password, so he could impersonate you. That is case 'C'.

Re:C is big

[Burz]

Thanks. That's an interesting scenario for that use case. There are probably a number of other plausible scenarios, too.

Probably the strongest argument in favor of 'C' is that an attacker would have to have always MITM'd your connection and never, ever stop or else be discovered. Its unlikely that anyone could sustain that level of sabotage, irregardless of whether the user changes ISPs, or takes their laptop to different APs in different cities or countries. Some of the site's users may also use VPN and proxies from time to time, which would also open the attack to discovery. (Still, I would publish my cert's fingerprint anyway as its so easy to do.)

So, yeah, case 'C' is quite valid assuming the people involved don't get the wrong idea about accepting certs (e.g. that accepting one from a blog being OK makes accepting one from a bank OK too).

Re:C is big

[marcosdumay]

"So, yeah, case 'C' is quite valid assuming the people involved don't get the wrong idea about accepting certs (e.g. that accepting one from a blog being OK makes accepting one from a bank OK too)."

That's why the user shouldn't explicitly accept any cert. The browser should do that transparently, and present the page like if it wasn't ecrypted (except for a small menu entry, for expert users to see the details of the cert) and only annoy the user if the cert someday fails to validate.

That way, you have added security without misleading any kind of user.

Re:C is big

[Burz]

I disagree - Too much transparency, and the user won't even know what certs are. Then you have a worst-case scenario, where the user doesn't even notice the lock icon, much less understand a certificate warning dialog; people tend to be very dismissive of what they don't understand.

A web culture that includes self-signed certs and webmasters who are willing to explain to their users what a cert is will resist attacks far more effectively than the head-in-the-sand culture we have now.

Adults know what to do with keys and keyrings. Its how we manage our security without always appealing to central authority. But your position assumes that adults should be saved from themselves by insulating them from the notion of digital keys and keyrings used with the Internet. The more that assumption is advanced in place of user education, the more centralized authority schemes we have to bring online.

Re:C is big

[marcosdumay]

Well, the users will have as much contact with certs as they have now. They'll see the lock icon when visiting a site that is verified by some trusted CA, and will see no lock when visiting a not trusted site. If a webmaster wants his self sigend cert to be trusted by the users, he'll have to instruct them to proceed with options 'A' or 'B' from your post. The only difference is that they aren't presented a dialog that they already trained themselves to dismiss.

Users train themselves very fast when presented with a dialog that says "click here and get what you want" and "click here and don't get" and there isn't any danger on any of the options. When you display a warning at every single site that has a self signed certificate, most of the time the first option won't be dangerous. For that reason alone, people will train themselves to ignore the new Firefox dialog too, it is just a matter of time.

Now, when there is a real risk with some option, people do pay atention. That is why they know how to deal with their house keys. On places where violence is very low, people are as lax with keys* as most people are with digital certificates. Note that I'm not saying that the risks with certificates are low, just that there is a too big rate of false positives, so they are a very big burden when compared to the probability of loss. When presented with such a situation people simply don't cooperate with security.

* I've being in a place where people go out without locking their houses, because they cooked some food and the neighbours may want some. That is lax security.

Re:C is big

[Burz]

Now, when there is a real risk with some option, people do pay atention.

So then, why introduce an outright distortion in the process by claiming any self-signed cert is "invalid"?

Users of such sites aren't untouched by this change: New users will likely encounter the new error before they see any explanation from the webmaster; Occasional visitors who used to accept only for a session will now see a page that simply won't load. The latter may not care about security, but in both cases this error is leaving the user with an initial impression that the webmaster is some kind of incompetent or scammer.

Re:C is big

[marcosdumay]

I did not argue that self signed certificates should be "invalid", only that pages with self signed certificates should be presented the same way that pages with no certificate and encryption. That doesn't involve an error message, warnings, or a dialog asking the user what to do next. In fact, that involves no interation at all, and no trusting.

Apache bug

[The MAZZTer]

"Though SSL has been around for years, most sites still don't use it by default"

Isn't Apache still used on the majority of web servers? And doesn't Apache have a huge bug (or design flaw, whatever) where VirtualHosts don't work through SSL (IE: an Apache server can only serve ONE HTTPS site, and infinite HTTP sites)?

Re:Apache bug

[mindstrm]

It's due to the design of SSL - not apache.

In order for the request to be encrypted, certificate exchange & validation has to take place.

In order to vaildate a certificate, domains must match what's in the certificate.

IN order for apache to do name-based virtual hosting, it has to look at the request headers.

Request headers cannot be sent until after certificate validation has taken place.

Therefore you can only host one site without running into certificate mismatch problems.

Separate Authorization from Encryption ...

[Coreigh]

As rsmith-mac and I am sure many others have said:
"The W3C needs to separate authentication and encryption in the standards themselves, that's the only proper and safe way to change things."

How often do we find that it actually works better to "kill two birds with one stone?"

Make each work on its own. They both serve a different need.

Re:depressingly small fraction of encrypted traffi

[Starcub]

Isn't it illegal for a company to transmit confidential personal information about clients over an insecure network?

Re:corrected secruity hierarchy list

[Anonymous Coward]

0. SSL with cert which you recognize/know
1. SSL with cert signed by a trusted certificate authority
2. SSL with self-signed cert
3. Plain HTTP

I don't trust the "trusted certificate authority" all that much. It's much better to have remembered the certificate you used last time -- why don't browsers do this? SSH does...

Great idea.

[mindstrm]

It's a great idea.

Plenty of people will say "without authentication, encryption is useless". This is not true.

"Without authentication - encryption cannot protect your sensitive data" - this IS true.

With non-authenticated encryption - anyone can middle you. Easily. you won't notice.

The benefit is a large scale one, and has to do with numbers and methods. The government could possibly muster enough resources to MITM the whole internet... but doing so would be detectable, provable, and very differnet legally than just taking a passive copy of the bits on the wire, as they do now.

This method of using crypto won't prevent a focused attacker from getting at your bits... and by focused, I don't mean sophisticated.. just someone who's taking a moment to look at you, or the network you are on, rather than a massive amount of data and users at once.

What it will do is change the playing field, and Change the methods an ISP or other person must use to sniff our data and snoop on our bits... change it in a way that's beneficial for the end user.

That's an important change.

Validation steps

[Burz]

Yes, and in the cases you have described, Firefox will not show any warnings at all. It will treat it as trusted since you've already verified the certificate.

Incorrect. If the method of installing and/or verifying a cert is initiated by accessing the website in question, then the draconian/inappropriate warning will appear.

In fact all of those cases I listed (like verifying a fingerprint from printed correspondence) are normally done with the browser - it's the simplest way. You click the lock icon, then match the fingerprint in the dialog window to what is on paper or spoken to you over the phone: Voila, validated certificate.

A point to consider

[Anonymous Coward]

If you think that signed certs can't be used for a man in the middle attack you have no clue who is in bed with the American based cert companies. Hint, they all have 3 letter names.

Re:Less secure than 128bit SSL? Why?

[kestasjk]

Because when it comes to modern encryption "secure" means "would take every computer on the planet longer than the age of the universe to break" and "less secure" might mean "would take every computer on the planet a few months to break".

Hmm... delicious!

[mebrahim]

Cheaper than SSL, and also weaker. Something that many people are willing to use and probably only NSA can crack. Delicious! Thanks Google.

depressingly stupid people is gonna be da wormface

[Anonymous Coward]

"depressingly small fraction of encrypted traffic on the Internet"
Yes. Encrypt everything. NOTHING should be plain text. Openness sucks. You could then sell passwords...want online at all?...decryption key is ten dollars. Google decryption key...two dollars. Or would the decryption key just be time limited? Ten minutes of decryption: ten dollars!
Anyway, great thinking, there, Einstein.

Not equivalent.

[Andy Dodd]

Neither of those provide authentication of transport protocol flags (such as TCP RST), allowing denial-of-service attacks to be conducted against a connection regardless of the strength of the content encryption.

This approach DOES actually protect the transport from malicious interference, but that has its own issues.

Potentially more useful for peer-to-peer than HTTP

[Andy Dodd]

I'm not going to get involved with the whole "this vs. self-signed certs with SSL" thing.

One thing that SSL and SSH both do NOT do is protect the transport. Encrypt all you want, nothing stops you from getting Sandvined (having your traffic analyzed and then RSTs being sent based purely on bandwidth usage).

This approach actually implements authentication of transport protocol communications, such as RST flags. Thus it is not possible (or at least not nearly as easy as it used to be) for someone to send a spoofed RST at you and kill your connection.

The bad thing about this is:
It means the entire transport protocol must be reimplemented including congestion control and flow control.
There's a good chance that there will be buggy/"intentionally greedy" implementations out there where congestion control behaves badly, flooding the network.

Re:depressingly small fraction of encrypted traffi

[Paleolibertarian]

I can't say for sure because the congressional acts are written in legalese which I have a hard time with, but yes I think so.

I'm not sure about Sarbanes-Oxley but HIPAA certainly does.

Edwin