Re: [TLS] Fwd: Cached Info

[Hannes Tschofenig <[e-mail]>]

Hi all,

in the off-list conversation I have also provided my remarks on the
raised issues.

Here is what I said:

-----------------

Thanks for spending the time to look at the document.

There were indeed concerns about the length of the hash in the working
group and, as you said, there was specific attack raised.

It is true that an attacker (or someone else) can create a certificate
that matches the hash of the certificate used by some other site,
particularly when the hash size is very small (4 bytes in our case).

It appears to me that the vulnerability described below assumes that the
client is somehow tricked into accepting the wrong certificate.

The client stores the hash of the obtained certificate locally after
completing a full handshake with the server. As such, it has to store
the server identity together with the hash.

This cache then has to be populated with the certificate provided by the
adversary.

The client then has to pick the wrong certificate, which matches the
fingerprint.

Such a scenario can indeed happen if the client TLS implementation does
a lookup of the certificate based on the hash alone rather than taking
the server identity into account.

In the other attack that Karthik described the client has to connect to
the malicious server and then that server would relay the messages to an
honest server and the signatures from the client would have to correctly
verify. I am missing a few assumptions about what else needs to go wrong
for this attack to work. Getting the honest server to just accept
relayed client certificate and a signature requires more than the TLS
Cached Info extension

Regardless of the details I understand the concerns. There is indeed an
additional level of brittleness with the introduction of the shortened
hashes. While they consume less bandwidth over the wire (which is nice)
they require a careful implementation.

-----------------

In a nutshell, while I do not believe that the attack described is
realistic I am sensitive to the problem of creating brittle code.

If it is OK for the working group then I would like to revert back to
the previous version of the draft where we use the longer hash.

Ciao
Hannes


