Martin Rex wrote: > Stephen Farrell wrote: > > > > On 28/09/16 01:17, Seth David Schoen wrote: > > > People with audit authority can then know all of the secrets, > > > > How well does that whole audit thing work in the financial services > > industry? (Sorry, couldn't resist:-) > > I am actually having serious doubts that it works at all. > > Consider a scenario that uses TLSv1.2 with static-RSA key exchange, > plain old session caching and Microsoft style renego-client-cert-auth > on a subset of the urlspace. > > (1) first TLS session, full handshake, request to public area. > > (2) TLS session resume, request to non-public area -> renego > > (3) TLS session resume for renego'ed session to non-public area. > > > To obtain the cleartext of session (3), you'll need the master secret > of the renego'ed session from (2), for which you'll first have to locate > and decrypt (2), for which you need the master secret from (1), so you'll > have to locate (1), and only at (1) you can start opening the encryption > with the longterm private RSA key of the server. > > It is impossible to open (3) directly, and the ClientKeyExchange > handshake message (and client&server randoms) that created the master secret > of session (3) is encrypted during renegotiation, so one can not > directly recover that with the longterm private RSA key of the server, > but has to open (2) first.
And it might even be more difficult than that. Because the Server Hello (with the server-issued new session_id) is encrypted during renegotiation, one can not see which renegotiation created the session that is resumed in (3), and may have to decrypt several renegotiation handshakes in order to find the correct one which created the session_id (3). -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
