[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] channel id and oob
From:       mrex () sap ! com (Martin Rex)
Date:       2013-10-22 0:28:36
Message-ID: 20131022002836.9CBCA1AA15 () ld9781 ! wdf ! sap ! corp
[Download RAW message or body]

Dirk Balfanz wrote:
> 
> When your TLS terminators resume a session with a client - what do those
> terminators tell their backends about the session? If the client proved
> possession of a private key/certificate during the original handshake, so
> terminators not tell their backends about that key on a resumed session?

Reverse Proxies will normally forward the authenticated client cert
PLUS any chain certificates that were received and successfully verified
during the full handshake to the backend.

Clients will normally also cache the Server certificate plus the entire
chain in the client side session cache.  Every reasonably portable and
generic TLS protocol implementation is likely going to include that
information in its SSL session cache.  Applications may not necesserily
know nor care whether the TLS handshake was a full handshake or
abbreviated handshake (aka session resume).


> 
> That's interesting. I was looking for the part in the TLS spec that says
> "thou shall make client certs part of the session state", and indeed
> couldn't find it. But in practice, of course that is what people are doing,
> right? If your TLS terminators didn't make a client cert part of the
> session state, how could you ever resume a session with them and still be
> considered authenticated with that client cert?

Session caching simply would not make any sense without caching
most of the attributes that were successfully established or successfully
negotiated during the full TLS handshake.  I do not see a difference
between the client caching the server's certificate chain and the
server caching the client's certificate chain.


> 
> Yeah, I'm a bit confused about this. I was a bit surprised to not find more
> explicit mention of what it means to resume a session in the TLS spec.

TLS is underspecified in a lot of places.  You may remember the result
of renegotiation being underspecified. A security problem that remained
unnoticed for ~13 years.


>
> Clearly, a resumed session (from the server's point of view) means "the guy
> on the other end knows the same master secret as I do". But in practice it
> also means "the guy on the other side wields the private key corresponding
> to this certain public key", if that's what was proven during the initial
> handshake.

Each peer only knows that the peer was able to perform a proof-of-posession
during the full TLS handshake.  It would be unwise to make any assumptions
about the posession of a private key for any point in time, much less any
later points in time, independent of whether the original TLS
connection has been running for a few hours, or whether this is about
a newly established TLS connection that has just been resumed from
the TLS session cache, with the original TLS handshake a few hours
in the past.

The certificate path validation (in particular when revocation checking
from remote information sources is performed) may be in the same ballpark
that the full handshake crypto operations, so typically, there is not
going to be a certificate path validation on session resume.


-Martin

[prev in list] [next in list] [prev in thread] [next in thread]