On 03/08/2016 02:19 AM, Sean Turner wrote:
> All,
> 
> The cached-info draft got all the way to the IESG and then we receive a
> couple of comments that require we bring the draft back to the WG to
> discuss.
> 
> spt
> 
>> Begin forwarded message:
>>
>> *From: *Karthikeyan Bhargavan <[e-mail]
>> <mailto:[e-mail]>>
>> *Subject: **Re: Cached Info*
>> *Date: *February 23, 2016 at 12:34:31 GMT+9
>> *To: *Sean Turner <[e-mail] <mailto:[e-mail]>>, Eric
>> Rescorla <[e-mail] <mailto:[e-mail]>>, Martin Thomson
>> <[e-mail] <mailto:[e-mail]>>, "Stephen
>> ie>" <[e-mail] <mailto:[e-mail]>>
>> *Cc: *Antoine Delignat-Lavaud <[e-mail]
>> <mailto:[e-mail]>>
>>
>> Some corrections:
>>
>> Dear All,
>>
>> I took a quick look at cached-info at Ekr’ prodding, who was worried
>> about key synchronization-style attacks (Ekr’s original email is a the
>> bottom of this email.)
>> My conclusion is that the use of a 4-byte hash is unnecessarily fragile.
>> The attacks are not super-serious, but the following scenario looks bad.
>> Maybe I got something wrong about the spec, so do tell me if I did.
>>
>> Suppose that the client uses client certificates (or channelID/token
>> binding) to login to all websites.
>> The client’s authentication credential is bound to the current
>> handshake transcript.
>> If the transcript does not contain the server certificate, then a
>> malicious server may be able
>> to forward a credential sent by the client to the malicious server to
>> a different server.
>> This kind of credential forwarding attack enables certain kinds of
>> impersonation (see Triple Handshake)
>>
>> In Cached-Info, the transcript includes a 32-bit hash of the
>> certificate and some signature or RSA encryption that uses the
>> certificate signing/encryption key.
>> To mount the attack described above, the attacker would first need to
>> find a certificate that collides with the honest server certificate hash.
>> You can imagine the attacker generating 2^32 self-signed certificates
>> until the collision is found, this is not hard.
>> Next, the attacker still has to match the parts of the transcript that
>> use the server’s public key (if any).
>> The client could maybe choose the public key to match that of the
>> server, or carefully choose the RSA signing key to create a signature
>> value that matches that of the real server etc.
>> There may be other attacks where the attacker uses a static ECDH
>> ciphersuite, and so does not need to sign anything.
>>
>> So now, the honest client C connects to malicious server M that has a
>> self-signed cert (for M).
>> C accepts the cert (for M) and agrees to use certificate/token-bound
>> authentication at M.
>> M can then forward the credential and signature to S, which will
>> accept it.
>> M would not control the keys between M and S (since it used S’s public
>> key.)
>> But if C is using a browser, then C’s window is at M’s origin, so M
>> can inject 
>> data into the connection which will then be forwarded to S, as if the
>> authenticated user C intended to send it to M.
>>
>> Perhaps the above attack is not very worrisome to some people, but the
>> silly
>> bit is that accepting this risk is completely unnecessary. The client and 
>> server could simply use the full SHA-256 hash for the certificate and the
>> client would have a hard time creating a colliding certificate.
>>
>> Best,
>> Karthik
> 
> 
>> —————
>> Ekr’s original email
>> ————————
>>
>> Folks,
>>
>> I've been thinking over the cached-info draft, and I'm not convinced
>> that the security analysis is right.
>>
>> In the current design, the client sends a truncated 32-bit hash
>> of what it believes the server's certificate is. If that matches
>> the server's certificate, then the server echoes that truncated
>> hash (if I'm reading it correctly).
>>
>> The security considerations section claims:
>>
>>    The use of the cached info extension allows the server to send
>>    significantly smaller TLS messages.  Consequently, these omitted
>>    parts of the messages are not included in the transcript of the
>>    handshake in the TLS Finish message.  However, since the client and
>>    the server communicate the hash values of the cached data in the
>>    initial handshake messages the fingerprints are included in the TLS
>>    Finish message.
>>
>> But this isn't correct with a short hash, since you're not strongly
>> binding the hash into the handshake. And elsewhere the text claims
>> that the hash isn't relevant:
>>
>>    If an attacker
>>    injects an incorrect fingerprint then two outcomes are possible: (1)
>>    The fingerprint does not relate to any cached state and the server
>>    has to fall back to a full exchange. (2) If the attacker manages to
>>    inject a fingerprint that refers to data the client has not cached
>>    then the exchange will fail later when the client continues with the
>>    handshake and aims to verify the digital signature.  The signature
>>    verification will fail since the public key cached by the client will
>>    not correspond to the private key that was used by server to sign the
>>    message.
>>
>> I think this is closer to the truth. But consider the case where
>> an attacker convinces the client to accept a certificate for
>> attacker.com <http://attacker.com/> but with victim.com
>> <http://victim.com/>'s public key that *also*
>> hash the same fingerprint as victim.com <http://victim.com/>'s
>> certificate. In that case,
>> you could end up with a UKS between the client and victim.com
>> <http://victim.com/>
>> (where the client thinks he's talking to attacker.com
>> <http://attacker.com/>). What prevents
>> this (I believe) is the text in Security Considerations:
>>
>>    Clients MUST ensure that they only cache information from legitimate
>>    sources.  For example, when the client populates the cache from a TLS
>>    exchange then it must only cache information after the successful
>>    completion of a TLS exchange to ensure that an attacker does not
>>    inject incorrect information into the cache.  Failure to do so allows
>>    for man-in-the-middle attacks.
>>
>> If followed, this will stop the client from accepting attacker.com
>> <http://attacker.com/>'s
>> bogus cert (because he doesn't have the private key). Note, however, that
>> you have to follow it strictly. For instance, if you cache after
>> False Start, then you are vulnerable to this attack. Also, these
>> instructions seem really counterintuitive, because naively you
>> would expect to just be able to validate the server's cert and
>> store the hash once it had been validated. I also note that this
>> advice was in the draft in -19 when the full hash was used.
>>
>> To be honest, I'm not entirely convinced that this advice is sufficient,
>> but I don't have a complete analysis either way. However, I do think it's
>> clear that the text in the draft is confusing.
>>
>> Thoughts?
>> -Ekr
>>
> 
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>