

Attack of the Week: TLS Triple Handshakes (3Shake) - tptacek
http://blog.cryptographyengineering.com/2014/04/attack-of-week-triple-handshakes-3shake.html

======
tptacek
A great summary. Previous discussion on the original research paper:
[https://news.ycombinator.com/item?id=7334514](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](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").

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

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

~~~
smtddr
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_

~~~
jontas
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](https://news.ycombinator.com/item?id=7430250)

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

------
jrochkind1
> _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.

~~~
tptacek
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.

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

~~~
BrandonMarc
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.

------
ams6110
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](https://opensource.conformal.com/wiki/xombrero)

