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

[Dr Stephen Henson <[e-mail]>]

On 04/03/2014 15:23, Martin Thomson wrote:
> On 4 March 2014 14:03, Dr Stephen Henson <[e-mail]> 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.
> 
> To provide some context, in HTTP/2 we are considering having multiple
> names share the same connection, as long as they are covered by
> wildcards or additional subjectAltName values.  You might start out
> looking for "foo.example.com", but as long as you have "*.example.com"
> or "bar.example.com" in subjectAltName, you will proceed with requests
> to "bar.example.com" on that connection.
> 
> I think that it would be unlikely that a renegotiated certificate
> would include some names from a previous certificate, but not others,
> but that might be a problem if an implementation fixates on a single
> name.
> 

Well in the specific case of OpenSSL a hostname is supplied via the API and that
is checked against the server certificate whenever it is presented. So it would
allow the certificate to change but an attacker would need a trusted certificate
matching the server's hostname. If they have that they can MITM the server
(provided it doesn't support client authentication) anyway.

It has been suggested that clients could be stricter and prohibit changes of
server certificate during renegotiation entirely, if not outright at least by
default.

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.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.