Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)

[Simon Josefsson <[e-mail]>]

Stefan Santesson <[e-mail]> writes:

> On 10-05-11 12:19 AM, "Simon Josefsson" <[e-mail]> wrote:
>
>> (different from what the real server would send), fail the
>> handshake, and let the client re-try against the real server, and the
>> client would then use the wrong cached information.
>
>
> And.... ?
>
> I don't mean to be rude, I just want you to complete the threat scenario.
>
> In what way may this serve the attacker?
> In what way may this cause serious harm to the victim?
>
> If the client is fooled to cache the wrong server certificate, key
> establishment will fail.
>
> If the client is fooled to believe in a false set of acceptable CA names,
> then the client may fail to find an acceptable client certificate to use.
>
> Both will cause the handshake to fail (and cause next attempt to be without
> caching).

I'm thinking about two scenarios:

 1) the undetectable modification of the list of acceptable CA names
    cause the client to select and use an unintended certificate.

 2) where multiple server certificates can be used to successfully
    establish the key.  That can happen if two certificates use the same
    public key.  Once connected, the client will not know the server by
    the same identity (certificate) as the server believe the client
    used.

This is not an problem in the sense that an attacker gains some benefit
(for 1 the client chose to proceed with the certificate and for 2 the
attacker needs to know the private key of the server): instead I'm
pointing at a semantic problem because, with the extension, the
historically true invariant that the client, after handshake, will know
which certificate the server used, does not hold strongly.

This doesn't necessarily have to affect the document in any way, but it
is an interesting property.

/Simon