September 06, 2005

SSL v2 Must Die - Notice of Extinction to be issued

A Notice of Extinction for prehistoric SSL v2 web servers is being typed up as we speak. This dinosaur should have been retired net-centuries ago, and it falls to Mozilla to clean up.

In your browser, turn off SSL v2 (a two-clawed footprint in protocol evolution). Go here and follow the instructions. You may discover some web sites that can't be connected to in HTTPS mode. Let everyone know where they are and to avoid them. (Add to bug 1 or bug 2.)

Maybe they'll receive a Notices of Imminent Extinction. When I last looked at SecuritySpace there were no more than 4445 of them, about 2%. But Gerv reports it is down to 2000 or so. (Measurement of websites is not an accurate science.)

Elsewhere, Eric Rescorla published some slides on a talk he'd given on "Evidence" (apologies, URL mislaid). Eric is the person who wrote the book on SSL and TLS (literally) and also served as the editor of the IETF committee. In this talk, he presented the case for "evidence-based security" which he refers to as looking at the evidence and acting on what it tells you. Very welcome to see this approach start to take root.

Another factoid - relevent to this post - he gave was that the half-life of an OpenSSL exploit is about 50 days (see chart half way down). That's the time it takes for half of the OpenSSL servers out there to be patched with a known exploit fix. Later on, he states that the half life for windows platforms with automated patching is 21 days for external machines and 62 days for internal machines (presumably inside some corporate net). This is good news, this means there isn't really any point in delaying the extinction of SSL v2: The sooner browsers ditch it the sooner the dinosaurs will be retired - we can actually make a big difference in 50 days or so.

Why is this important? Why do we care about a small group of sites are still running SSL v2. Here's why - it feeds into phishing:

1. In order for browsers to talk to these sites, they still perform the SSL v2 Hello. 2. Which means they cannot talk the TLS hello. 3. Which means that servers like Apache cannot implement TLS features to operate multiple web sites securely through multiple certificates. 4. Which further means that the spread of TLS (a.k.a. SSL) is slowed down dramatically (only one protected site per IP number - schlock!), and 5, this finally means that anti-phishing efforts at the browser level haven't a leg to stand on when it comes to protecting 99% of the web.

Until *all* sites stop talking SSL v2, browsers will continue to talk SSL v2. Which means the anti-phishing features we have been building and promoting are somewhat held back because they don't so easily protect everything.

(There's more to it than that, but that's the general effect: one important factor in addressing phishing is more TLS. To get more TLS we have to get rid of SSL v2.)

Posted by iang at September 6, 2005 12:45 PM | TrackBack

Are there any webservers that support name-based https virtual hosting? How it possible at all?

Several services (e.g. SMPT) can run concurrently on the same port as their TLS-protected counterparts. Is that true for http?

And the most important question: where is good documentation?

Posted by: Daniel A. Nagy at September 6, 2005 09:04 PM

It's totally true that services can run on the same port as their TLS-protected counterparts. Actually, SSL/TLS is woking on TCP/IP layer so as soon as you use SSL/TLS you can use whatever port you want, so it's true for http - the usual port for HTTPS is 443.
For starting documentation I think you can try this :

Posted by: Silver_h at September 7, 2005 03:41 AM

This is almost OT, but there is a misconfiguration on this website that keeps biting me.

The RSS feeds link to, however the SSL cert is only valid for (i.e. not or * and so my browser throws up a warning every time I follow a link from RSS.

Posted by: Robin at September 7, 2005 05:26 AM

The best source of info on how to create certs for sharing vhosts over TLS at the moment is the VHost Task Force page over at CACert. Click on the link below.

Sadly, the page concludes that this is not really totally possible as yet ... Servers such as Apache have just started to roll out some of the facilities needed, but browsers are not capable of probing these facilities until SSL v2 is no longer an issue.

Posted by: VhostTaskForce at September 7, 2005 11:02 AM

You missed my question completely. I know very well how to configure https servers as I have been doing that for a living at an earlier time in my career.
What I was asking is running http and https on the same port at the same time, much as SMPT and SMTP/TLS can be run simultaneously. Also, I was asking about running name-based virtual hosting via https, which the link that you provide explicitly claims to be impossible.
The previous comment answers my question so thanks to VHostTaskForce.

Posted by: Daniel A. Nagy at September 7, 2005 04:45 PM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.