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 <karthik.bharga...@gmail.com> > Subject: Re: Cached Info > Date: February 23, 2016 at 12:34:31 GMT+9 > To: Sean Turner <turn...@ieca.com>, Eric Rescorla <e...@rtfm.com>, Martin > Thomson <martin.thom...@gmail.com>, "Stephen ie>" <stephen.farr...@cs.tcd.ie> > Cc: Antoine Delignat-Lavaud <an...@microsoft.com> > > 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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
