Attack of the Week: TLS Triple Handshakes (3Shake) | Hacker News Reader

Attack of the Week: TLS Triple Handshakes (3Shake)

blog.cryptographyengineering.com

91 pointstptacek25 comments

A great summary. Previous discussion on the original research paper: https://news.ycombinator.com/item?id=7334514

This comment in particular is my best effort at explaining the class of cryptographic attacks (identity misbinding, or "unknown key share") that 3Shake belongs to:

https://news.ycombinator.com/item?id=7335101

I was lucky enough to have Trevor Perrin try to explain UKS flaws to me at a BaySec meeting a few months back. The moral of Perrin's story was, "key exchange protocols are extremely difficult, moreso than most cryptographers appreciate". Worth considering before the default response to TLS flaws ("let's just scrap it and design a new one").

So, Thomas, when do I get to say "I told you so"?

Soon. As soon there's a well-reviewed workable alternative to TLS, I'll be right there with you, and I will write up something permanent as a concession/mea-culpa.

I still think TLS is a much better plan than inventing ones own encrypted transport. As things like UKS show: these things are hard to get right.

For what it's worth: reading the whole backlog of the IETF TLS WG mailing list probably did more to move my opinion closer to yours than anything else.

One thing that would limit feature creep would have the TLS WG maintain a POSIX reference library implementation, standard library compatibility interface (header file) and a comprehensive test suite. Because once the maintenance of that hits the people making suggestions and decisions, priorities will adjusted. (It still takes work to do the right thing regardless, but at least there would be a baseline, and behavior across implementations would be more comparable.)

Also, accelerate the sunset of older specs so that deployed code will have to stay more current to even function, rather than interop'ing with old code that will never be patched.

I'm not so sure. Look at Heartbleed: the vulnerable reference code was committed by the person who wrote the Internet Draft.

But then they would think twice before furthering "...serves too many interests, and (particularly in the TLS portion of the tree) is a grab bag of functionality" [0] of un-security-like features like heartbeats. They might think: "Do I really want to write tests and a demo for this, or can I make do with something simpler?"

If not, then this suggests a lack of clear guiding principles of what is in-scope and what is not &| insufficient questioning of adding new features.

[0] https://news.ycombinator.com/item?id=7566456

I think that is a real problem, yes; I also think that problem is endemic to open standards groups.

But that's not an acceptable assessment of leadership for a vital crypto WG, much less the leading implementation. So far, OpenSSL has added one dev and it seems like business as usual. Does anyone know if anything's changed at TLS WG (I'm not on the mailing lists)?

In other news, I ported LibreSSL to OSX today[0].

[0] https://github.com/steakknife/libressl

I'm not sure what to tell you. I follow the mailing lists but very deliberately don't post on them, because I would drastically increase the noise level, which is already often bad. I can say that it does not look like the TLS WG has a "default deny" stance w/r/t/ new features for TLS.

I like what Google is doing; they control the Internet's most important server properties and one of the most important clients, and are taking full advantage of that to testbed TLS refinements and then bring them to the IETF as working code.

That's what I was after... confirmation that it's a Tragedy of the Commons.

There's political ammo now to make necessary changes in how things are done to make sure OpenSSL, TLS WG doesn't continue with business-as-usual.

Careful, last time I made this as a top level comment, he pretty much lost it on me.

Let's see if everyone can understand the difference between a longstanding technical debate and a deliberate attack on my character.

Dual_EC was the former, and I have no idea how you would have interpreted it as a personal attack. But this probably isn't worth a subthread.

Edit: I've said it before, I greatly appreciate the crypto knowledge you share on HN. When crypto related submissions come up, I often click comments before reading the articles just to see your take on it. I did it just this afternoon with https://news.ycombinator.com/item?id=7642434 and was disappointed to see you had not weighed in yet.

Like I said, this is just drama. I like a lot of your comments too.

You should link to that comment so we can all see the context and judge for ourselves. :)

