Never resume sessions on renegotiations.
This cuts down on one config knob as well as one case in the renego
combinatorial explosion. Since the only case we care about with renego
is the client auth hack, there's no reason to ever do resumption.
Especially since, no matter what's in the session cache:
- OpenSSL will only ever offer the session it just established,
whether or not a newer one with client auth was since established.
- Chrome will never cache sessions created on a renegotiation, so
such a session would never make it to the session cache.
- The new_session + SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION
logic had a bug where it would unconditionally never offer tickets
(but would advertise support) on renego, so any server doing renego
resumption against an OpenSSL-derived client must not support
This also gets rid of s->new_session which is now pointless.
Reviewed-by: Adam Langley <email@example.com>
diff --git a/ssl/test/runner/common.go b/ssl/test/runner/common.go
index 4ac7250..2e6ddf3 100644
@@ -681,9 +681,9 @@
// fragments in DTLS.
- // NeverResumeOnRenego, if true, causes renegotiations to always be full
- // handshakes.
- NeverResumeOnRenego bool
+ // FailIfResumeOnRenego, if true, causes renegotiations to fail if the
+ // client offers a resumption or the server accepts one.
+ FailIfResumeOnRenego bool
// NoSignatureAlgorithmsOnRenego, if true, causes renegotiations to omit
// the signature_algorithms extension.