4b27d9f8bd
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> |
||
|---|---|---|
| .. | ||
| runner | ||
| async_bio.cc | ||
| async_bio.h | ||
| bssl_shim.cc | ||
| CMakeLists.txt | ||
| malloc.cc | ||
| packeted_bio.cc | ||
| packeted_bio.h | ||
| scoped_types.h | ||
| test_config.cc | ||
| test_config.h | ||