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

[Martin Thomson <[e-mail]>]

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.