Re: [TLS] MITM Attacks on Client Authentication after Resumption

After my talk at the meeting, its worth summarizing comments on the triple
handshake attack and its impact on client-authenticated TLS renegotiation.

In the common case (e.g HTTPS) where a server presents  a certificate in
both the initial handshake and during renegotiation, it would be enough for
the client to verify that the certificate doesn't change. (More precisely,
the client needs to verify that the principals represented by both
certificates are equally trustworthy.)

There are other cases, and I'd be curious to know how common they are, when
one or both handshakes does not have a server certificate. These would be
more difficult to fix with a general TLS library-level policy.

Typical examples (from discussion at the meeting):

- Initial handshake uses DH_anon or a self-signed server cert
  and renegotiation uses the real server certificate

- Initial handshake uses a server certificate,
  and renegotiation uses PSK or SRP to authenticate the user

In the first case, I guess the purpose is to protect the server name from
passive attackers. In the second, the purpose is privacy for the user's
SRP/PSK identity.

In both cases, if both handshakes happen on the same connection, RFC5746
(renego indication) gives us a pretty strong guarantee that the principals
on both ends do not change. In effect, the second handshake retroactively
authenticates the first.

The triple handshake attack shows that this nice guarantee does not hold if
there is session resumption between the two handshakes.

I can't think of easy implementation-level ways of fixing the DH_anon and
PSK/SRP cases.

Best,
Karthik

On Wed, Mar 5, 2014 at 5:09 AM, Xuelei Fan <xuelei.fan@vimino.com> wrote:

> On 3/5/2014 12:05 AM, Dr Stephen Henson wrote:
>
>> On 04/03/2014 15:23, Martin Thomson wrote:
>>
>>> On 4 March 2014 14:03, Dr Stephen Henson <lists@drh-consultancy.co.uk>
>>> wrote:
>>>
>>>>
>>>> I performed a few checks with an experimental option to change the
>>>> server
>>>> certificate during renegotiation, which I believe simulates the attack
>>>> mechanism. If the client checks certificates in band then all versions
>>>> choke
>>>> with a verification error if a chain is untrusted. For 1.0.2 only it
>>>> also chokes
>>>> if the chain is trusted but the hostname doesn't match.
>>>>
>>>
>>> This is an interesting option.  I like the general idea, but wonder
>>> what "hostname doesn't match" means in this case.
>>>
>>>  JSSE enabled the hostname checking during handshaking for HTTPS and
> LDAP.  If hostname doesn't match, the handshaking is terminated immediately.
>
>
>  I'd be interested if anyone knows of examples where the server
>> certificate does
>> have to change during renegotiation and how common that practice is.
>>
>>  I was wondering, if the cipher suite is changed from RSA cert based to
> EC cert based (and vice versa), the server certificate would have to change
> accordingly.  Not sure about the case in practice.
>
> Xuelei
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>