

Really bad SSL/TLS flaw discovered with client renegotiation - tptacek
http://www.ietf.org/mail-archive/web/tls/current/msg03928.html

======
tptacek
Ouch.

So, here's what's up: applications that rely on client certificates (where the
client had to have a valid, accepted cert to make a request) can, on most
servers, be coerced into accepting unauthorized requests.

Most applications HN people are familiar with don't use client certificates.
They're cumbersome, but (the conventional wisdom goes) much more secure,
because the client has to cryptographically prove their identity.

But lots of important high-security apps do require client certs, including
SSL-VPNs.

The problem boils down to this: when you connect to (say) a web app that wants
a client cert, the client usually doesn't offer their cert first, and the
server can't tell if the client even needs to do that until it routes the
request. During that window of time, the SSL client is anonymous. When you hit
a resource that needs a client cert, the web server tells TLS to renegotiate
the session to get the client cert --- _but it can't throw away the data from
the anonymous portion of the connection_.

So, if you're a man in the middle, you can stuff an HTTP request into an
anonymous session, then splice the client to the server for the renegotiation,
and you got to send a free request. You can't see the response (it's encrypted
under the new TLS session, which is now cryptographically protected from you),
but you were able to make a potentially dangerous request that appeared
authenticated.

There's more about this attack at this link, including a PDF report on the
general problem of client renegotiation:

<http://extendedsubset.com/?p=8>

~~~
NateLawson
A good summary of the possible fixes is here: [http://www.ietf.org/mail-
archive/web/tls/current/msg03943.ht...](http://www.ietf.org/mail-
archive/web/tls/current/msg03943.html)

The best approach is the one advocated by ESR's internet draft, namely binding
sessions to IDs better. [http://www.ietf.org/mail-
archive/web/tls/current/msg03963.ht...](http://www.ietf.org/mail-
archive/web/tls/current/msg03963.html)

This flaw is a result of layering within SSL. The client key exchange
component carefully verified the user and the record protocol protected the
data, but no one checked the binding between the two.

I'm aghast. Both the client and server should reject data sent before the
client/server key exchange if authentication is required. There should be no
protocol state transition edge for "session -> data1 -> authenticated session
-> data2". I can think of no good reason to mix the two.

------
ErrantX
The responses to this are worth reading too:

[http://www.ietf.org/mail-
archive/web/tls/current/msg03943.ht...](http://www.ietf.org/mail-
archive/web/tls/current/msg03943.html) [http://www.ietf.org/mail-
archive/web/tls/current/msg03942.ht...](http://www.ietf.org/mail-
archive/web/tls/current/msg03942.html)

Calling this "really bad" is perhaps pushing it a bit far; this is not
something that is going to cause widespread panic tomorrow: because it's going
to require more security flaws outside of the TLS connection - i.e. the
unauthenticated request has to be useful :) Call it a gotcha for the moment!

What this _should_ be is a heads up for TLS servers/clients to rework the
renegotiation sequence slightly (again see the response link).

------
cperciva
So Thomas, we should all use SSL because it has been extensively studied and
has no security flaws, right? :-)

~~~
tptacek
Yes.

(1) This flaw doesn't hurt your service, and you do more with TLS than most
people here.

(2) It doesn't hurt most TLS services, which don't use client auth.

(3) "It has no security flaws" is a straw-man argument. There was a much more
serious implementation flaw this summer: common SSL implementations could be
spoofed by embedding NUL characters in certs. Every time something like this
gets found, the protocol gets _stronger_ , not weaker.

(4) The odds of you or me or anyone else on Hacker News developing a crypto
transport for which an attack as slick as this would be required are basically
nil.

(5) This isn't so much a TLS problem as it is an HTTP + TLS problem. The core
issue is that HTTP doesn't really understand how TLS works; it looks like TLS
appeared to give HTTP the ability to "upgrade" a connection, when in fact that
TLS really does is "tunnel a new" connection. HTTP could have had a "369
PROVIDE CLIENT CERTIFICATE" error code instead of trying to reneg connections.

I should end with a question. Questions usually seem to stop you cold. So
here's mine: name the widely-used cryptographic transport protocol that
someone invented that _didn't_ subsequently have very serious flaws uncovered
in it.

~~~
cperciva
_This flaw doesn't hurt your service, and you do more with TLS than most
people here._

I do? The only thing I use TLS for is the Tarsnap website.

 _The odds of you or me or anyone else on Hacker News developing a crypto
transport for which an attack as slick as this would be required are basically
nil._

Tarsnap's transport layer is described and implemented in the public Tarsnap
source code. If you're so sure that there are easier attacks against it,
please go find one. :-)

 _This isn't so much a TLS problem as it is an HTTP + TLS problem._

Agreed. The whole thing is a layering violation, and it's not surprising at
all that it's screwed up.

 _name the widely-used cryptographic transport protocol that someone invented
that didn't subsequently have very serious flaws uncovered in it._

As JoachimSchipper points out, the SSH transport protocol has done rather
better than SSL. More importantly, however, you're unreasonably limiting
things by restricting consideration to _widely-used_ protocols: In general,
widely-used protocols tend to be protocols designed by committee which contain
everything except the kitchen sink -- and it's that precisely that excessively
large feature set which makes SSL so hard to get right.

~~~
tptacek
SSH was gameovered in v1, and the current protocol has had serious findings. I
could argue that the worst SSH flaw is worse than the worst SSL flaw, but I
don't have to; that's not my point.

Instead of answering my question, you editorialized. I'll assume you can't
name a widely-used crypto-secured protocol that hasn't had a serious flaw
discovered. That's OK, because I probably can't either.

It took over 10 years for anyone to find this most recent flaw in HTTPS. You,
for instance, didn't know about it. That's OK; neither did most cryptographers
and protocol designers. What's weird is that from this fact you manage to draw
the conclusion that people should just design their own protocols, as if they
would do better _without_ 10-15 years of attention from hundreds of academic
and industry researchers.

I happily recomment Tarsnap to people, Colin, but to my mind the reason there
are no findings in the Tarsnap protocol is that a finding in Tarsnap is worth
$0 to an industry researcher and 0 cites to an academic researcher.

~~~
cperciva
_You, for instance, didn't know about it._

Quite true -- but my attention rather drifted once I got past page 50 of the
RFC. I would argue that any cryptographic protocol which cannot be described
in less than 10 pages is too complex to be secure.

 _a finding in Tarsnap is worth $0 to an industry researcher_

Come on Thomas, I'm sure it would be worth at least $1 to you to have me shut
up about SSL. :-)

~~~
tptacek
That would be worth much more than $1 to me, personally, but unfortunately not
worth enough to offset my bill rate.

Your first argument --- crypto protocols that take more than 10 pages are
insecure --- is, I think, asinine. Not you, just the argument. The argument is
asinine. You're great. Argument: not so much. Why? Because more damage has
been done to Internet security by crypto protocols that can be described in
under 10 pages than has ever been done by TLS. Start with PPTP, RADIUS, and
RDP, but I can keep going.

~~~
cperciva
I didn't say that protocols which can be described in under 10 pages are
necessarily secure! However, if you can describe something in less than 10
pages, it's probably going to be _obviously_ insecure, rather than having
problems lurking unnoticed for a decade.

------
peterwwillis
Can anyone reply back with a list of known services which would be affected by
this attack? Would like to stay away from them until patches have been
circulated...

~~~
evgen
The the service does not require you to have a client cert then you are safe.
If you are not sure about whether or not you need a client cert for a service
then you probably don't use one. As mentioned previously, the only commonly
used systems that have this vulnerability are SSL VPN setups with the paranoid
bit turned on.

