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.
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.
Power and timing attacks are examples of side-channel attacks. :)
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?
And it isn't just politics. Some of the sleeziest, "salesman" tricks I have ever seen came from fellow developers pushing something.
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.
Indeed, one man's "objective fact" is another man's subjective opinion, especially once you introduce competing demands.
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 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.
Now, she's apparently making chocolate: http://www.insidetucsonbusiness.com/news/profiles/after-appl... and http://www.chocolatefox.com/
On this matter, anyone remember the Netscape random number generator bug:
Notice the paragraph at the end about RSA Data Security!"
TLS is also a better name than SSL. A "socket" is an implementation concept. TLS really does secure the transport layer.
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
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.
I'd make two counterarguments about RFC 793:
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.
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.