Re: [TLS] cross-domain cache sharing and 0rtt

[Ilari Liusvaara <[e-mail]>]

On Tue, Jan 03, 2017 at 06:14:23PM -0600, Benjamin Kaduk wrote:
> On 12/30/2016 06:44 AM, Ilari Liusvaara wrote:
> > On Thu, Dec 29, 2016 at 02:45:53PM -0800, Adam Langley wrote:
> >>
> >> An attacker could redirect a 0-RTT handshake that was destined to S1
> >> and feed it to S2. If S2 ignores the SNI value (common) it could
> >> accept and process the 0-RTT data even though it was destined for S1.
> > Sounds like standard-issue default-vhost attack (which are sadly
> > common security issues in https://).
> >  
> 
> Somehow, I feel like adding text in the 1.3 spec that servers should not
> do this is not really going to help anyone.

I think it is much more HTTP-layer issue than TLS issue. After all, the
authoritative vhost info is available on HTTP layer. The TLS layer info
is not authoritative, especially in HTTP/2.

The last point is especially as coalescing information in HTTP/2 can
not be considered authenticatied (so attacker can trigger coalescing).

> >> However, in that case TLS 1.2 is probably also affected because S2
> >> would likely process a 1.2 handshake that was destined to S1 as well.
> >> (Even without a shared ticket key or session cache.) See
> >> http://antoine.delignat-lavaud.fr/doc/www15.pdf for more.
> > You mean redirecting full handshake meant for s1.example.com to
> > s2.example.com? Or redirecting a TLS 1.2 resumption handshake?
> 
> Naively, if s1 and s2 share cert and private key, and ignore the SNI, it
> seems like redirecting a full handshake would work.  But I didn't think
> about it very hard.

Actually, I think it would work if you merely have cross-valid 
selected certs. No need to share private key or even ignore SNI.

I'm aware of at least one TLS library that under no circumstances
ignores SNI for certificate selection (SNI with no known certificate
is always fatal error, and the returned certificate is always valid for
the name in SNI), but still can have redirect full handshakes if both
sides merely have a certificate that is valid for the other (no need
to share a key).



-Ilari