5 ms·
Why TLS is called "TLS", not "SSL 3.1"
- chewxy 12y agoThe more I read into specifications and standardization stuff, the more amazed I am at how political we geeks can get.
- taeric 12y agoI'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.
- leorocky 12y agoThe 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.
- taeric 12y agoI 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.
- mpyne 12y ago> 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.
- leorocky 12y ago"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.
- leorocky 12y agoIf there isn't an easy way to find objective facts to cling to you're probably bikeshedding.
- taeric 12y agoI 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.
- kennytuan 12y agođổ 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
- jmnicolas 12y agoGeeks are humans too you know ;-)
- Already__Taken 12y agoI think you'll like this; http://vimeo.com/9270320 http://vimeo.com/9270320
- tptacek 12y agoSchneier 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.
- timdierks 12y agoThere'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.
- 12y ago
- omh 12y agoSo 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".
- tptacek 12y agoIt'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.
- yuhong 12y agoI would not go that far, but they could have fixed some flaws. Remember Bleichenbacher for example?
- tptacek 12y agoBleichenbacher is still there!
- ambrop7 12y agoCorrection: 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.
- tptacek 12y agoI 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.
- deleted 12y ago[deleted]
- pacaro 12y agoWhen 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...
- timdierks 12y agoDepending 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-apple-and-microsoft-the-next-mountain-to-climb-was/article_ea87fba2-a07a-11e1-81fe-0019bb2963f4.html http://www.insidetucsonbusiness.com/news/profiles/after-appl... and http://www.chocolatefox.com/ http://www.chocolatefox.com/
- matthiasb 12y agoThere 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 http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html Notice the paragraph at the end about RSA Data Security!"
- x86dev 12y agoAnd if you look at a TLS 1.0 handshake message you'll see 15 03 01
- lectrick 12y ago> 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 https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish