2014-06-20 20:00:00 +01:00
|
|
|
/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* This package is an SSL implementation written
|
|
|
|
* by Eric Young (eay@cryptsoft.com).
|
|
|
|
* The implementation was written so as to conform with Netscapes SSL.
|
|
|
|
*
|
|
|
|
* This library is free for commercial and non-commercial use as long as
|
|
|
|
* the following conditions are aheared to. The following conditions
|
|
|
|
* apply to all code found in this distribution, be it the RC4, RSA,
|
|
|
|
* lhash, DES, etc., code; not just the SSL code. The SSL documentation
|
|
|
|
* included with this distribution is covered by the same copyright terms
|
|
|
|
* except that the holder is Tim Hudson (tjh@cryptsoft.com).
|
|
|
|
*
|
|
|
|
* Copyright remains Eric Young's, and as such any Copyright notices in
|
|
|
|
* the code are not to be removed.
|
|
|
|
* If this package is used in a product, Eric Young should be given attribution
|
|
|
|
* as the author of the parts of the library used.
|
|
|
|
* This can be in the form of a textual message at program startup or
|
|
|
|
* in documentation (online or textual) provided with the package.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* 3. All advertising materials mentioning features or use of this software
|
|
|
|
* must display the following acknowledgement:
|
|
|
|
* "This product includes cryptographic software written by
|
|
|
|
* Eric Young (eay@cryptsoft.com)"
|
|
|
|
* The word 'cryptographic' can be left out if the rouines from the library
|
|
|
|
* being used are not cryptographic related :-).
|
|
|
|
* 4. If you include any Windows specific code (or a derivative thereof) from
|
|
|
|
* the apps directory (application code) you must include an acknowledgement:
|
|
|
|
* "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
|
|
|
|
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
|
|
|
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
|
|
|
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
|
|
|
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
|
|
|
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
|
|
|
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
|
|
|
* SUCH DAMAGE.
|
|
|
|
*
|
|
|
|
* The licence and distribution terms for any publically available version or
|
|
|
|
* derivative of this code cannot be changed. i.e. this code cannot simply be
|
|
|
|
* copied and put under another distribution licence
|
|
|
|
* [including the GNU Public Licence.]
|
|
|
|
*/
|
|
|
|
/* ====================================================================
|
|
|
|
* Copyright (c) 1998-2002 The OpenSSL Project. All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
*
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer.
|
|
|
|
*
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in
|
|
|
|
* the documentation and/or other materials provided with the
|
|
|
|
* distribution.
|
|
|
|
*
|
|
|
|
* 3. All advertising materials mentioning features or use of this
|
|
|
|
* software must display the following acknowledgment:
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
* for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
|
|
|
|
*
|
|
|
|
* 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
|
|
|
|
* endorse or promote products derived from this software without
|
|
|
|
* prior written permission. For written permission, please contact
|
|
|
|
* openssl-core@openssl.org.
|
|
|
|
*
|
|
|
|
* 5. Products derived from this software may not be called "OpenSSL"
|
|
|
|
* nor may "OpenSSL" appear in their names without prior written
|
|
|
|
* permission of the OpenSSL Project.
|
|
|
|
*
|
|
|
|
* 6. Redistributions of any form whatsoever must retain the following
|
|
|
|
* acknowledgment:
|
|
|
|
* "This product includes software developed by the OpenSSL Project
|
|
|
|
* for use in the OpenSSL Toolkit (http://www.openssl.org/)"
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
|
|
|
|
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
|
|
|
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
|
|
|
|
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
|
|
|
|
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
|
|
|
|
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
|
|
|
|
* OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
* ====================================================================
|
|
|
|
*
|
|
|
|
* This product includes cryptographic software written by Eric Young
|
|
|
|
* (eay@cryptsoft.com). This product includes software written by Tim
|
|
|
|
* Hudson (tjh@cryptsoft.com). */
|
|
|
|
/* ====================================================================
|
|
|
|
* Copyright 2002 Sun Microsystems, Inc. ALL RIGHTS RESERVED.
|
|
|
|
* ECC cipher suite support in OpenSSL originally developed by
|
|
|
|
* SUN MICROSYSTEMS, INC., and contributed to the OpenSSL project. */
|
|
|
|
|
2015-09-15 06:48:04 +01:00
|
|
|
#include <openssl/ssl.h>
|
|
|
|
|
2014-06-20 20:00:00 +01:00
|
|
|
#include <assert.h>
|
|
|
|
#include <limits.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
#include <openssl/buf.h>
|
2016-06-17 23:48:29 +01:00
|
|
|
#include <openssl/bytestring.h>
|
2015-04-08 04:05:04 +01:00
|
|
|
#include <openssl/err.h>
|
2014-06-20 20:00:00 +01:00
|
|
|
#include <openssl/evp.h>
|
|
|
|
#include <openssl/mem.h>
|
2014-08-26 05:32:30 +01:00
|
|
|
#include <openssl/md5.h>
|
2016-03-25 22:07:11 +00:00
|
|
|
#include <openssl/nid.h>
|
2014-06-20 20:00:00 +01:00
|
|
|
#include <openssl/rand.h>
|
2014-08-26 05:32:30 +01:00
|
|
|
#include <openssl/sha.h>
|
2014-06-20 20:00:00 +01:00
|
|
|
#include <openssl/x509.h>
|
|
|
|
|
2016-12-13 06:07:13 +00:00
|
|
|
#include "../crypto/internal.h"
|
2015-04-08 03:38:30 +01:00
|
|
|
#include "internal.h"
|
2014-06-20 20:00:00 +01:00
|
|
|
|
2014-12-16 02:42:07 +00:00
|
|
|
|
2016-11-14 01:45:16 +00:00
|
|
|
SSL_HANDSHAKE *ssl_handshake_new(SSL *ssl) {
|
2016-08-18 20:32:23 +01:00
|
|
|
SSL_HANDSHAKE *hs = OPENSSL_malloc(sizeof(SSL_HANDSHAKE));
|
|
|
|
if (hs == NULL) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_MALLOC_FAILURE);
|
|
|
|
return NULL;
|
|
|
|
}
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memset(hs, 0, sizeof(SSL_HANDSHAKE));
|
2016-11-14 01:45:16 +00:00
|
|
|
hs->ssl = ssl;
|
2016-08-18 20:32:23 +01:00
|
|
|
hs->wait = ssl_hs_ok;
|
2016-12-12 22:00:50 +00:00
|
|
|
hs->state = SSL_ST_INIT;
|
2017-01-12 18:17:07 +00:00
|
|
|
if (!SSL_TRANSCRIPT_init(&hs->transcript)) {
|
|
|
|
ssl_handshake_free(hs);
|
|
|
|
return NULL;
|
|
|
|
}
|
2016-08-18 20:32:23 +01:00
|
|
|
return hs;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ssl_handshake_free(SSL_HANDSHAKE *hs) {
|
|
|
|
if (hs == NULL) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
OPENSSL_cleanse(hs->secret, sizeof(hs->secret));
|
2016-12-16 16:29:28 +00:00
|
|
|
OPENSSL_cleanse(hs->client_handshake_secret,
|
|
|
|
sizeof(hs->client_handshake_secret));
|
|
|
|
OPENSSL_cleanse(hs->server_handshake_secret,
|
|
|
|
sizeof(hs->server_handshake_secret));
|
2016-10-03 17:25:56 +01:00
|
|
|
OPENSSL_cleanse(hs->client_traffic_secret_0,
|
|
|
|
sizeof(hs->client_traffic_secret_0));
|
|
|
|
OPENSSL_cleanse(hs->server_traffic_secret_0,
|
|
|
|
sizeof(hs->server_traffic_secret_0));
|
Only predict X25519 in TLS 1.3.
We'd previously been assuming we'd want to predict P-256 and X25519 but,
on reflection, that's nonsense. Although, today, P-256 is widespread and
X25519 is less so, that's not the right question to ask. Those servers
are all 1.2.
The right question is whether we believe enough servers will get to TLS
1.3 before X25519 to justify wasting 64 bytes on all other connections.
Given that OpenSSL has already shipped X25519 and Microsoft was doing
interop testing on X25519 around when we were shipping it, I think the
answer is no.
Moreover, if we are wrong, it will be easier to go from predicting one
group to two rather than the inverse (provided we send a fake one with
GREASE). I anticipate prediction-miss HelloRetryRequest logic across the
TLS/TCP ecosystem will be largely untested (no one wants to pay an RTT),
so taking a group out of the predicted set will likely be a risky
operation.
Only predicting one group also makes things a bit simpler. I haven't
done this here, but we'll be able to fold the 1.2 and 1.3 ecdh_ctx's
together, even.
Change-Id: Ie7e42d3105aca48eb9d97e2e05a16c5379aa66a3
Reviewed-on: https://boringssl-review.googlesource.com/10960
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
2016-09-09 04:47:48 +01:00
|
|
|
SSL_ECDH_CTX_cleanup(&hs->ecdh_ctx);
|
2017-01-12 18:17:07 +00:00
|
|
|
SSL_TRANSCRIPT_cleanup(&hs->transcript);
|
2016-10-08 02:10:38 +01:00
|
|
|
OPENSSL_free(hs->cookie);
|
2016-08-18 20:32:23 +01:00
|
|
|
OPENSSL_free(hs->key_share_bytes);
|
|
|
|
OPENSSL_free(hs->public_key);
|
2017-02-10 01:01:26 +00:00
|
|
|
SSL_SESSION_free(hs->new_session);
|
2016-08-17 20:29:46 +01:00
|
|
|
OPENSSL_free(hs->peer_sigalgs);
|
2016-10-07 05:41:50 +01:00
|
|
|
OPENSSL_free(hs->peer_supported_group_list);
|
2016-10-08 02:10:38 +01:00
|
|
|
OPENSSL_free(hs->peer_key);
|
|
|
|
OPENSSL_free(hs->server_params);
|
2016-09-17 00:34:02 +01:00
|
|
|
OPENSSL_free(hs->peer_psk_identity_hint);
|
2016-10-07 00:11:32 +01:00
|
|
|
sk_X509_NAME_pop_free(hs->ca_names, X509_NAME_free);
|
|
|
|
OPENSSL_free(hs->certificate_types);
|
2016-11-07 20:45:53 +00:00
|
|
|
|
|
|
|
if (hs->key_block != NULL) {
|
|
|
|
OPENSSL_cleanse(hs->key_block, hs->key_block_len);
|
|
|
|
OPENSSL_free(hs->key_block);
|
|
|
|
}
|
|
|
|
|
2016-11-16 08:08:23 +00:00
|
|
|
OPENSSL_free(hs->hostname);
|
2016-12-12 19:37:43 +00:00
|
|
|
EVP_PKEY_free(hs->peer_pubkey);
|
2016-08-18 20:32:23 +01:00
|
|
|
OPENSSL_free(hs);
|
|
|
|
}
|
|
|
|
|
2017-01-21 19:13:39 +00:00
|
|
|
int ssl_check_message_type(SSL *ssl, int type) {
|
|
|
|
if (ssl->s3->tmp.message_type != type) {
|
|
|
|
ssl3_send_alert(ssl, SSL3_AL_FATAL, SSL_AD_UNEXPECTED_MESSAGE);
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_UNEXPECTED_MESSAGE);
|
|
|
|
ERR_add_error_dataf("got type %d, wanted type %d",
|
|
|
|
ssl->s3->tmp.message_type, type);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
static int add_record_to_flight(SSL *ssl, uint8_t type, const uint8_t *in,
|
|
|
|
size_t in_len) {
|
|
|
|
/* We'll never add a flight while in the process of writing it out. */
|
|
|
|
assert(ssl->s3->pending_flight_offset == 0);
|
|
|
|
|
|
|
|
if (ssl->s3->pending_flight == NULL) {
|
|
|
|
ssl->s3->pending_flight = BUF_MEM_new();
|
|
|
|
if (ssl->s3->pending_flight == NULL) {
|
|
|
|
return 0;
|
|
|
|
}
|
2014-12-16 02:42:07 +00:00
|
|
|
}
|
|
|
|
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
size_t max_out = in_len + SSL_max_seal_overhead(ssl);
|
|
|
|
size_t new_cap = ssl->s3->pending_flight->length + max_out;
|
|
|
|
if (max_out < in_len || new_cap < max_out) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_OVERFLOW);
|
|
|
|
return 0;
|
|
|
|
}
|
2016-06-17 23:48:29 +01:00
|
|
|
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
size_t len;
|
|
|
|
if (!BUF_MEM_reserve(ssl->s3->pending_flight, new_cap) ||
|
|
|
|
!tls_seal_record(ssl, (uint8_t *)ssl->s3->pending_flight->data +
|
|
|
|
ssl->s3->pending_flight->length,
|
|
|
|
&len, max_out, type, in, in_len)) {
|
2016-06-17 23:48:29 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
ssl->s3->pending_flight->length += len;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ssl3_init_message(SSL *ssl, CBB *cbb, CBB *body, uint8_t type) {
|
2016-06-17 23:48:29 +01:00
|
|
|
/* Pick a modest size hint to save most of the |realloc| calls. */
|
|
|
|
if (!CBB_init(cbb, 64) ||
|
|
|
|
!CBB_add_u8(cbb, type) ||
|
|
|
|
!CBB_add_u24_length_prefixed(cbb, body)) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
CBB_cleanup(cbb);
|
2016-06-17 23:48:29 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-11-12 03:23:25 +00:00
|
|
|
int ssl3_finish_message(SSL *ssl, CBB *cbb, uint8_t **out_msg,
|
|
|
|
size_t *out_len) {
|
|
|
|
if (!CBB_finish(cbb, out_msg, out_len)) {
|
2016-06-17 23:48:29 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
|
|
|
return 0;
|
|
|
|
}
|
2016-11-12 05:26:19 +00:00
|
|
|
|
2016-11-12 03:23:25 +00:00
|
|
|
return 1;
|
|
|
|
}
|
2016-06-17 23:48:29 +01:00
|
|
|
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
int ssl3_add_message(SSL *ssl, uint8_t *msg, size_t len) {
|
|
|
|
/* Add the message to the current flight, splitting into several records if
|
|
|
|
* needed. */
|
|
|
|
int ret = 0;
|
|
|
|
size_t added = 0;
|
|
|
|
do {
|
|
|
|
size_t todo = len - added;
|
|
|
|
if (todo > ssl->max_send_fragment) {
|
|
|
|
todo = ssl->max_send_fragment;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!add_record_to_flight(ssl, SSL3_RT_HANDSHAKE, msg + added, todo)) {
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
added += todo;
|
|
|
|
} while (added < len);
|
|
|
|
|
|
|
|
ssl_do_msg_callback(ssl, 1 /* write */, SSL3_RT_HANDSHAKE, msg, len);
|
2017-01-12 18:17:07 +00:00
|
|
|
/* TODO(svaldez): Move this up a layer to fix abstraction for SSL_TRANSCRIPT
|
|
|
|
* on hs. */
|
|
|
|
if (ssl->s3->hs != NULL &&
|
|
|
|
!SSL_TRANSCRIPT_update(&ssl->s3->hs->transcript, msg, len)) {
|
|
|
|
goto err;
|
|
|
|
}
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
ret = 1;
|
|
|
|
|
|
|
|
err:
|
|
|
|
OPENSSL_free(msg);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ssl3_add_change_cipher_spec(SSL *ssl) {
|
|
|
|
static const uint8_t kChangeCipherSpec[1] = {SSL3_MT_CCS};
|
|
|
|
|
|
|
|
if (!add_record_to_flight(ssl, SSL3_RT_CHANGE_CIPHER_SPEC, kChangeCipherSpec,
|
|
|
|
sizeof(kChangeCipherSpec))) {
|
2016-06-17 23:48:29 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
ssl_do_msg_callback(ssl, 1 /* write */, SSL3_RT_CHANGE_CIPHER_SPEC,
|
|
|
|
kChangeCipherSpec, sizeof(kChangeCipherSpec));
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ssl3_add_alert(SSL *ssl, uint8_t level, uint8_t desc) {
|
|
|
|
uint8_t alert[2] = {level, desc};
|
|
|
|
if (!add_record_to_flight(ssl, SSL3_RT_ALERT, alert, sizeof(alert))) {
|
|
|
|
return 0;
|
|
|
|
}
|
2016-06-17 23:48:29 +01:00
|
|
|
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
ssl_do_msg_callback(ssl, 1 /* write */, SSL3_RT_ALERT, alert, sizeof(alert));
|
|
|
|
ssl_do_info_callback(ssl, SSL_CB_WRITE_ALERT, ((int)level << 8) | desc);
|
2016-06-17 23:48:29 +01:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
int ssl_add_message_cbb(SSL *ssl, CBB *cbb) {
|
2016-11-12 05:26:19 +00:00
|
|
|
uint8_t *msg;
|
2016-11-12 03:23:25 +00:00
|
|
|
size_t len;
|
|
|
|
if (!ssl->method->finish_message(ssl, cbb, &msg, &len) ||
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
!ssl->method->add_message(ssl, msg, len)) {
|
2016-11-12 03:23:25 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
int ssl3_flush_flight(SSL *ssl) {
|
|
|
|
if (ssl->s3->pending_flight == NULL) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ssl->s3->pending_flight->length > 0xffffffff ||
|
|
|
|
ssl->s3->pending_flight->length > INT_MAX) {
|
2016-06-17 23:48:29 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
return -1;
|
2016-06-17 23:48:29 +01:00
|
|
|
}
|
|
|
|
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
/* The handshake flight buffer is mutually exclusive with application data.
|
|
|
|
*
|
|
|
|
* TODO(davidben): This will not be true when closure alerts use this. */
|
|
|
|
if (ssl_write_buffer_is_pending(ssl)) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Write the pending flight. */
|
|
|
|
while (ssl->s3->pending_flight_offset < ssl->s3->pending_flight->length) {
|
|
|
|
int ret = BIO_write(
|
|
|
|
ssl->wbio,
|
|
|
|
ssl->s3->pending_flight->data + ssl->s3->pending_flight_offset,
|
|
|
|
ssl->s3->pending_flight->length - ssl->s3->pending_flight_offset);
|
|
|
|
if (ret <= 0) {
|
|
|
|
ssl->rwstate = SSL_WRITING;
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ssl->s3->pending_flight_offset += ret;
|
|
|
|
}
|
|
|
|
|
2017-01-27 15:06:07 +00:00
|
|
|
if (BIO_flush(ssl->wbio) <= 0) {
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
ssl->rwstate = SSL_WRITING;
|
2017-01-27 15:06:07 +00:00
|
|
|
return -1;
|
2016-06-17 23:48:29 +01:00
|
|
|
}
|
|
|
|
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
BUF_MEM_free(ssl->s3->pending_flight);
|
|
|
|
ssl->s3->pending_flight = NULL;
|
|
|
|
ssl->s3->pending_flight_offset = 0;
|
2016-06-07 20:06:39 +01:00
|
|
|
return 1;
|
2014-12-16 02:42:07 +00:00
|
|
|
}
|
|
|
|
|
2017-01-13 01:02:05 +00:00
|
|
|
int ssl3_send_finished(SSL_HANDSHAKE *hs) {
|
2016-11-14 01:32:04 +00:00
|
|
|
SSL *const ssl = hs->ssl;
|
2017-01-12 18:17:07 +00:00
|
|
|
const SSL_SESSION *session = SSL_get_session(ssl);
|
|
|
|
|
2016-10-08 16:56:01 +01:00
|
|
|
uint8_t finished[EVP_MAX_MD_SIZE];
|
2017-01-12 18:17:07 +00:00
|
|
|
size_t finished_len;
|
|
|
|
if (!SSL_TRANSCRIPT_finish_mac(&hs->transcript, finished, &finished_len,
|
|
|
|
session, ssl->server,
|
|
|
|
ssl3_protocol_version(ssl))) {
|
2016-06-17 23:48:29 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Log the master secret, if logging is enabled. */
|
2016-06-27 21:34:59 +01:00
|
|
|
if (!ssl_log_secret(ssl, "CLIENT_RANDOM",
|
2017-01-12 18:17:07 +00:00
|
|
|
session->master_key,
|
|
|
|
session->master_key_length)) {
|
2016-06-17 23:48:29 +01:00
|
|
|
return 0;
|
2014-12-16 02:42:07 +00:00
|
|
|
}
|
|
|
|
|
2016-10-08 17:05:03 +01:00
|
|
|
/* Copy the Finished so we can use it for renegotiation checks. */
|
|
|
|
if (ssl->version != SSL3_VERSION) {
|
|
|
|
if (finished_len > sizeof(ssl->s3->previous_client_finished) ||
|
|
|
|
finished_len > sizeof(ssl->s3->previous_server_finished)) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ssl->server) {
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memcpy(ssl->s3->previous_server_finished, finished, finished_len);
|
2016-10-08 17:05:03 +01:00
|
|
|
ssl->s3->previous_server_finished_len = finished_len;
|
|
|
|
} else {
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memcpy(ssl->s3->previous_client_finished, finished, finished_len);
|
2016-10-08 17:05:03 +01:00
|
|
|
ssl->s3->previous_client_finished_len = finished_len;
|
|
|
|
}
|
2016-06-17 23:48:29 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
CBB cbb, body;
|
|
|
|
if (!ssl->method->init_message(ssl, &cbb, &body, SSL3_MT_FINISHED) ||
|
2016-10-08 16:56:01 +01:00
|
|
|
!CBB_add_bytes(&body, finished, finished_len) ||
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
!ssl_add_message_cbb(ssl, &cbb)) {
|
2016-06-17 23:48:29 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
|
|
|
CBB_cleanup(&cbb);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2017-01-13 01:02:05 +00:00
|
|
|
return 1;
|
2014-12-16 02:42:07 +00:00
|
|
|
}
|
|
|
|
|
2016-11-14 01:32:04 +00:00
|
|
|
int ssl3_get_finished(SSL_HANDSHAKE *hs) {
|
|
|
|
SSL *const ssl = hs->ssl;
|
2017-01-21 19:49:39 +00:00
|
|
|
int ret = ssl->method->ssl_get_message(ssl);
|
2016-07-08 22:32:11 +01:00
|
|
|
if (ret <= 0) {
|
|
|
|
return ret;
|
2014-12-16 02:42:07 +00:00
|
|
|
}
|
|
|
|
|
2017-01-21 19:13:39 +00:00
|
|
|
if (!ssl_check_message_type(ssl, SSL3_MT_FINISHED)) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2014-12-16 02:42:07 +00:00
|
|
|
/* Snapshot the finished hash before incorporating the new message. */
|
2016-10-08 16:56:01 +01:00
|
|
|
uint8_t finished[EVP_MAX_MD_SIZE];
|
2017-01-12 18:17:07 +00:00
|
|
|
size_t finished_len;
|
|
|
|
if (!SSL_TRANSCRIPT_finish_mac(&hs->transcript, finished, &finished_len,
|
|
|
|
SSL_get_session(ssl), !ssl->server,
|
|
|
|
ssl3_protocol_version(ssl)) ||
|
|
|
|
!ssl_hash_current_message(hs)) {
|
2016-10-08 16:56:01 +01:00
|
|
|
return -1;
|
2015-02-17 00:33:53 +00:00
|
|
|
}
|
2014-12-16 02:42:07 +00:00
|
|
|
|
2016-09-09 16:41:18 +01:00
|
|
|
int finished_ok = ssl->init_num == finished_len &&
|
2016-10-08 16:56:01 +01:00
|
|
|
CRYPTO_memcmp(ssl->init_msg, finished, finished_len) == 0;
|
2016-03-02 03:57:40 +00:00
|
|
|
#if defined(BORINGSSL_UNSAFE_FUZZER_MODE)
|
2016-09-09 16:41:18 +01:00
|
|
|
finished_ok = 1;
|
2016-03-02 03:57:40 +00:00
|
|
|
#endif
|
2016-09-09 16:41:18 +01:00
|
|
|
if (!finished_ok) {
|
2016-10-08 16:56:01 +01:00
|
|
|
ssl3_send_alert(ssl, SSL3_AL_FATAL, SSL_AD_DECRYPT_ERROR);
|
2015-06-29 05:28:17 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_DIGEST_CHECK_FAILED);
|
2016-10-08 16:56:01 +01:00
|
|
|
return -1;
|
2014-12-16 02:42:07 +00:00
|
|
|
}
|
|
|
|
|
2016-10-08 17:05:03 +01:00
|
|
|
/* Copy the Finished so we can use it for renegotiation checks. */
|
|
|
|
if (ssl->version != SSL3_VERSION) {
|
|
|
|
if (finished_len > sizeof(ssl->s3->previous_client_finished) ||
|
|
|
|
finished_len > sizeof(ssl->s3->previous_server_finished)) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ssl->server) {
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memcpy(ssl->s3->previous_client_finished, finished, finished_len);
|
2016-10-08 17:05:03 +01:00
|
|
|
ssl->s3->previous_client_finished_len = finished_len;
|
|
|
|
} else {
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memcpy(ssl->s3->previous_server_finished, finished, finished_len);
|
2016-10-08 17:05:03 +01:00
|
|
|
ssl->s3->previous_server_finished_len = finished_len;
|
|
|
|
}
|
2014-12-16 02:42:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
2015-12-19 22:05:56 +00:00
|
|
|
int ssl3_output_cert_chain(SSL *ssl) {
|
2016-06-17 23:48:29 +01:00
|
|
|
CBB cbb, body;
|
|
|
|
if (!ssl->method->init_message(ssl, &cbb, &body, SSL3_MT_CERTIFICATE) ||
|
|
|
|
!ssl_add_cert_chain(ssl, &body) ||
|
Don't use the buffer BIO in TLS.
On the TLS side, we introduce a running buffer of ciphertext. Queuing up
pending data consists of encrypting the record into the buffer. This
effectively reimplements what the buffer BIO was doing previously, but
this resizes to fit the whole flight.
As part of this, rename all the functions to add to the pending flight
to be more uniform. This CL proposes "add_foo" to add to the pending
flight and "flush_flight" to drain it.
We add an add_alert hook for alerts but, for now, only the SSL 3.0
warning alert (sent mid-handshake) uses this mechanism. Later work will
push this down to the rest of the write path so closure alerts use it
too, as in DTLS. The intended end state is that all the ssl_buffer.c and
wpend_ret logic will only be used for application data and eventually
optionally replaced by the in-place API, while all "incidental" data
will be handled internally.
For now, the two buffers are mutually exclusive. Moving closure alerts
to "incidentals" will change this, but flushing application data early
is tricky due to wpend_ret. (If we call ssl_write_buffer_flush,
do_ssl3_write doesn't realize it still has a wpend_ret to replay.) That
too is all left alone in this change.
To keep the diff down, write_message is retained for now and will be
removed from the state machines in a follow-up change.
BUG=72
Change-Id: Ibce882f5f7196880648f25d5005322ca4055c71d
Reviewed-on: https://boringssl-review.googlesource.com/13224
Reviewed-by: Adam Langley <agl@google.com>
2017-01-03 23:37:41 +00:00
|
|
|
!ssl_add_message_cbb(ssl, &cbb)) {
|
2016-06-17 23:48:29 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
|
|
|
CBB_cleanup(&cbb);
|
2014-12-16 02:42:07 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-06-17 23:48:29 +01:00
|
|
|
return 1;
|
2014-12-16 02:42:07 +00:00
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
Simplify handshake message size limits.
A handshake message can go up to 2^24 bytes = 16MB which is a little large for
the peer to force us to buffer. Accordingly, we bound the size of a
handshake message.
Rather than have a global limit, the existing logic uses a different limit at
each state in the handshake state machine and, for certificates, allows
configuring the maximum certificate size. This is nice in that we engage larger
limits iff the relevant state is reachable from the handshake. Servers without
client auth get a tighter limit "for free".
However, this doesn't work for DTLS due to out-of-order messages and we use a
simpler scheme for DTLS. This scheme also is tricky on optional messages and
makes the handshake <-> message layer communication complex.
Apart from an ignored 20,000 byte limit on ServerHello, the largest
non-certificate limit is the common 16k limit on ClientHello. So this
complexity wasn't buying us anything. Unify everything on the DTLS scheme
except, so as not to regress bounds on client-auth-less servers, also correctly
check for whether client auth is configured. The value of 16k was chosen based
on this value.
(The 20,000 byte ServerHello limit makes no sense. We can easily bound the
ServerHello because servers may not send extensions we don't implement. But it
gets overshadowed by the certificate anyway.)
Change-Id: I00309b16d809a3c2a1543f99fd29c4163e3add81
Reviewed-on: https://boringssl-review.googlesource.com/7941
Reviewed-by: David Benjamin <davidben@google.com>
2016-05-12 05:43:05 +01:00
|
|
|
size_t ssl_max_handshake_message_len(const SSL *ssl) {
|
|
|
|
/* kMaxMessageLen is the default maximum message size for handshakes which do
|
|
|
|
* not accept peer certificate chains. */
|
|
|
|
static const size_t kMaxMessageLen = 16384;
|
|
|
|
|
2016-07-28 16:05:58 +01:00
|
|
|
if (SSL_in_init(ssl)) {
|
|
|
|
if ((!ssl->server || (ssl->verify_mode & SSL_VERIFY_PEER)) &&
|
|
|
|
kMaxMessageLen < ssl->max_cert_list) {
|
|
|
|
return ssl->max_cert_list;
|
|
|
|
}
|
|
|
|
return kMaxMessageLen;
|
Simplify handshake message size limits.
A handshake message can go up to 2^24 bytes = 16MB which is a little large for
the peer to force us to buffer. Accordingly, we bound the size of a
handshake message.
Rather than have a global limit, the existing logic uses a different limit at
each state in the handshake state machine and, for certificates, allows
configuring the maximum certificate size. This is nice in that we engage larger
limits iff the relevant state is reachable from the handshake. Servers without
client auth get a tighter limit "for free".
However, this doesn't work for DTLS due to out-of-order messages and we use a
simpler scheme for DTLS. This scheme also is tricky on optional messages and
makes the handshake <-> message layer communication complex.
Apart from an ignored 20,000 byte limit on ServerHello, the largest
non-certificate limit is the common 16k limit on ClientHello. So this
complexity wasn't buying us anything. Unify everything on the DTLS scheme
except, so as not to regress bounds on client-auth-less servers, also correctly
check for whether client auth is configured. The value of 16k was chosen based
on this value.
(The 20,000 byte ServerHello limit makes no sense. We can easily bound the
ServerHello because servers may not send extensions we don't implement. But it
gets overshadowed by the certificate anyway.)
Change-Id: I00309b16d809a3c2a1543f99fd29c4163e3add81
Reviewed-on: https://boringssl-review.googlesource.com/7941
Reviewed-by: David Benjamin <davidben@google.com>
2016-05-12 05:43:05 +01:00
|
|
|
}
|
2016-07-28 16:05:58 +01:00
|
|
|
|
|
|
|
if (ssl3_protocol_version(ssl) < TLS1_3_VERSION) {
|
|
|
|
/* In TLS 1.2 and below, the largest acceptable post-handshake message is
|
|
|
|
* a HelloRequest. */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ssl->server) {
|
|
|
|
/* The largest acceptable post-handshake message for a server is a
|
|
|
|
* KeyUpdate. We will never initiate post-handshake auth. */
|
2017-02-10 18:14:01 +00:00
|
|
|
return 1;
|
2016-07-28 16:05:58 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Clients must accept NewSessionTicket and CertificateRequest, so allow the
|
|
|
|
* default size. */
|
Simplify handshake message size limits.
A handshake message can go up to 2^24 bytes = 16MB which is a little large for
the peer to force us to buffer. Accordingly, we bound the size of a
handshake message.
Rather than have a global limit, the existing logic uses a different limit at
each state in the handshake state machine and, for certificates, allows
configuring the maximum certificate size. This is nice in that we engage larger
limits iff the relevant state is reachable from the handshake. Servers without
client auth get a tighter limit "for free".
However, this doesn't work for DTLS due to out-of-order messages and we use a
simpler scheme for DTLS. This scheme also is tricky on optional messages and
makes the handshake <-> message layer communication complex.
Apart from an ignored 20,000 byte limit on ServerHello, the largest
non-certificate limit is the common 16k limit on ClientHello. So this
complexity wasn't buying us anything. Unify everything on the DTLS scheme
except, so as not to regress bounds on client-auth-less servers, also correctly
check for whether client auth is configured. The value of 16k was chosen based
on this value.
(The 20,000 byte ServerHello limit makes no sense. We can easily bound the
ServerHello because servers may not send extensions we don't implement. But it
gets overshadowed by the certificate anyway.)
Change-Id: I00309b16d809a3c2a1543f99fd29c4163e3add81
Reviewed-on: https://boringssl-review.googlesource.com/7941
Reviewed-by: David Benjamin <davidben@google.com>
2016-05-12 05:43:05 +01:00
|
|
|
return kMaxMessageLen;
|
|
|
|
}
|
|
|
|
|
2016-05-13 23:12:19 +01:00
|
|
|
static int extend_handshake_buffer(SSL *ssl, size_t length) {
|
|
|
|
if (!BUF_MEM_reserve(ssl->init_buf, length)) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
while (ssl->init_buf->length < length) {
|
2016-07-28 16:05:58 +01:00
|
|
|
int ret = ssl3_read_handshake_bytes(
|
|
|
|
ssl, (uint8_t *)ssl->init_buf->data + ssl->init_buf->length,
|
|
|
|
length - ssl->init_buf->length);
|
2016-05-13 23:12:19 +01:00
|
|
|
if (ret <= 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
ssl->init_buf->length += (size_t)ret;
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2017-01-21 19:27:45 +00:00
|
|
|
static int read_v2_client_hello(SSL *ssl) {
|
2016-07-07 05:55:10 +01:00
|
|
|
/* Read the first 5 bytes, the size of the TLS record header. This is
|
|
|
|
* sufficient to detect a V2ClientHello and ensures that we never read beyond
|
|
|
|
* the first record. */
|
|
|
|
int ret = ssl_read_buffer_extend_to(ssl, SSL3_RT_HEADER_LENGTH);
|
|
|
|
if (ret <= 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
const uint8_t *p = ssl_read_buffer(ssl);
|
|
|
|
|
|
|
|
/* Some dedicated error codes for protocol mixups should the application wish
|
|
|
|
* to interpret them differently. (These do not overlap with ClientHello or
|
|
|
|
* V2ClientHello.) */
|
|
|
|
if (strncmp("GET ", (const char *)p, 4) == 0 ||
|
|
|
|
strncmp("POST ", (const char *)p, 5) == 0 ||
|
|
|
|
strncmp("HEAD ", (const char *)p, 5) == 0 ||
|
|
|
|
strncmp("PUT ", (const char *)p, 4) == 0) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_HTTP_REQUEST);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (strncmp("CONNE", (const char *)p, 5) == 0) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_HTTPS_PROXY_REQUEST);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((p[0] & 0x80) == 0 || p[2] != SSL2_MT_CLIENT_HELLO ||
|
|
|
|
p[3] != SSL3_VERSION_MAJOR) {
|
|
|
|
/* Not a V2ClientHello. */
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Determine the length of the V2ClientHello. */
|
|
|
|
size_t msg_length = ((p[0] & 0x7f) << 8) | p[1];
|
|
|
|
if (msg_length > (1024 * 4)) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_RECORD_TOO_LARGE);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (msg_length < SSL3_RT_HEADER_LENGTH - 2) {
|
|
|
|
/* Reject lengths that are too short early. We have already read
|
|
|
|
* |SSL3_RT_HEADER_LENGTH| bytes, so we should not attempt to process an
|
|
|
|
* (invalid) V2ClientHello which would be shorter than that. */
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_RECORD_LENGTH_MISMATCH);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read the remainder of the V2ClientHello. */
|
|
|
|
ret = ssl_read_buffer_extend_to(ssl, 2 + msg_length);
|
|
|
|
if (ret <= 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
CBS v2_client_hello;
|
|
|
|
CBS_init(&v2_client_hello, ssl_read_buffer(ssl) + 2, msg_length);
|
|
|
|
|
|
|
|
/* The V2ClientHello without the length is incorporated into the handshake
|
2017-01-12 18:17:07 +00:00
|
|
|
* hash. This is only ever called at the start of the handshake, so hs is
|
|
|
|
* guaranteed to be non-NULL. */
|
|
|
|
if (!SSL_TRANSCRIPT_update(&ssl->s3->hs->transcript,
|
|
|
|
CBS_data(&v2_client_hello),
|
|
|
|
CBS_len(&v2_client_hello))) {
|
2016-07-07 05:55:10 +01:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2016-09-20 01:15:07 +01:00
|
|
|
ssl_do_msg_callback(ssl, 0 /* read */, 0 /* V2ClientHello */,
|
2016-07-07 05:55:10 +01:00
|
|
|
CBS_data(&v2_client_hello), CBS_len(&v2_client_hello));
|
|
|
|
|
|
|
|
uint8_t msg_type;
|
|
|
|
uint16_t version, cipher_spec_length, session_id_length, challenge_length;
|
|
|
|
CBS cipher_specs, session_id, challenge;
|
|
|
|
if (!CBS_get_u8(&v2_client_hello, &msg_type) ||
|
|
|
|
!CBS_get_u16(&v2_client_hello, &version) ||
|
|
|
|
!CBS_get_u16(&v2_client_hello, &cipher_spec_length) ||
|
|
|
|
!CBS_get_u16(&v2_client_hello, &session_id_length) ||
|
|
|
|
!CBS_get_u16(&v2_client_hello, &challenge_length) ||
|
|
|
|
!CBS_get_bytes(&v2_client_hello, &cipher_specs, cipher_spec_length) ||
|
|
|
|
!CBS_get_bytes(&v2_client_hello, &session_id, session_id_length) ||
|
|
|
|
!CBS_get_bytes(&v2_client_hello, &challenge, challenge_length) ||
|
|
|
|
CBS_len(&v2_client_hello) != 0) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_DECODE_ERROR);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* msg_type has already been checked. */
|
|
|
|
assert(msg_type == SSL2_MT_CLIENT_HELLO);
|
|
|
|
|
|
|
|
/* The client_random is the V2ClientHello challenge. Truncate or
|
|
|
|
* left-pad with zeros as needed. */
|
|
|
|
size_t rand_len = CBS_len(&challenge);
|
|
|
|
if (rand_len > SSL3_RANDOM_SIZE) {
|
|
|
|
rand_len = SSL3_RANDOM_SIZE;
|
|
|
|
}
|
|
|
|
uint8_t random[SSL3_RANDOM_SIZE];
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memset(random, 0, SSL3_RANDOM_SIZE);
|
|
|
|
OPENSSL_memcpy(random + (SSL3_RANDOM_SIZE - rand_len), CBS_data(&challenge),
|
|
|
|
rand_len);
|
2016-07-07 05:55:10 +01:00
|
|
|
|
|
|
|
/* Write out an equivalent SSLv3 ClientHello. */
|
2016-07-27 19:01:59 +01:00
|
|
|
size_t max_v3_client_hello = SSL3_HM_HEADER_LENGTH + 2 /* version */ +
|
|
|
|
SSL3_RANDOM_SIZE + 1 /* session ID length */ +
|
|
|
|
2 /* cipher list length */ +
|
|
|
|
CBS_len(&cipher_specs) / 3 * 2 +
|
|
|
|
1 /* compression length */ + 1 /* compression */;
|
2016-07-07 05:55:10 +01:00
|
|
|
CBB client_hello, hello_body, cipher_suites;
|
2016-07-27 19:01:59 +01:00
|
|
|
CBB_zero(&client_hello);
|
|
|
|
if (!BUF_MEM_reserve(ssl->init_buf, max_v3_client_hello) ||
|
|
|
|
!CBB_init_fixed(&client_hello, (uint8_t *)ssl->init_buf->data,
|
2016-07-07 05:55:10 +01:00
|
|
|
ssl->init_buf->max) ||
|
|
|
|
!CBB_add_u8(&client_hello, SSL3_MT_CLIENT_HELLO) ||
|
|
|
|
!CBB_add_u24_length_prefixed(&client_hello, &hello_body) ||
|
|
|
|
!CBB_add_u16(&hello_body, version) ||
|
|
|
|
!CBB_add_bytes(&hello_body, random, SSL3_RANDOM_SIZE) ||
|
|
|
|
/* No session id. */
|
|
|
|
!CBB_add_u8(&hello_body, 0) ||
|
|
|
|
!CBB_add_u16_length_prefixed(&hello_body, &cipher_suites)) {
|
|
|
|
CBB_cleanup(&client_hello);
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_MALLOC_FAILURE);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Copy the cipher suites. */
|
|
|
|
while (CBS_len(&cipher_specs) > 0) {
|
|
|
|
uint32_t cipher_spec;
|
|
|
|
if (!CBS_get_u24(&cipher_specs, &cipher_spec)) {
|
|
|
|
CBB_cleanup(&client_hello);
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_DECODE_ERROR);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Skip SSLv2 ciphers. */
|
|
|
|
if ((cipher_spec & 0xff0000) != 0) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (!CBB_add_u16(&cipher_suites, cipher_spec)) {
|
|
|
|
CBB_cleanup(&client_hello);
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Add the null compression scheme and finish. */
|
|
|
|
if (!CBB_add_u8(&hello_body, 1) || !CBB_add_u8(&hello_body, 0) ||
|
|
|
|
!CBB_finish(&client_hello, NULL, &ssl->init_buf->length)) {
|
|
|
|
CBB_cleanup(&client_hello);
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Consume and discard the V2ClientHello. */
|
|
|
|
ssl_read_buffer_consume(ssl, 2 + msg_length);
|
|
|
|
ssl_read_buffer_discard(ssl);
|
2016-07-27 19:20:08 +01:00
|
|
|
|
2017-01-21 19:27:45 +00:00
|
|
|
ssl->s3->is_v2_hello = 1;
|
|
|
|
/* This is the first message, so hs must be non-NULL. */
|
|
|
|
ssl->s3->hs->v2_clienthello = 1;
|
2016-07-07 05:55:10 +01:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2017-01-21 19:49:39 +00:00
|
|
|
int ssl3_get_message(SSL *ssl) {
|
2016-07-27 19:01:59 +01:00
|
|
|
/* Re-create the handshake buffer if needed. */
|
|
|
|
if (ssl->init_buf == NULL) {
|
|
|
|
ssl->init_buf = BUF_MEM_new();
|
|
|
|
if (ssl->init_buf == NULL) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-07 05:55:10 +01:00
|
|
|
if (ssl->server && !ssl->s3->v2_hello_done) {
|
|
|
|
/* Bypass the record layer for the first message to handle V2ClientHello. */
|
2017-01-21 19:27:45 +00:00
|
|
|
int ret = read_v2_client_hello(ssl);
|
2016-07-07 05:55:10 +01:00
|
|
|
if (ret <= 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
ssl->s3->v2_hello_done = 1;
|
|
|
|
}
|
|
|
|
|
2015-12-19 22:05:56 +00:00
|
|
|
if (ssl->s3->tmp.reuse_message) {
|
2017-01-21 19:49:39 +00:00
|
|
|
/* There must be a current message. */
|
2016-07-27 19:20:08 +01:00
|
|
|
assert(ssl->init_msg != NULL);
|
2016-07-07 05:31:14 +01:00
|
|
|
ssl->s3->tmp.reuse_message = 0;
|
2016-07-27 22:51:49 +01:00
|
|
|
} else {
|
|
|
|
ssl3_release_current_message(ssl, 0 /* don't free buffer */);
|
2016-05-13 23:12:19 +01:00
|
|
|
}
|
2014-12-16 02:42:07 +00:00
|
|
|
|
2016-05-13 23:12:19 +01:00
|
|
|
/* Read the message header, if we haven't yet. */
|
2016-07-27 19:03:33 +01:00
|
|
|
int ret = extend_handshake_buffer(ssl, SSL3_HM_HEADER_LENGTH);
|
2016-05-13 23:12:19 +01:00
|
|
|
if (ret <= 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
2014-12-16 02:42:07 +00:00
|
|
|
|
2016-05-13 23:12:19 +01:00
|
|
|
/* Parse out the length. Cap it so the peer cannot force us to buffer up to
|
|
|
|
* 2^24 bytes. */
|
|
|
|
const uint8_t *p = (uint8_t *)ssl->init_buf->data;
|
|
|
|
size_t msg_len = (((uint32_t)p[1]) << 16) | (((uint32_t)p[2]) << 8) | p[3];
|
|
|
|
if (msg_len > ssl_max_handshake_message_len(ssl)) {
|
|
|
|
ssl3_send_alert(ssl, SSL3_AL_FATAL, SSL_AD_ILLEGAL_PARAMETER);
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_EXCESSIVE_MESSAGE_SIZE);
|
|
|
|
return -1;
|
|
|
|
}
|
2014-12-16 02:42:07 +00:00
|
|
|
|
2016-05-13 23:12:19 +01:00
|
|
|
/* Read the message body, if we haven't yet. */
|
2016-07-27 19:03:33 +01:00
|
|
|
ret = extend_handshake_buffer(ssl, SSL3_HM_HEADER_LENGTH + msg_len);
|
2016-05-13 23:12:19 +01:00
|
|
|
if (ret <= 0) {
|
|
|
|
return ret;
|
|
|
|
}
|
2014-12-16 02:46:16 +00:00
|
|
|
|
2016-05-13 23:12:19 +01:00
|
|
|
/* We have now received a complete message. */
|
2016-09-20 01:15:07 +01:00
|
|
|
ssl_do_msg_callback(ssl, 0 /* read */, SSL3_RT_HANDSHAKE, ssl->init_buf->data,
|
|
|
|
ssl->init_buf->length);
|
2014-12-16 02:42:07 +00:00
|
|
|
|
2016-07-24 06:59:10 +01:00
|
|
|
ssl->s3->tmp.message_type = ((const uint8_t *)ssl->init_buf->data)[0];
|
2016-07-27 19:03:33 +01:00
|
|
|
ssl->init_msg = (uint8_t*)ssl->init_buf->data + SSL3_HM_HEADER_LENGTH;
|
|
|
|
ssl->init_num = ssl->init_buf->length - SSL3_HM_HEADER_LENGTH;
|
2016-07-08 22:32:11 +01:00
|
|
|
return 1;
|
2014-12-16 02:42:07 +00:00
|
|
|
}
|
2014-06-20 20:00:00 +01:00
|
|
|
|
2016-11-14 08:12:11 +00:00
|
|
|
void ssl3_get_current_message(const SSL *ssl, CBS *out) {
|
|
|
|
CBS_init(out, (uint8_t *)ssl->init_buf->data, ssl->init_buf->length);
|
|
|
|
}
|
|
|
|
|
2017-01-12 18:17:07 +00:00
|
|
|
int ssl_hash_current_message(SSL_HANDSHAKE *hs) {
|
2017-01-21 19:27:45 +00:00
|
|
|
/* V2ClientHellos are hashed implicitly. */
|
2017-01-12 18:17:07 +00:00
|
|
|
if (hs->ssl->s3->is_v2_hello) {
|
2017-01-21 19:27:45 +00:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-11-14 08:12:11 +00:00
|
|
|
CBS cbs;
|
2017-01-12 18:17:07 +00:00
|
|
|
hs->ssl->method->get_current_message(hs->ssl, &cbs);
|
|
|
|
return SSL_TRANSCRIPT_update(&hs->transcript, CBS_data(&cbs), CBS_len(&cbs));
|
2014-12-16 02:42:07 +00:00
|
|
|
}
|
2014-08-26 02:34:56 +01:00
|
|
|
|
2016-07-27 22:51:49 +01:00
|
|
|
void ssl3_release_current_message(SSL *ssl, int free_buffer) {
|
|
|
|
if (ssl->init_msg != NULL) {
|
|
|
|
/* |init_buf| never contains data beyond the current message. */
|
|
|
|
assert(SSL3_HM_HEADER_LENGTH + ssl->init_num == ssl->init_buf->length);
|
|
|
|
|
|
|
|
/* Clear the current message. */
|
|
|
|
ssl->init_msg = NULL;
|
|
|
|
ssl->init_num = 0;
|
|
|
|
ssl->init_buf->length = 0;
|
2017-01-21 19:27:45 +00:00
|
|
|
ssl->s3->is_v2_hello = 0;
|
2016-07-27 22:51:49 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (free_buffer) {
|
|
|
|
BUF_MEM_free(ssl->init_buf);
|
|
|
|
ssl->init_buf = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-12-16 02:42:07 +00:00
|
|
|
int ssl_verify_alarm_type(long type) {
|
|
|
|
int al;
|
|
|
|
|
|
|
|
switch (type) {
|
|
|
|
case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT:
|
|
|
|
case X509_V_ERR_UNABLE_TO_GET_CRL:
|
|
|
|
case X509_V_ERR_UNABLE_TO_GET_CRL_ISSUER:
|
|
|
|
al = SSL_AD_UNKNOWN_CA;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case X509_V_ERR_UNABLE_TO_DECRYPT_CERT_SIGNATURE:
|
|
|
|
case X509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE:
|
|
|
|
case X509_V_ERR_UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY:
|
|
|
|
case X509_V_ERR_ERROR_IN_CERT_NOT_BEFORE_FIELD:
|
|
|
|
case X509_V_ERR_ERROR_IN_CERT_NOT_AFTER_FIELD:
|
|
|
|
case X509_V_ERR_ERROR_IN_CRL_LAST_UPDATE_FIELD:
|
|
|
|
case X509_V_ERR_ERROR_IN_CRL_NEXT_UPDATE_FIELD:
|
|
|
|
case X509_V_ERR_CERT_NOT_YET_VALID:
|
|
|
|
case X509_V_ERR_CRL_NOT_YET_VALID:
|
|
|
|
case X509_V_ERR_CERT_UNTRUSTED:
|
|
|
|
case X509_V_ERR_CERT_REJECTED:
|
2016-06-07 17:49:36 +01:00
|
|
|
case X509_V_ERR_HOSTNAME_MISMATCH:
|
|
|
|
case X509_V_ERR_EMAIL_MISMATCH:
|
|
|
|
case X509_V_ERR_IP_ADDRESS_MISMATCH:
|
2014-12-16 02:42:07 +00:00
|
|
|
al = SSL_AD_BAD_CERTIFICATE;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case X509_V_ERR_CERT_SIGNATURE_FAILURE:
|
|
|
|
case X509_V_ERR_CRL_SIGNATURE_FAILURE:
|
|
|
|
al = SSL_AD_DECRYPT_ERROR;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case X509_V_ERR_CERT_HAS_EXPIRED:
|
|
|
|
case X509_V_ERR_CRL_HAS_EXPIRED:
|
|
|
|
al = SSL_AD_CERTIFICATE_EXPIRED;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case X509_V_ERR_CERT_REVOKED:
|
|
|
|
al = SSL_AD_CERTIFICATE_REVOKED;
|
|
|
|
break;
|
|
|
|
|
2016-06-07 17:49:36 +01:00
|
|
|
case X509_V_ERR_UNSPECIFIED:
|
2014-12-16 02:42:07 +00:00
|
|
|
case X509_V_ERR_OUT_OF_MEM:
|
2016-06-07 17:49:36 +01:00
|
|
|
case X509_V_ERR_INVALID_CALL:
|
|
|
|
case X509_V_ERR_STORE_LOOKUP:
|
2014-12-16 02:42:07 +00:00
|
|
|
al = SSL_AD_INTERNAL_ERROR;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT:
|
|
|
|
case X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN:
|
|
|
|
case X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY:
|
|
|
|
case X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE:
|
|
|
|
case X509_V_ERR_CERT_CHAIN_TOO_LONG:
|
|
|
|
case X509_V_ERR_PATH_LENGTH_EXCEEDED:
|
|
|
|
case X509_V_ERR_INVALID_CA:
|
|
|
|
al = SSL_AD_UNKNOWN_CA;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case X509_V_ERR_APPLICATION_VERIFICATION:
|
|
|
|
al = SSL_AD_HANDSHAKE_FAILURE;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case X509_V_ERR_INVALID_PURPOSE:
|
|
|
|
al = SSL_AD_UNSUPPORTED_CERTIFICATE;
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
|
|
|
al = SSL_AD_CERTIFICATE_UNKNOWN;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return al;
|
|
|
|
}
|
2016-11-13 01:32:10 +00:00
|
|
|
|
|
|
|
int ssl_parse_extensions(const CBS *cbs, uint8_t *out_alert,
|
|
|
|
const SSL_EXTENSION_TYPE *ext_types,
|
2016-12-07 20:29:45 +00:00
|
|
|
size_t num_ext_types, int ignore_unknown) {
|
2016-11-13 01:32:10 +00:00
|
|
|
/* Reset everything. */
|
|
|
|
for (size_t i = 0; i < num_ext_types; i++) {
|
|
|
|
*ext_types[i].out_present = 0;
|
|
|
|
CBS_init(ext_types[i].out_data, NULL, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
CBS copy = *cbs;
|
|
|
|
while (CBS_len(©) != 0) {
|
|
|
|
uint16_t type;
|
|
|
|
CBS data;
|
|
|
|
if (!CBS_get_u16(©, &type) ||
|
|
|
|
!CBS_get_u16_length_prefixed(©, &data)) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_PARSE_TLSEXT);
|
|
|
|
*out_alert = SSL_AD_DECODE_ERROR;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
const SSL_EXTENSION_TYPE *ext_type = NULL;
|
|
|
|
for (size_t i = 0; i < num_ext_types; i++) {
|
|
|
|
if (type == ext_types[i].type) {
|
|
|
|
ext_type = &ext_types[i];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ext_type == NULL) {
|
2016-12-07 20:29:45 +00:00
|
|
|
if (ignore_unknown) {
|
|
|
|
continue;
|
|
|
|
}
|
2016-11-13 01:32:10 +00:00
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_UNEXPECTED_EXTENSION);
|
|
|
|
*out_alert = SSL_AD_UNSUPPORTED_EXTENSION;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Duplicate ext_types are forbidden. */
|
|
|
|
if (*ext_type->out_present) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_DUPLICATE_EXTENSION);
|
|
|
|
*out_alert = SSL_AD_ILLEGAL_PARAMETER;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
*ext_type->out_present = 1;
|
|
|
|
*ext_type->out_data = data;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|