(sidenote: I'm very happy about all the attention SSL related stuff is getting. Just like Snowden said, encryption is our best defense against whoever and all the SSL stuff is the most commonly used encryption out there. Don't know what to do about dis-honest CAs though...).

EDIT: tptacek is probably right that this is drama and my sidenote should probably be the main comment

https://news.ycombinator.com/item?id=6944360

[deleted] is tptacek's comment I'm referring to, but it's quoted in the thread.

https://news.ycombinator.com/item?id=6420306 was a previous episode of the same debate.

tl;dr The issue was whether or not Dual EC was an NSA backdoor, and then whether or not there were any implementations. There was a time when tptacek denied both of these, saying it was too dumb to be a backdoor, and later conceding but saying it wasn't used in any software.

Interestingly, before the NSA paying RSA scandal came out, my post in the second linked thread says:

> Edit: Actually, I take that back. I have no problem believing that RSA Security are perfectly sane. Would we be completely shocked if the reason they chose a questionable default was due to coercion from the spooks? Only NSA has the keys, so it's a pretty safe backdoor.

Only 215 days ago, that sounded like tinfoil hat tier speculation.

I'm guessing it's this, but I didn't go too far back in the comment history so I may be wrong:

https://news.ycombinator.com/item?id=7430250

This is really just drama (I'm equally culpable here on this thread). Let's talk about TLS and UKS instead.

No, it wasn't that. That one was a bit silly (admittedly, so is this thread, and the one it references). I'll find it and edit this post.

Edit: linked upthread in my other comment.

> But before you get cocky, remember -- all these crazy features in TLS were put there for a reason. Someone wanted and demanded them.

While I guess that must be true, the OP was clever enough not to say that someone actually needed them.

And really, all we can say for sure is true is that someone wanted them. Whether they had to demand them or not depends on if there was any resistance to the feature from the standards body. Having seen some standards processes at play, it's sometimes more like "Hey, I think this is probably a good idea," "Okay, sounds good." Of course, some of those would escalate to "demands" if resistance was put up, and lack of energy for that fight is why sometimes resistance isn't.

However, I feel like the last couple years has seen such a raft of vulnerabilities that it may lead to an actually qualitative change in how people approach these things, and in the future security standards-making is going to be a lot more conservative about adding features. One can hope.

Doesn't change the main point that security is hard, and that surely the next gen of TLS, if it happens, will wind up with some vulnerabilities too.

People do need resumption. If you were designing a new encrypted transport protocol, it's likely that your starting point would include a mechanism to persist the initial key exchange across multiple connections; that's a sensible feature. It may be less and less necessary over the next decade if we transition to faster and faster ECC handshakes, but most handshakes today use RSA.

Similarly: renegotiation, an armpit feature of TLS, has a sensible use case: a server doesn't necessarily know whether a TLS client certificate is required until it can see the HTTP URL requested. But that doesn't happen until after the handshake completes. I'm not sure renegotiation is the best solution to that problem (as opposed to an HTTP 4xx status code response), but it's not as if the feature was crazy.

Nice to see they've continue the trend of ensuring each exploit has a proper logo.

Heartbleed taught us a lot of lessons. Imagery, a good explanation geared to people at all levels of expertise, a sense of urgency. I was impressed at all the attention it received.

It sounds silly, but even a good logo makes a big difference.

I appreciate that they didn't just copy the style of Heartbleed, they duplicated the exact drips from the original.

I suppose this is probably a browser bug given that I use a somewhat nonmainstream browser (Xombrero[1] on OpenBSD) but I get this error from time to time browsing HN. I've never seen it happen on any other website:

  Error performing TLS handshake: An unexpected TLS handshake packet was received.

Does HN do anything "nonstandard" with their https configuration?

1: https://opensource.conformal.com/wiki/xombrero

Reply on news.ycombinator.com