Schneier was definitely famous in the late '90s, when this decision was made; he was famous almost immediately after the publication of Applied Cryptography, which came out when I was in high school.
SSL 2.0 is a disaster. The handshake isn't protected. Records (the data unit of SSL/TLS) do have MACs, but the MAC is secret-prefix MD5, with a key shared by encryption. Record MACs are also inconsistently applied. All of these problems are probably worse than any of the major TLS bugs --- renegotiation, BEAST, CRIME, RC4, Lucky13 --- that followed SSL 2.0.
Paul Kocher is the author of SSL 3.0, but also famous as one of the first (possibly the first) researcher to publish on side channel attacks --- he released a technical paper on square-and-multiply timing against RSA in the '90s. He founded Cryptography Research, which later built the as-yet-unbroken pay TV card system and the Blu-ray BD+ DRM system, along with publishing a crapload of crypto research.
There's "famous", below that, maybe "wonk famous" and then there's "nerd famous". At the time, Bruce was only the latter, at best; in fact, probably only at the lower, entry-level, "crypto nerd famous". Now, he's arguably wonk famous (that is, within epsilon, everyone on HN has heard of him, a reasonable fraction of readers of the NYT op-ed page will recognize his name, but less than 5% of the US population).
Yes, I think Paul is probably the mass-market father of side channel attacks; I believe he has the first published research on power use attacks and he's also done good work on timing attacks.
And, yes, SSL 2 is a mess: it was only not-broken enough (with the info we had at the time) to not be an SSL 1 or heartbleed-like "patch ALL the software" crisis.
How bad is this? I have internet-facing production web servers running software which (unfortunately) does not support TLS even in the most recent versions.
Are there practical attacks I should be worried about?
Yea, I think it took until 2006 before IE and Firefox was able to disable SSLv2. SNI doesn't work with SSLv3 though, and the increasing IP address crunch and the obsolescence of XP/Server 2003 will make it more common.
The only tricks I'll buy from fellow developers are competent solutions focused on the problem at hand. Focus and competence. Often it is nought for us to decide the product we work on, simply the approach.
Whatever is optimal. I'm not saying what you're saying doesn't happen, it does, but I feel like I've wizened, and when you stick to objective facts, not subjective crap, even at the expense of making your friends unhappy with you, you'll have found a cure. In a good engineering department facts are a sharp sword that can cut through bullshit as if it were butter. Be careful though, that edge doesn't care who wields it, it'll cut down your own bullshit and errors too. Personally I welcome having bad ideas and incorrect knowledge slain from my mind.
I think the major caveat here is that there is probably more subjectivity in day to day developer decisions than there is objectivity. And often times seeing that distinction where it doesn't actually exist is a pain point.
"Indeed, one man's "objective fact" is another man's subjective opinion"
If it's objective, it's objective. It's not subjective. Objective facts can be measured with numbers in units of time, bits and money. If your objective facts don't involve numbers, then yeah they're probably actually subjective.
I offer no objections to that assertion. I just currently feel that more decisions are of the nature than not.
I am also in a place where the development team has managed to jump between upwards of four dependency management strategies and as many ways to communicate with the backend in the past few years. To say I am jaded on some of the decisions is an understatement.
When I worked in Windows Security (BitLocker FWIW), Barb Fox's office was a windowless closet with an antique computer and a bunch of boxes in it that hadn't been touched in years. I've no idea what she was doing at that time, but nobody ever saw her and her stuff was religiously moved to a new closet every time we moved buildings...
Depending on the exact year, going to standards meetings, probably. (If I recall, she spent some time on leave after being active in security standards but before she left Microsoft.)
So they couldn't call it "SSL 3" because it couldn't be seen to be the Netscape proposal - fair enough.
But it's a shame they didn't take the simpler route and just call it "SSL 4".
It's actually frustrating that the SSL name lived on at all. A clean break would have been better. The parts of TLS that are derived from the original SSL 2.0 system (mainly the ciphersuites) are a plague.
TLS is also a better name than SSL. A "socket" is an implementation concept. TLS really does secure the transport layer.
Correction: While the socket is an implementation concept in some implementations, it generally is not. From RFC 793 (TCP):
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. Concatenated with the network
and host addresses from the internet communication layer, this forms
a socket. A pair of sockets uniquely identifies each connection.
That is, a socket may be simultaneously used in multiple
connections.
But then, it is a TCP specific concept, and TLS is a better name because it can be used on top of other transport layers.
1. It was written in 1981. You can find lots of other terms in early-80s RFCs that are no longer applicable to modern TCP/IP.
2. It was written in a time when Unix (and I guess VMS) implementation concerns infected all of standards work; if you follow the IETF, particularly DNS, there has been a long painful process of trying to disinfect standards of implementation entanglements.
But we agree on TLS being the better name, which is probably all the matters to the thread.
I agree for the most part, although as someone who wasn't really paying attention at the time it took me a surprisingly long time to figure out that TLS didn't just mean Thread Local Storage :/.
To give some flavor: I was working at a 3D modeling company that was working on a license deal with MS to provide models for the new Direct3D. We needed a way to browse and visualize models; Java applets was all the rage, and I even found a cool voxel component that would let people see the geometry without giving them the actual geometry.
MS and Netscape both had a set of "foundation classes". Netscape's were much, much better, so, given the time constraints, I used those. Because of a little bit of window dressing in the scroll bars, somebody from a recent acquisition noticed it was Netscape's classes and, by itself, that killed my project and almost killed the entire deal.
The nineties were an ugly time for software development, thanks to Microsoft.
For those who have read God Emperor of Dune, Microsoft was essentially like Duke Leto II. It/he suppressed freedom and creativity until it was like a pot boiling over and exploded all over the kitchen.
> As a part of the cutthroat competition, Microsoft decided to revise the SSL 2 protocol with some additions of their own, and specified a protocol called "PCT" that was derived from SSL 2. It was only supported in IE and IIS.
SSL 2.0 is a disaster. The handshake isn't protected. Records (the data unit of SSL/TLS) do have MACs, but the MAC is secret-prefix MD5, with a key shared by encryption. Record MACs are also inconsistently applied. All of these problems are probably worse than any of the major TLS bugs --- renegotiation, BEAST, CRIME, RC4, Lucky13 --- that followed SSL 2.0.
Paul Kocher is the author of SSL 3.0, but also famous as one of the first (possibly the first) researcher to publish on side channel attacks --- he released a technical paper on square-and-multiply timing against RSA in the '90s. He founded Cryptography Research, which later built the as-yet-unbroken pay TV card system and the Blu-ray BD+ DRM system, along with publishing a crapload of crypto research.