Home
Security, Crypto, and Random Topics
SSL session cookies vulnerable (SSL everywhere!) 
25th-Aug-2008 09:35 am
Elinor Mills' CNET's post titled Google making SSL changes, other sites quiet is interesting not just because it's about session cookies at some sites being vulnerable to MITM attacks, but also because it brings up a topic I've been talking about for years: Using SSL for all connections, not just for login. (See here, and here, among others)

She quotes Mike Perry:
"Just about everyone but Google simply does not want to spend the money to invest in the security of their users, and will continue to ignore this issue, just as they have for the past year," Perry wrote in an e-mail.
Mike is being generous. Companies have been ignoring this class of issue for the past decade. In 2008 web sites that deal in money or personal information (like email) need to secure 100% of all connections, 100% of the time. It is not enough to secure just the login pages.

And as for cost? It's not really about buying new machines anymore. (See my posts, linked above) SSL has been more than fast enough for years. It's really just a matter of inertia.
Comments 
25th-Aug-2008 05:50 pm (UTC) - IP addresses
Anonymous
IMO the most annoying thing about HTTPS is that you need one IP address per hostname (or at least one IP address per domain if you use a wildcard certificate).

Though I haven't been denied new addresses so far, I assume that there is a rather low limit on how many I can get.
25th-Aug-2008 06:32 pm (UTC) - Re: IP addresses
Anonymous
RFC 4366 provides a way to do this. Unfortunately, while Opera, Firefox 2+ and MSIE 7+ support this, IE only supports it on Vista¹ so it will be quite a while before it's actually usable.

¹https://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf
26th-Aug-2008 12:02 am (UTC) - Mark those cookies "secure"
Anonymous
Even if your application is 100% over ssl, and you don't even have a service running on port 80, if your cookies are not marked with the secure flag the attacker can get them through a network based attack. Insert an <img src="http://securesite:443"> into any HTTP request that may occur (browsing livejournal over HTTP perhaps?) and the cookie will be delivered in plaintext to the secure port. The SSL handshake fails because the server was expecting SSL and the client wasn't, but it's too late. The cookie has been exposed.
This page was loaded Nov 9th 2009, 8:22 pm GMT.