Why TLS is called "TLS", not "SSL 3.1"(tim.dierks.org)
tim.dierks.org
Why TLS is called "TLS", not "SSL 3.1"
http://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html
8 comments
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.
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.
SSL 2.0 is a disaster
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?
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?
The more I read into specifications and standardization stuff, the more amazed I am at how political we geeks can get.
I'm always amused by the attitude that "politics is what other people do."
And it isn't just politics. Some of the sleeziest, "salesman" tricks I have ever seen came from fellow developers pushing something.
And it isn't just politics. Some of the sleeziest, "salesman" tricks I have ever seen came from fellow developers pushing something.
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.
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.
> 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, especially once you introduce competing demands.
Indeed, one man's "objective fact" is another man's subjective opinion, especially once you introduce competing demands.
"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.
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.
If there isn't an easy way to find objective facts to cling to you're probably bikeshedding.
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.
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.
đổ mực máy in canon giá rẻ quan tâm hiên hệ nhé
http://thaymucmayin.litado.vn/do-muc-may-in-canon
http://thaymucmayin.litado.vn/do-muc-may-in-canon
Geeks are humans too you know ;-)
I think you'll like this;
http://vimeo.com/9270320
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.)
Now, she's apparently making chocolate: http://www.insidetucsonbusiness.com/news/profiles/after-appl... and http://www.chocolatefox.com/
Now, she's apparently making chocolate: http://www.insidetucsonbusiness.com/news/profiles/after-appl... and http://www.chocolatefox.com/
There is an interesting comment below the article:
"Yuhong BaoMay 23, 2014 at 10:14 AM
On this matter, anyone remember the Netscape random number generator bug: http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html Notice the paragraph at the end about RSA Data Security!"
On this matter, anyone remember the Netscape random number generator bug: http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html Notice the paragraph at the end about RSA Data Security!"
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.
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.
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.
I knew someone was going to dispute that. :)
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.
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.
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 :/.
That was seen as politically too close to Netscape's position. If you weren't there, you have no idea: Microsoft/Netscape was a trench war.
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.
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.
It probably made open source development explode though. Microsoft couldn't really effectively compete with free software.
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.
These motherfuckers...
https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
These motherfuckers...
https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
[deleted]
And if you look at a TLS 1.0 handshake message you'll see 15 03 01
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.