Re: [TLS] Fwd: Cached Info

[Anirudh Ramachandran <[e-mail]>]

Since this is being discussed, I had an unrelated comment about the
following wording:

The draft says in Section 4:

   By returning the "cached_info" extension the server indicates that it
supports the
   cached info types.  For each indicated cached info type the server
   MUST alter the transmission of respective payloads, according to the
   rules outlined with each type

The 'MUST' is likely to indicate to the client that a match has been found,
which is useful. However, most SSL implementations (e.g,. OpenSSL) create
and process messages one state at a time. The same buffer is reused for
each handshake message, which means that only after the ServerHello message
is constructed and sent is the Certificate message be constructed. If one
were to follow the draft, there are two options – either hold back the
ServerHello until the Certificate message is constructed and hashed, or
early-construct the Certificate message while assembling the ServerHello.
Both options introduce complications in implementation because the draft is
asking to hash data from a later state during ServerHello.

An alternative might be to use the ServerHello cached_info extension merely
to indicate support of the extension, and indicate the cached info hit/miss
during the Certificate message. This can already be done implicitly — If
the Certificate message is of length exactly 4 bytes, the client looks up
its CachedInformation store using the tuple <servername, server-supplied
hash> to retrieve the correct cached Certificate message (a miss indicates
a protocol error). We believe this lookup is needed anyway since a client
might have multiple certificates stored per servername (e.g., both EC and
RSA certs) and will anyways need to a lookup to figure out which
Certificate should be picked.

Was this issue discussed, or perhaps my read of the draft is wrong?

Thanks,
Anirudh


On Wed, Mar 9, 2016 at 6:16 AM, Hannes Tschofenig <[e-mail]
> wrote:

> 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
> >
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>