tree 2897ba0b8e420425bcd4d1b76da4c000765edf3b
parent 785e07b23d965e1e984c2ee9f6a0dbe06d3d658e
author David Benjamin <davidben@chromium.org> 1431484972 -0400
committer Adam Langley <agl@google.com> 1431644001 +0000

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
  session tickets.

This also gets rid of s->new_session which is now pointless.

BUG=429450

Change-Id: I884bdcdc80bff45935b2c429b4bbc9c16b2288f8
Reviewed-on: https://boringssl-review.googlesource.com/4732
Reviewed-by: Adam Langley <agl@google.com>