TLS MITM attack

I haven't read through the linked articles carefully, but on first
glance it looks pretty annoying. Apparently there is a bug in the TLS
renegotiation protocol that allows a MITM to inject arbitrary chosen
plaintext into the "authenticated" session. This can be turned into
nasty attacks against HTTPS, among other things. There is a patch
available that disable renegotiation in OpenSSL and I guess it would
be a good idea to use the patch.

TLS has always seemed pretty ad hoc to me. If it were being designed
today, would we do a better job?

Actually the bug is not in TLS but in the assumptions made by the HTTP
servers. It seems that the servers believe that when they have
renegotiated a new key with the client, then whatever characteristics
obtained through that renegotiation (e.g. client authentication with a
client certificate) magically extend to the data which was exchanged
prior to the renegotiation.

It shall be noted that the TLS specification is especially silent on
what renegotiation is about and what security features it provides.
Moreover, the HTTPS protocol, with its schizophrenic dichotomy between
the transport layer (the bidirectionnal tunnel offered by TLS) and the
message layer (the nominally independent HTTP requests, each receiving a
single response), makes it quite difficult to implement some serious,
cryptographically supported session management, which is the very reason
why Web server have to resort to TLS renegotiation. The proper solution
would have to make the client repeat the original request (which
prompted the renegotiation) through the renegotiated tunnel, but it
would require HTTP to include a response code for "say it again please".

Disabling renegotiation in OpenSSL is akin to evacuating a building in
case of fire: an emergency procedure, which is no solution in the long
term (people were in the building for a reason, mind you).

SSH is, to some extent, a redesign of TLS, which ended up to be as
clunky as TLS. What makes SSH more bearable is that nobody tries to mix
it up with HTTP.

--Thomas Pornin

Having many times read "Use SSL" given as advice in this forum, I'm
glad someone else is questioning it. While the advice is good in that
TLS is better than naive programmers' homebrew, it has its problems.

--Mike Amling