kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Remove s->renegotiate check in SSL_clear.

Browse Source 
This dates back to upstream's a2a0158959e597188c10fbfeaf61888b2df2e587.
It seems to be a remnant of those SSL_clear calls in the handshake state
machine which... were also bizarre and since gone.

Since SSL_clear is to drop the current connection but retain the
configuration, it doesn't really make sense to forbid it while you're
mid-handshake.

This removes another consumer of s->renegotiate.

BUG=429450

Change-Id: Ifac6bf11644447fd5571262bed7421684739bc39
Reviewed-on: https://boringssl-review.googlesource.com/4823
Reviewed-by: Adam Langley <agl@google.com>
This commit is contained in:
David Benjamin 2015-05-15 22:05:42 -04:00 committed by Adam Langley
parent 20f6e97c7e
commit 5f387e38fc
1 changed files with 1 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
ssl/ssl_lib.c
View File

@ -181,11 +181,6 @@ int SSL_clear(SSL *ssl) {
ssl->hit = 0;
ssl->shutdown = 0;
if (ssl->renegotiate) {
OPENSSL_PUT_ERROR(SSL, SSL_clear, ERR_R_INTERNAL_ERROR);
return 0;
}
/* SSL_clear may be called before or after the |ssl| is initialized in either
* accept or connect state. In the latter case, SSL_clear should preserve the
* half and reset |ssl->state| accordingly. */
@ -199,7 +194,7 @@ int SSL_clear(SSL *ssl) {
assert(ssl->state == 0);
}
/* TODO(davidben): Some state on |s| is reset both in |SSL_new| and
/* TODO(davidben): Some state on |ssl| is reset both in |SSL_new| and
* |SSL_clear| because it is per-connection state rather than configuration
* state. Per-connection state should be on |ssl->s3| and |ssl->d1| so it is
* naturally reset at the right points between |SSL_new|, |SSL_clear|, and