I would argue they lose nearly all of the security benefits of SSL

I’d like to know more about what you see as the benefits of SSL.

For most traffic all I need is to know that the communication to the server is encrypted so that other users at the coffee shop or whatever can’t hijack the connection or see what it is carrying.

For my bank and other such high-value systems obviously I want a greater level of security where there are more reliable protections against more sophisticated types of attacks.

Use WPA with a strong password.

One simple option is a Firefox plug-in http://www.getCocoon.com and it provides secure SSL encryption on any connection and is literally just download and go, instant protection. Full disclosure, I do work for the company, but the product is in beta and free, so give it a try and please share your feedback. Thanks! David

atenlabs.com/blog/how-to-steal-facebook-authentication-cookies/

I wrote that back in June, but the actual vulnerability is inherent to ALL PHP SITES.
Well, all php sites that don’t encrypt, anyway.

For those who care, the program is great. I have already helped different people understand how to be more secure in there lives. It is funny how a friend will not listen to what you have to say about security until you begin posting the warnings as him on his favorite social networking site. Also interesting is that many sites that have a mobile variant are vulnerable even if the non-mobile version of the site is not.

I this program is most important not b/c of what it does (since many people have been able to do exactly what this program does for several years at least) but because it makes it so incredibly easy. Btw, I will not list them, but not all banks are protected from this type of exploit, although they all should be.

addressing the issue where it is broke would be more effective than shotgunning the upstream services.

Secure encryption between the pc/laptop/smart-phone and the wireless router would close this hole.

So how about an SSL-like security protocol for each connection on ‘open’ wifi networks?

For most traffic all I need is to know that the communication to the server is encrypted so that other users at the coffee shop or whatever can’t hijack the connection or see what it is carrying.

Your communication to the server will be encrypted all right. The problem is you won’t know what server you are connected to. It could very well be that hipster looking dude over there playing man-in-the-middle with his laptop.

Just to reiterate – that’s what the CA signing process is for – it’s the CA certifying that they have verified that the person who submitted the certificate request to them, is in fact
- who they claim to be (in the case of a personal cert such as you might use for email encryption), or
- a legitimate operator of the domain name for which they requested the certificate (in the case of a certificate for a server)

So, now, you enter https://bankofamerica.com in your browser’s address bar, and hit return. The browser requests the OS to make a DNS query, to look up an IP address based on the name, but that result could be incorrect due to error or deliberate tampering. The browser makes a connection to that IP address, but that connection could also be misrouted due to error or deliberate tampering.

Now, the browser establishes the SSL connection. It checks that the certificate is for the host name bankofamerica.com, that the period of validity of the cert hasn’t expired, and that the cert is signed by a trusted CA.

If all that holds, then the browser will let the connection proceed without alerting you of an error, having ascertained that
- It is in direct, untamperable, unsnoopable contact with a server that is in possession of the certificate that was just presented to it.
- The host name in the certificate matches the host name the user intended to connect to.
- The certificate is currently valid.
- An organization this browser (or operating system) is configured to trust has certified that the certificate presented to the browser, was requested by a person who was entitled to make such a request on behalf of the Bank of America.

That last statement is actually somewhat weaker than the others – a basic certificate only certifies that they’re entitled to make the request on behalf of the domain bankofamerica.com. An extended validation certificate (if I’m remembering the term correctly) will extend to cover what corporate entity is making the claim to the domain name. Modern browsers will display additional information when they see an extended validation cert.

The problem is you won’t know what server you are connected to.

Can you explain briefly how SSL with certificates signed by a signing authority prevents a man-in-the middle?

This is of course not an issue for a big company like Facebook or Google, but a big problem with universally extending HTTPS to the entire web ecosystem.

The problem with HTTPS everywhere, unfortunately, is that you need a trusted signature signing authority.

Are you sure about that? Can sites not self-sign their certificates?

That obviously loses some of the features available with a trusted signing authority, but still gets you some useful features.

The key term in “HTTPS everywhere” is actually the “Everywhere” part. The vulnerability Firesheep targets is the use of authentication cookies sent without SSL, after a login process that (typically) used SSL for the credentials themselves.

It’s true that SSL certificates cost a few hundred bucks, which can be an issue at times for smaller sites, but this is targetting sites that already have SSL certificates, but design their sites to not use that SSL protection completely.

Oh, and @IPFREELY – If you’re on a small coffeeshop network, the odds are very high that the WiFi network will use private addresses, and everyone in the place will be NATed to the same Internet-visible IP address once their web traffic hits the Internet. At that point, you and the cookie-hijacker at the next table have the same IP anyway. And, depending on the NAT scheme, it’s quite easy for a single internal computer to bounce around from one Internet-visible IP address to another, inside the expiration lifetime of a cookie (to say nothing of walking down the block from the coffeeshop to the library).

Can sites not self-sign their certificates?

That obviously loses some of the features available with a trusted signing authority, but still gets you some useful features.

I would argue they lose nearly all of the security benefits of SSL, and even makes it worse for users of sites that implement SSL properly, by getting them used to ignoring SSL errors.

When a browser and server initiate an SSL/TLS connection, the browser can opt, using the CA information that it has built in or from the OS out of band (not in the same communications channel that could be compromised) to contact the CA to validate the server’s certificate information.

A man in the middle would need a valid certificate for the domain signed by a valid CA in order for the browser to accept that security is established. There have been social engineering attempts, and also some revoke CAs that improperly issue certificates without checking the identity of the party requesting it. (There’s a certificate revocation process, too.)

A man-in-the-middle with a still-valid certificate for a popular domain signed by a still-valid CA (before it’s discovered) could compromise connections if it could also poison ARP and potentially poison DNS!

…would be a great way to trick people into downloading your malware. :)

In other words, Firesheep should work beautifully here. My wifi card doesn’t seem to like it, though, so I can’t say for sure.