mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-12-27 06:21:43 +08:00
Code Issues Packages Projects Releases Wiki Activity
eee2750bd3
openssl/ssl/record/ssl3_record.c

1850 lines
62 KiB
C
Raw Normal View History

Copyright consolidation 01/10 Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2016-05-18 02:18:30 +08:00
/*
* Copyright 1995-2016 The OpenSSL Project Authors. All Rights Reserved.
Encapsulate s->s3->rrec Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-01-31 01:29:41 +08:00
*
Copyright consolidation 01/10 Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2016-05-18 02:18:30 +08:00
* Licensed under the OpenSSL license (the "License"). You may not use
* this file except in compliance with the License. You can obtain a copy
* in the file LICENSE in the source distribution or at
* https://www.openssl.org/source/license.html
Encapsulate s->s3->rrec Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-01-31 01:29:41 +08:00
*/
Remove an OPENSSL_assert() and replace with a soft assert and check Following on from CVE-2017-3733, this removes the OPENSSL_assert() check that failed and replaces it with a soft assert, and an explicit check of value with an error return if it fails. Reviewed-by: Richard Levitte <levitte@openssl.org>
2017-02-03 22:45:49 +08:00
#include <assert.h>
Encapsulate s->s3->rrec Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-01-31 01:29:41 +08:00
#include "../ssl_locl.h"
Identify and move OpenSSL internal header files There are header files in crypto/ that are used by the rest of OpenSSL. Move those to include/internal and adapt the affected source code, Makefiles and scripts. The header files that got moved are: crypto/constant_time_locl.h crypto/o_dir.h crypto/o_str.h Reviewed-by: Matt Caswell <matt@openssl.org>
2015-05-14 20:54:49 +08:00
#include "internal/constant_time_locl.h"
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
#include <openssl/rand.h>
Renamed record layer header files Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-04 23:52:05 +08:00
#include "record_locl.h"
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
static const unsigned char ssl3_pad_1[48] = {
0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36,
0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36,
0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36,
0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36,
0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36,
0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36, 0x36
};
static const unsigned char ssl3_pad_2[48] = {
0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c,
0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c,
0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c,
0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c,
0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c,
0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c, 0x5c
};
Encapsulate s->s3->rrec Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-01-31 01:29:41 +08:00
Fix a memory leak in compression The function RECORD_LAYER_clear() is supposed to clear the contents of the RECORD_LAYER structure, but retain certain data such as buffers that are allocated. Unfortunately one buffer (for compression) got missed and was inadvertently being wiped, thus causing a memory leak. In part this is due to the fact that RECORD_LAYER_clear() was reaching inside SSL3_BUFFERs and SSL3_RECORDs, which it really shouldn't. So, I've rewritten it to only clear the data it knows about, and to defer clearing of SSL3_RECORD and SSL3_BUFFER structures to SSL_RECORD_clear() and the new function SSL3_BUFFER_clear(). Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-21 21:06:52 +08:00
/*
* Clear the contents of an SSL3_RECORD but retain any memory allocated
*/
Convert SSL3_RECORD_clear() and SSL3_RECORD_release() to size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 04:12:23 +08:00
void SSL3_RECORD_clear(SSL3_RECORD *r, size_t num_recs)
Encapsulate s->s3->rrec Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-01-31 01:29:41 +08:00
{
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
unsigned char *comp;
Convert SSL3_RECORD_clear() and SSL3_RECORD_release() to size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 04:12:23 +08:00
size_t i;
Fix a memory leak in compression The function RECORD_LAYER_clear() is supposed to clear the contents of the RECORD_LAYER structure, but retain certain data such as buffers that are allocated. Unfortunately one buffer (for compression) got missed and was inadvertently being wiped, thus causing a memory leak. In part this is due to the fact that RECORD_LAYER_clear() was reaching inside SSL3_BUFFERs and SSL3_RECORDs, which it really shouldn't. So, I've rewritten it to only clear the data it knows about, and to defer clearing of SSL3_RECORD and SSL3_BUFFER structures to SSL_RECORD_clear() and the new function SSL3_BUFFER_clear(). Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-05-21 21:06:52 +08:00
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
for (i = 0; i < num_recs; i++) {
comp = r[i].comp;
memset(&r[i], 0, sizeof(*r));
r[i].comp = comp;
}
Encapsulate s->s3->rrec Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-01-31 01:29:41 +08:00
}
Convert SSL3_RECORD_clear() and SSL3_RECORD_release() to size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 04:12:23 +08:00
void SSL3_RECORD_release(SSL3_RECORD *r, size_t num_recs)
Encapsulate s->s3->rrec Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-01-31 01:29:41 +08:00
{
Convert SSL3_RECORD_clear() and SSL3_RECORD_release() to size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 04:12:23 +08:00
size_t i;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
for (i = 0; i < num_recs; i++) {
OPENSSL_free(r[i].comp);
r[i].comp = NULL;
}
Encapsulate s->s3->rrec Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-01-31 01:29:41 +08:00
}
void SSL3_RECORD_set_seq_num(SSL3_RECORD *r, const unsigned char *seq_num)
{
Define SEQ_NUM_SIZE Replace the hard coded value 8 (the size of the sequence number) with a constant defined in a macro. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-03-26 21:12:24 +08:00
memcpy(r->seq_num, seq_num, SEQ_NUM_SIZE);
Encapsulate s->s3->rrec Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-01-31 01:29:41 +08:00
}
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/*
* Peeks ahead into "read_ahead" data to see if we have a whole record waiting
* for us in the buffer.
*/
Rename a function Rename the have_whole_app_data_record_waiting() function to include the ssl3_record prefix...and make it a bit shorter. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:11:42 +08:00
static int ssl3_record_app_data_waiting(SSL *s)
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
{
SSL3_BUFFER *rbuf;
Convert record layer to use size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 16:24:19 +08:00
size_t left, len;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
unsigned char *p;
rbuf = RECORD_LAYER_get_rbuf(&s->rlayer);
p = SSL3_BUFFER_get_buf(rbuf);
if (p == NULL)
return 0;
left = SSL3_BUFFER_get_left(rbuf);
if (left < SSL3_RT_HEADER_LENGTH)
return 0;
p += SSL3_BUFFER_get_offset(rbuf);
/*
* We only check the type and record length, we will sanity check version
* etc later
*/
if (*p != SSL3_RT_APPLICATION_DATA)
return 0;
p += 3;
n2s(p, len);
if (left < SSL3_RT_HEADER_LENGTH + len)
return 0;
return 1;
}
Skip early_data if appropriate after a HelloRetryRequest Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-24 19:40:49 +08:00
int early_data_count_ok(SSL *s, size_t length, size_t overhead, int *al)
Check max_early_data against the amount of early data we actually receive Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-23 22:29:36 +08:00
{
uint32_t max_early_data = s->max_early_data;
/*
Don't attempt to write more early_data than we know the server will accept Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-24 21:51:04 +08:00
* If we are a client then we always use the max_early_data from the
* session. Otherwise we go with the lowest out of the max early data set in
* the session and the configured max_early_data.
Check max_early_data against the amount of early data we actually receive Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-23 22:29:36 +08:00
*/
Don't attempt to write more early_data than we know the server will accept Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-24 21:51:04 +08:00
if (!s->server || (s->hit
&& s->session->ext.max_early_data < s->max_early_data))
Skip early_data if appropriate after a HelloRetryRequest Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-24 19:40:49 +08:00
max_early_data = s->session->ext.max_early_data;
Check max_early_data against the amount of early data we actually receive Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-23 22:29:36 +08:00
if (max_early_data == 0) {
Don't attempt to write more early_data than we know the server will accept Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-24 21:51:04 +08:00
if (al != NULL)
*al = SSL_AD_UNEXPECTED_MESSAGE;
Check max_early_data against the amount of early data we actually receive Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-23 22:29:36 +08:00
SSLerr(SSL_F_EARLY_DATA_COUNT_OK, SSL_R_TOO_MUCH_EARLY_DATA);
return 0;
}
/* If we are dealing with ciphertext we need to allow for the overhead */
max_early_data += overhead;
Don't attempt to write more early_data than we know the server will accept Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-24 21:51:04 +08:00
if (s->early_data_count + length > max_early_data) {
if (al != NULL)
*al = SSL_AD_UNEXPECTED_MESSAGE;
Check max_early_data against the amount of early data we actually receive Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-23 22:29:36 +08:00
SSLerr(SSL_F_EARLY_DATA_COUNT_OK, SSL_R_TOO_MUCH_EARLY_DATA);
return 0;
}
Don't attempt to write more early_data than we know the server will accept Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-24 21:51:04 +08:00
s->early_data_count += length;
Check max_early_data against the amount of early data we actually receive Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-23 22:29:36 +08:00
return 1;
}
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/*
* MAX_EMPTY_RECORDS defines the number of consecutive, empty records that
* will be processed per call to ssl3_get_record. Without this limit an
* attacker could send empty records at a faster rate than we can process and
* cause ssl3_get_record to loop forever.
*/
#define MAX_EMPTY_RECORDS 32
Server side version negotiation rewrite This commit changes the way that we do server side protocol version negotiation. Previously we had a whole set of code that had an "up front" state machine dedicated to the negotiating the protocol version. This adds significant complexity to the state machine. Historically the justification for doing this was the support of SSLv2 which works quite differently to SSLv3+. However, we have now removed support for SSLv2 so there is little reason to maintain this complexity. The one slight difficulty is that, although we no longer support SSLv2, we do still support an SSLv3+ ClientHello in an SSLv2 backward compatible ClientHello format. This is generally only used by legacy clients. This commit adds support within the SSLv3 code for these legacy format ClientHellos. Server side version negotiation now works in much the same was as DTLS, i.e. we introduce the concept of TLS_ANY_VERSION. If s->version is set to that then when a ClientHello is received it will work out the most appropriate version to respond with. Also, SSLv23_method and SSLv23_server_method have been replaced with TLS_method and TLS_server_method respectively. The old SSLv23* names still exist as macros pointing at the new name, although they are deprecated. Subsequent commits will look at client side version negotiation, as well of removal of the old s23* code. Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2015-03-28 07:01:51 +08:00
#define SSL2_RT_HEADER_LENGTH 2
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/*-
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
* Call this to get new input records.
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
* It will return <= 0 if more data is needed, normally due to an error
* or non-blocking IO.
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
* When it finishes, |numrpipes| records have been decoded. For each record 'i':
* rr[i].type - is the type of record
* rr[i].data, - data
* rr[i].length, - number of bytes
* Multiple records will only be returned if the record types are all
* SSL3_RT_APPLICATION_DATA. The number of records returned will always be <=
* |max_pipelines|
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
*/
/* used only by ssl3_read_bytes */
int ssl3_get_record(SSL *s)
{
Convert TLS Record receipt to use PACKET Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 01:06:14 +08:00
int al;
Convert record layer to use size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 16:24:19 +08:00
int enc_err, rret, ret = -1;
int i;
size_t more, n;
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
SSL3_RECORD *rr, *thisrr;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
SSL3_BUFFER *rbuf;
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
SSL_SESSION *sess;
unsigned char *p;
unsigned char md[EVP_MAX_MD_SIZE];
Convert TLS Record receipt to use PACKET Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 01:06:14 +08:00
unsigned int version;
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
size_t mac_size;
int imac_size;
size_t num_recs = 0, max_recs, j;
Convert TLS Record receipt to use PACKET Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 01:06:14 +08:00
PACKET pkt, sslv2pkt;
Check max_early_data against the amount of early data we actually receive Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-23 22:29:36 +08:00
size_t first_rec_len;
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
rr = RECORD_LAYER_get_rrec(&s->rlayer);
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
rbuf = RECORD_LAYER_get_rbuf(&s->rlayer);
max_recs = s->max_pipelines;
if (max_recs == 0)
max_recs = 1;
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
sess = s->session;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
do {
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr = &rr[num_recs];
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/* check if we have the header */
if ((RECORD_LAYER_get_rstate(&s->rlayer) != SSL_ST_READ_BODY) ||
(RECORD_LAYER_get_packet_length(&s->rlayer)
< SSL3_RT_HEADER_LENGTH)) {
Convert TLS Record receipt to use PACKET Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 01:06:14 +08:00
size_t sslv2len;
unsigned int type;
Convert record layer to use size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 16:24:19 +08:00
rret = ssl3_read_n(s, SSL3_RT_HEADER_LENGTH,
SSL3_BUFFER_get_len(rbuf), 0,
num_recs == 0 ? 1 : 0, &n);
if (rret <= 0)
return rret; /* error or non-blocking */
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
RECORD_LAYER_set_rstate(&s->rlayer, SSL_ST_READ_BODY);
p = RECORD_LAYER_get_packet(&s->rlayer);
Convert TLS Record receipt to use PACKET Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 01:06:14 +08:00
if (!PACKET_buf_init(&pkt, RECORD_LAYER_get_packet(&s->rlayer),
RECORD_LAYER_get_packet_length(&s->rlayer))) {
al = SSL_AD_INTERNAL_ERROR;
SSLerr(SSL_F_SSL3_GET_RECORD, ERR_R_INTERNAL_ERROR);
goto f_err;
}
sslv2pkt = pkt;
if (!PACKET_get_net_2_len(&sslv2pkt, &sslv2len)
|| !PACKET_get_1(&sslv2pkt, &type)) {
al = SSL_AD_INTERNAL_ERROR;
SSLerr(SSL_F_SSL3_GET_RECORD, ERR_R_INTERNAL_ERROR);
goto f_err;
}
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/*
Address feedback on SSLv2 ClientHello processing Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-08-03 20:03:25 +08:00
* The first record received by the server may be a V2ClientHello.
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
*/
Address feedback on SSLv2 ClientHello processing Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-08-03 20:03:25 +08:00
if (s->server && RECORD_LAYER_is_first_record(&s->rlayer)
Convert TLS Record receipt to use PACKET Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 01:06:14 +08:00
&& (sslv2len & 0x8000) != 0
&& (type == SSL2_MT_CLIENT_HELLO)) {
Add a comment to explain the use of |num_recs| In the SSLV2ClientHello processing code in ssl3_get_record, the value of |num_recs| will always be 0. This isn't obvious from the code so a comment is added to explain it. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-05-17 22:27:09 +08:00
/*
* SSLv2 style record
*
* |num_recs| here will actually always be 0 because
* |num_recs > 0| only ever occurs when we are processing
* multiple app data records - which we know isn't the case here
* because it is an SSLv2ClientHello. We keep it using
* |num_recs| for the sake of consistency
*/
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr->type = SSL3_RT_HANDSHAKE;
thisrr->rec_version = SSL2_VERSION;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr->length = sslv2len & 0x7fff;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (thisrr->length > SSL3_BUFFER_get_len(rbuf)
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
- SSL2_RT_HEADER_LENGTH) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
al = SSL_AD_RECORD_OVERFLOW;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_PACKET_LENGTH_TOO_LONG);
goto f_err;
}
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (thisrr->length < MIN_SSL2_RECORD_LEN) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
al = SSL_AD_HANDSHAKE_FAILURE;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_LENGTH_TOO_SHORT);
goto f_err;
}
} else {
/* SSLv3+ style record */
Add a TLS1.3 TODO for the msg callback At the moment the msg callback only received the record header with the outer record type in it. We never pass the inner record type - we probably need to at some point. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-22 01:11:51 +08:00
/*
* TODO(TLS1.3): This callback only provides the "outer" record
* type to the callback. Somehow we need to pass the "inner"
* record type
*/
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
if (s->msg_callback)
s->msg_callback(0, 0, SSL3_RT_HEADER, p, 5, s,
s->msg_callback_arg);
/* Pull apart the header into the SSL3_RECORD */
Convert TLS Record receipt to use PACKET Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 01:06:14 +08:00
if (!PACKET_get_1(&pkt, &type)
|| !PACKET_get_net_2(&pkt, &version)
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
|| !PACKET_get_net_2_len(&pkt, &thisrr->length)) {
Convert TLS Record receipt to use PACKET Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 01:06:14 +08:00
al = SSL_AD_INTERNAL_ERROR;
SSLerr(SSL_F_SSL3_GET_RECORD, ERR_R_INTERNAL_ERROR);
goto f_err;
}
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr->type = type;
thisrr->rec_version = version;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
Ignore the record version in TLS1.3 The record layer version field must be ignored in TLSv1.3, so we remove the check when using that version. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-07 21:49:18 +08:00
/* Lets check version. In TLSv1.3 we ignore this field */
Fix missing SSL_IS_TLS13(s) usage We should use the macro for testing if we are using TLSv1.3 rather than checking s->version directly. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-16 18:22:38 +08:00
if (!s->first_packet && !SSL_IS_TLS13(s)
Convert TLS Record receipt to use PACKET Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 01:06:14 +08:00
&& version != (unsigned int)s->version) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_WRONG_VERSION_NUMBER);
if ((s->version & 0xFF00) == (version & 0xFF00)
&& !s->enc_write_ctx && !s->write_hash) {
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (thisrr->type == SSL3_RT_ALERT) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/*
* The record is using an incorrect version number,
* but what we've got appears to be an alert. We
* haven't read the body yet to check whether its a
* fatal or not - but chances are it is. We probably
* shouldn't send a fatal alert back. We'll just
* end.
*/
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
goto err;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
}
Don't send an alert if we've just received one If the record received is for a version that we don't support, previously we were sending an alert back. However if the incoming record already looks like an alert then probably we shouldn't do that. So suppress an outgoing alert if it looks like we've got one incoming. Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2015-05-24 04:32:12 +08:00
/*
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
* Send back error using their minor version number :-)
Don't send an alert if we've just received one If the record received is for a version that we don't support, previously we were sending an alert back. However if the incoming record already looks like an alert then probably we shouldn't do that. So suppress an outgoing alert if it looks like we've got one incoming. Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2015-05-24 04:32:12 +08:00
*/
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
s->version = (unsigned short)version;
Don't send an alert if we've just received one If the record received is for a version that we don't support, previously we were sending an alert back. However if the incoming record already looks like an alert then probably we shouldn't do that. So suppress an outgoing alert if it looks like we've got one incoming. Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2015-05-24 04:32:12 +08:00
}
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
al = SSL_AD_PROTOCOL_VERSION;
goto f_err;
Don't send an alert if we've just received one If the record received is for a version that we don't support, previously we were sending an alert back. However if the incoming record already looks like an alert then probably we shouldn't do that. So suppress an outgoing alert if it looks like we've got one incoming. Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2015-05-24 04:32:12 +08:00
}
Server side version negotiation rewrite This commit changes the way that we do server side protocol version negotiation. Previously we had a whole set of code that had an "up front" state machine dedicated to the negotiating the protocol version. This adds significant complexity to the state machine. Historically the justification for doing this was the support of SSLv2 which works quite differently to SSLv3+. However, we have now removed support for SSLv2 so there is little reason to maintain this complexity. The one slight difficulty is that, although we no longer support SSLv2, we do still support an SSLv3+ ClientHello in an SSLv2 backward compatible ClientHello format. This is generally only used by legacy clients. This commit adds support within the SSLv3 code for these legacy format ClientHellos. Server side version negotiation now works in much the same was as DTLS, i.e. we introduce the concept of TLS_ANY_VERSION. If s->version is set to that then when a ClientHello is received it will work out the most appropriate version to respond with. Also, SSLv23_method and SSLv23_server_method have been replaced with TLS_method and TLS_server_method respectively. The old SSLv23* names still exist as macros pointing at the new name, although they are deprecated. Subsequent commits will look at client side version negotiation, as well of removal of the old s23* code. Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2015-03-28 07:01:51 +08:00
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
if ((version >> 8) != SSL3_VERSION_MAJOR) {
Send an alert if we get a non-initial record with the wrong version If we receive a non-initial record but the version number isn't right then we should send an alert. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-08-03 00:43:32 +08:00
if (RECORD_LAYER_is_first_record(&s->rlayer)) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/* Go back to start of packet, look at the five bytes
* that we have. */
p = RECORD_LAYER_get_packet(&s->rlayer);
if (strncmp((char *)p, "GET ", 4) == 0 ||
strncmp((char *)p, "POST ", 5) == 0 ||
strncmp((char *)p, "HEAD ", 5) == 0 ||
strncmp((char *)p, "PUT ", 4) == 0) {
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_HTTP_REQUEST);
goto err;
} else if (strncmp((char *)p, "CONNE", 5) == 0) {
SSLerr(SSL_F_SSL3_GET_RECORD,
SSL_R_HTTPS_PROXY_REQUEST);
goto err;
}
Send an alert if we get a non-initial record with the wrong version If we receive a non-initial record but the version number isn't right then we should send an alert. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-08-03 00:43:32 +08:00
/* Doesn't look like TLS - don't send an alert */
SSLerr(SSL_F_SSL3_GET_RECORD,
SSL_R_WRONG_VERSION_NUMBER);
goto err;
} else {
SSLerr(SSL_F_SSL3_GET_RECORD,
SSL_R_WRONG_VERSION_NUMBER);
al = SSL_AD_PROTOCOL_VERSION;
goto f_err;
RT4304: Look for plaintext HTTP Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-13 21:03:23 +08:00
}
}
Server side version negotiation rewrite This commit changes the way that we do server side protocol version negotiation. Previously we had a whole set of code that had an "up front" state machine dedicated to the negotiating the protocol version. This adds significant complexity to the state machine. Historically the justification for doing this was the support of SSLv2 which works quite differently to SSLv3+. However, we have now removed support for SSLv2 so there is little reason to maintain this complexity. The one slight difficulty is that, although we no longer support SSLv2, we do still support an SSLv3+ ClientHello in an SSLv2 backward compatible ClientHello format. This is generally only used by legacy clients. This commit adds support within the SSLv3 code for these legacy format ClientHellos. Server side version negotiation now works in much the same was as DTLS, i.e. we introduce the concept of TLS_ANY_VERSION. If s->version is set to that then when a ClientHello is received it will work out the most appropriate version to respond with. Also, SSLv23_method and SSLv23_server_method have been replaced with TLS_method and TLS_server_method respectively. The old SSLv23* names still exist as macros pointing at the new name, although they are deprecated. Subsequent commits will look at client side version negotiation, as well of removal of the old s23* code. Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2015-03-28 07:01:51 +08:00
Update the record layer to use TLSv1.3 style record construction Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 07:44:09 +08:00
if (SSL_IS_TLS13(s) && s->enc_read_ctx != NULL
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
&& thisrr->type != SSL3_RT_APPLICATION_DATA) {
Update the record layer to use TLSv1.3 style record construction Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 07:44:09 +08:00
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_BAD_RECORD_TYPE);
al = SSL_AD_UNEXPECTED_MESSAGE;
goto f_err;
}
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (thisrr->length >
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
SSL3_BUFFER_get_len(rbuf) - SSL3_RT_HEADER_LENGTH) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
al = SSL_AD_RECORD_OVERFLOW;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_PACKET_LENGTH_TOO_LONG);
goto f_err;
}
Server side version negotiation rewrite This commit changes the way that we do server side protocol version negotiation. Previously we had a whole set of code that had an "up front" state machine dedicated to the negotiating the protocol version. This adds significant complexity to the state machine. Historically the justification for doing this was the support of SSLv2 which works quite differently to SSLv3+. However, we have now removed support for SSLv2 so there is little reason to maintain this complexity. The one slight difficulty is that, although we no longer support SSLv2, we do still support an SSLv3+ ClientHello in an SSLv2 backward compatible ClientHello format. This is generally only used by legacy clients. This commit adds support within the SSLv3 code for these legacy format ClientHellos. Server side version negotiation now works in much the same was as DTLS, i.e. we introduce the concept of TLS_ANY_VERSION. If s->version is set to that then when a ClientHello is received it will work out the most appropriate version to respond with. Also, SSLv23_method and SSLv23_server_method have been replaced with TLS_method and TLS_server_method respectively. The old SSLv23* names still exist as macros pointing at the new name, although they are deprecated. Subsequent commits will look at client side version negotiation, as well of removal of the old s23* code. Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2015-03-28 07:01:51 +08:00
}
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/* now s->rlayer.rstate == SSL_ST_READ_BODY */
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
}
Tweak the TLSv1.3 record overflow limits Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2861)
2017-03-06 23:13:25 +08:00
if (SSL_IS_TLS13(s)) {
if (thisrr->length > SSL3_RT_MAX_TLS13_ENCRYPTED_LENGTH) {
al = SSL_AD_RECORD_OVERFLOW;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_ENCRYPTED_LENGTH_TOO_LONG);
goto f_err;
}
} else {
size_t len = SSL3_RT_MAX_ENCRYPTED_LENGTH;
Fix no-comp The value of SSL3_RT_MAX_ENCRYPTED_LENGTH normally includes the compression overhead (even if no compression is negotiated for a connection). Except in a build where no-comp is used the value of SSL3_RT_MAX_ENCRYPTED_LENGTH does not include the compression overhead. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2872)
2017-03-07 17:58:27 +08:00
#ifndef OPENSSL_NO_COMP
/*
* If OPENSSL_NO_COMP is defined then SSL3_RT_MAX_ENCRYPTED_LENGTH
* does not include the compression overhead anyway.
*/
Tweak the TLSv1.3 record overflow limits Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2861)
2017-03-06 23:13:25 +08:00
if (s->expand == NULL)
len -= SSL3_RT_MAX_COMPRESSED_OVERHEAD;
Fix no-comp The value of SSL3_RT_MAX_ENCRYPTED_LENGTH normally includes the compression overhead (even if no compression is negotiated for a connection). Except in a build where no-comp is used the value of SSL3_RT_MAX_ENCRYPTED_LENGTH does not include the compression overhead. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2872)
2017-03-07 17:58:27 +08:00
#endif
Tweak the TLSv1.3 record overflow limits Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2861)
2017-03-06 23:13:25 +08:00
if (thisrr->length > len) {
al = SSL_AD_RECORD_OVERFLOW;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_ENCRYPTED_LENGTH_TOO_LONG);
goto f_err;
}
}
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/*
* s->rlayer.rstate == SSL_ST_READ_BODY, get and decode the data.
* Calculate how much more data we need to read for the rest of the
* record
*/
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (thisrr->rec_version == SSL2_VERSION) {
more = thisrr->length + SSL2_RT_HEADER_LENGTH
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
- SSL3_RT_HEADER_LENGTH;
} else {
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
more = thisrr->length;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
}
Convert record layer to use size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 16:24:19 +08:00
if (more > 0) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/* now s->packet_length == SSL3_RT_HEADER_LENGTH */
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
Convert record layer to use size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 16:24:19 +08:00
rret = ssl3_read_n(s, more, more, 1, 0, &n);
if (rret <= 0)
return rret; /* error or non-blocking io */
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
}
Server side version negotiation rewrite This commit changes the way that we do server side protocol version negotiation. Previously we had a whole set of code that had an "up front" state machine dedicated to the negotiating the protocol version. This adds significant complexity to the state machine. Historically the justification for doing this was the support of SSLv2 which works quite differently to SSLv3+. However, we have now removed support for SSLv2 so there is little reason to maintain this complexity. The one slight difficulty is that, although we no longer support SSLv2, we do still support an SSLv3+ ClientHello in an SSLv2 backward compatible ClientHello format. This is generally only used by legacy clients. This commit adds support within the SSLv3 code for these legacy format ClientHellos. Server side version negotiation now works in much the same was as DTLS, i.e. we introduce the concept of TLS_ANY_VERSION. If s->version is set to that then when a ClientHello is received it will work out the most appropriate version to respond with. Also, SSLv23_method and SSLv23_server_method have been replaced with TLS_method and TLS_server_method respectively. The old SSLv23* names still exist as macros pointing at the new name, although they are deprecated. Subsequent commits will look at client side version negotiation, as well of removal of the old s23* code. Reviewed-by: Kurt Roeckx <kurt@openssl.org>
2015-03-28 07:01:51 +08:00
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/* set state for later operations */
RECORD_LAYER_set_rstate(&s->rlayer, SSL_ST_READ_HEADER);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/*
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
* At this point, s->packet_length == SSL3_RT_HEADER_LENGTH
* + thisrr->length, or s->packet_length == SSL2_RT_HEADER_LENGTH
* + thisrr->length and we have that many bytes in s->packet
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
*/
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (thisrr->rec_version == SSL2_VERSION) {
thisrr->input =
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
&(RECORD_LAYER_get_packet(&s->rlayer)[SSL2_RT_HEADER_LENGTH]);
} else {
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr->input =
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
&(RECORD_LAYER_get_packet(&s->rlayer)[SSL3_RT_HEADER_LENGTH]);
}
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/*
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
* ok, we can now read from 's->packet' data into 'thisrr' thisrr->input
* points at thisrr->length bytes, which need to be copied into
* thisrr->data by either the decryption or by the decompression When
* the data is 'copied' into the thisrr->data buffer, thisrr->input will
* be pointed at the new buffer
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
*/
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/*
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
* We now have - encrypted [ MAC [ compressed [ plain ] ] ]
* thisrr->length bytes of encrypted compressed stuff.
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
*/
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
/* decrypt in place in 'thisrr->input' */
thisrr->data = thisrr->input;
thisrr->orig_len = thisrr->length;
Reject out of context empty records Previously if we received an empty record we just threw it away and ignored it. Really though if we get an empty record of a different content type to what we are expecting then that should be an error, i.e. we should reject out of context empty records. This commit makes the necessary changes to achieve that. RT#4395 Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-06-01 23:31:11 +08:00
/* Mark this record as not read by upper layers yet */
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr->read = 0;
Reject out of context empty records Previously if we received an empty record we just threw it away and ignored it. Really though if we get an empty record of a different content type to what we are expecting then that should be an error, i.e. we should reject out of context empty records. This commit makes the necessary changes to achieve that. RT#4395 Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-06-01 23:31:11 +08:00
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
num_recs++;
/* we have pulled in a full packet so zero things */
RECORD_LAYER_reset_packet_length(&s->rlayer);
Address feedback on SSLv2 ClientHello processing Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-08-03 20:03:25 +08:00
RECORD_LAYER_clear_first_record(&s->rlayer);
Use the current record offset in ssl3_get_record The function ssl3_get_record() can obtain multiple records in one go as long as we are set up for pipelining and all the records are app data records. The logic in the while loop which reads in each record is supposed to only continue looping if the last record we read was app data and we have an app data record waiting in the buffer to be processed. It was actually checking that the first record had app data and we have an app data record waiting. This actually amounts to the same thing so wasn't wrong - but it looks a bit odd because it uses the |rr| array without an offset. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-04-26 23:07:17 +08:00
} while (num_recs < max_recs
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
&& thisrr->type == SSL3_RT_APPLICATION_DATA
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
&& SSL_USE_EXPLICIT_IV(s)
&& s->enc_read_ctx != NULL
&& (EVP_CIPHER_flags(EVP_CIPHER_CTX_cipher(s->enc_read_ctx))
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
& EVP_CIPH_FLAG_PIPELINE)
Rename a function Rename the have_whole_app_data_record_waiting() function to include the ssl3_record prefix...and make it a bit shorter. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:11:42 +08:00
&& ssl3_record_app_data_waiting(s));
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/*
* If in encrypt-then-mac mode calculate mac from encrypted record. All
* the details below are public so no timing details can leak.
*/
Don't change the state of the ETM flags until CCS processing In 1.1.0 changing the ciphersuite during a renegotiation can result in a crash leading to a DoS attack. In master this does not occur with TLS (instead you get an internal error, which is still wrong but not a security issue) - but the problem still exists in the DTLS code. The problem is caused by changing the flag indicating whether to use ETM or not immediately on negotiation of ETM, rather than at CCS. Therefore, during a renegotiation, if the ETM state is changing (usually due to a change of ciphersuite), then an error/crash will occur. Due to the fact that there are separate CCS messages for read and write we actually now need two flags to determine whether to use ETM or not. CVE-2017-3733 Reviewed-by: Richard Levitte <levitte@openssl.org>
2017-02-03 22:06:20 +08:00
if (SSL_READ_ETM(s) && s->read_hash) {
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
unsigned char *mac;
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
/* TODO(size_t): convert this to do size_t properly */
imac_size = EVP_MD_CTX_size(s->read_hash);
Remove an OPENSSL_assert() and replace with a soft assert and check Following on from CVE-2017-3733, this removes the OPENSSL_assert() check that failed and replaces it with a soft assert, and an explicit check of value with an error return if it fails. Reviewed-by: Richard Levitte <levitte@openssl.org>
2017-02-03 22:45:49 +08:00
assert(imac_size >= 0 && imac_size <= EVP_MAX_MD_SIZE);
if (imac_size < 0 || imac_size > EVP_MAX_MD_SIZE) {
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
al = SSL_AD_INTERNAL_ERROR;
SSLerr(SSL_F_SSL3_GET_RECORD, ERR_LIB_EVP);
goto f_err;
}
mac_size = (size_t)imac_size;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
for (j = 0; j < num_recs; j++) {
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr = &rr[j];
if (thisrr->length < mac_size) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
al = SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_LENGTH_TOO_SHORT);
goto f_err;
}
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr->length -= mac_size;
mac = thisrr->data + thisrr->length;
i = s->method->ssl3_enc->mac(s, thisrr, md, 0 /* not send */ );
Convert the mac functions to just return 1 for success and 0 for failure Previously they return -1 for failure or the size of the mac. But the size was never used anywhere. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:44:28 +08:00
if (i == 0 || CRYPTO_memcmp(md, mac, mac_size) != 0) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
al = SSL_AD_BAD_RECORD_MAC;
SSLerr(SSL_F_SSL3_GET_RECORD,
SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC);
goto f_err;
}
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
}
}
Check max_early_data against the amount of early data we actually receive Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-23 22:29:36 +08:00
first_rec_len = rr[0].length;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
enc_err = s->method->ssl3_enc->enc(s, rr, num_recs, 0);
Update the record layer to use TLSv1.3 style record construction Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 07:44:09 +08:00
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/*-
* enc_err is:
Provide an SSL_read_early() function for reading early data Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-22 01:14:42 +08:00
* 0: (in non-constant time) if the record is publicly invalid.
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
* 1: if the padding is valid
* -1: if the padding is invalid
*/
if (enc_err == 0) {
Parse the early_data extension We also skip any early_data that subsequently gets sent. Later commits will process it if we can. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-21 00:35:03 +08:00
if (num_recs == 1 && ossl_statem_skip_early_data(s)) {
/*
Provide an SSL_read_early() function for reading early data Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-22 01:14:42 +08:00
* Valid early_data that we cannot decrypt might fail here as
* publicly invalid. We treat it like an empty record.
Parse the early_data extension We also skip any early_data that subsequently gets sent. Later commits will process it if we can. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-21 00:35:03 +08:00
*/
Check max_early_data against the amount of early data we actually receive Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-23 22:29:36 +08:00
Parse the early_data extension We also skip any early_data that subsequently gets sent. Later commits will process it if we can. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-21 00:35:03 +08:00
thisrr = &rr[0];
Check max_early_data against the amount of early data we actually receive Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-23 22:29:36 +08:00
if (!early_data_count_ok(s, thisrr->length,
EARLY_DATA_CIPHERTEXT_OVERHEAD, &al))
goto f_err;
Parse the early_data extension We also skip any early_data that subsequently gets sent. Later commits will process it if we can. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-21 00:35:03 +08:00
thisrr->length = 0;
thisrr->read = 1;
RECORD_LAYER_set_numrpipes(&s->rlayer, 1);
Make sure we reset the read sequence when skipping records Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-24 00:05:57 +08:00
RECORD_LAYER_reset_read_sequence(&s->rlayer);
Parse the early_data extension We also skip any early_data that subsequently gets sent. Later commits will process it if we can. Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-21 00:35:03 +08:00
return 1;
}
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
al = SSL_AD_DECRYPTION_FAILED;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_BLOCK_CIPHER_PAD_IS_WRONG);
goto f_err;
}
Remove outdated DEBUG flags. Add -DBIO_DEBUG to --strict-warnings. Remove comments about outdated debugging ifdef guards. Remove md_rand ifdef guarding an assert; it doesn't seem used. Remove the conf guards in conf_api since we use OPENSSL_assert, not assert. For pkcs12 stuff put OPENSSL_ in front of the macro name. Merge TLS_DEBUG into SSL_DEBUG. Various things just turned on/off asserts, mainly for checking non-NULL arguments, which is now removed: camellia, bn_ctx, crypto/modes. Remove some old debug code, that basically just printed things to stderr: DEBUG_PRINT_UNKNOWN_CIPHERSUITES, DEBUG_ZLIB, OPENSSL_RI_DEBUG, RL_DEBUG, RSA_DEBUG, SCRYPT_DEBUG. Remove OPENSSL_SSL_DEBUG_BROKEN_PROTOCOL. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-19 00:33:21 +08:00
#ifdef SSL_DEBUG
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
printf("dec %"OSSLzu"\n", rr[0].length);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
{
Further libssl size_t-ify of reading Writing still to be done Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 19:05:25 +08:00
size_t z;
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
for (z = 0; z < rr[0].length; z++)
printf("%02X%c", rr[0].data[z], ((z + 1) % 16) ? ' ' : '\n');
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
}
printf("\n");
#endif
/* r->length is now the compressed data plus mac */
if ((sess != NULL) &&
(s->enc_read_ctx != NULL) &&
Don't change the state of the ETM flags until CCS processing In 1.1.0 changing the ciphersuite during a renegotiation can result in a crash leading to a DoS attack. In master this does not occur with TLS (instead you get an internal error, which is still wrong but not a security issue) - but the problem still exists in the DTLS code. The problem is caused by changing the flag indicating whether to use ETM or not immediately on negotiation of ETM, rather than at CCS. Therefore, during a renegotiation, if the ETM state is changing (usually due to a change of ciphersuite), then an error/crash will occur. Due to the fact that there are separate CCS messages for read and write we actually now need two flags to determine whether to use ETM or not. CVE-2017-3733 Reviewed-by: Richard Levitte <levitte@openssl.org>
2017-02-03 22:06:20 +08:00
(!SSL_READ_ETM(s) && EVP_MD_CTX_md(s->read_hash) != NULL)) {
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/* s->read_hash != NULL => mac_size != -1 */
unsigned char *mac = NULL;
unsigned char mac_tmp[EVP_MAX_MD_SIZE];
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
mac_size = EVP_MD_CTX_size(s->read_hash);
OPENSSL_assert(mac_size <= EVP_MAX_MD_SIZE);
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
for (j = 0; j < num_recs; j++) {
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr = &rr[j];
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/*
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
* orig_len is the length of the record before any padding was
* removed. This is public information, as is the MAC in use,
* therefore we can safely process the record in a different amount
* of time if it's too short to possibly contain a MAC.
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
*/
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (thisrr->orig_len < mac_size ||
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/* CBC records must have a padding length byte too. */
(EVP_CIPHER_CTX_mode(s->enc_read_ctx) == EVP_CIPH_CBC_MODE &&
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr->orig_len < mac_size + 1)) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
al = SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_LENGTH_TOO_SHORT);
goto f_err;
}
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
if (EVP_CIPHER_CTX_mode(s->enc_read_ctx) == EVP_CIPH_CBC_MODE) {
/*
* We update the length so that the TLS header bytes can be
* constructed correctly but we need to extract the MAC in
* constant time from within the record, without leaking the
* contents of the padding bytes.
*/
mac = mac_tmp;
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
ssl3_cbc_copy_mac(mac_tmp, thisrr, mac_size);
thisrr->length -= mac_size;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
} else {
/*
* In this case there's no padding, so |rec->orig_len| equals
* |rec->length| and we checked that there's enough bytes for
* |mac_size| above.
*/
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr->length -= mac_size;
mac = &thisrr->data[thisrr->length];
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
}
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
i = s->method->ssl3_enc->mac(s, thisrr, md, 0 /* not send */ );
Convert the mac functions to just return 1 for success and 0 for failure Previously they return -1 for failure or the size of the mac. But the size was never used anywhere. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:44:28 +08:00
if (i == 0 || mac == NULL
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
|| CRYPTO_memcmp(md, mac, (size_t)mac_size) != 0)
enc_err = -1;
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (thisrr->length > SSL3_RT_MAX_COMPRESSED_LENGTH + mac_size)
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
enc_err = -1;
}
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
}
if (enc_err < 0) {
Provide an SSL_read_early() function for reading early data Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-22 01:14:42 +08:00
if (num_recs == 1 && ossl_statem_skip_early_data(s)) {
/*
* We assume this is unreadable early_data - we treat it like an
* empty record
*/
Check max_early_data against the amount of early data we actually receive Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-23 22:29:36 +08:00
/*
* The record length may have been modified by the mac check above
* so we use the previously saved value
*/
if (!early_data_count_ok(s, first_rec_len,
EARLY_DATA_CIPHERTEXT_OVERHEAD, &al))
goto f_err;
Provide an SSL_read_early() function for reading early data Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-22 01:14:42 +08:00
thisrr = &rr[0];
thisrr->length = 0;
thisrr->read = 1;
RECORD_LAYER_set_numrpipes(&s->rlayer, 1);
Make sure we reset the read sequence when skipping records Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-24 00:05:57 +08:00
RECORD_LAYER_reset_read_sequence(&s->rlayer);
Provide an SSL_read_early() function for reading early data Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-22 01:14:42 +08:00
return 1;
}
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/*
* A separate 'decryption_failed' alert was introduced with TLS 1.0,
* SSL 3.0 only has 'bad_record_mac'. But unless a decryption
* failure is directly visible from the ciphertext anyway, we should
* not reveal which kind of error occurred -- this might become
* visible to an attacker (e.g. via a logfile)
*/
al = SSL_AD_BAD_RECORD_MAC;
SSLerr(SSL_F_SSL3_GET_RECORD,
SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC);
goto f_err;
}
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
for (j = 0; j < num_recs; j++) {
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr = &rr[j];
/* thisrr->length is now just compressed */
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
if (s->expand != NULL) {
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (thisrr->length > SSL3_RT_MAX_COMPRESSED_LENGTH) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
al = SSL_AD_RECORD_OVERFLOW;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_COMPRESSED_LENGTH_TOO_LONG);
goto f_err;
}
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (!ssl3_do_uncompress(s, thisrr)) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
al = SSL_AD_DECOMPRESSION_FAILURE;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_BAD_DECOMPRESSION);
goto f_err;
}
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
}
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
Update the record layer to use TLSv1.3 style record construction Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 07:44:09 +08:00
if (SSL_IS_TLS13(s) && s->enc_read_ctx != NULL) {
size_t end;
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (thisrr->length == 0) {
Update the record layer to use TLSv1.3 style record construction Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 07:44:09 +08:00
al = SSL_AD_UNEXPECTED_MESSAGE;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_BAD_RECORD_TYPE);
goto f_err;
}
/* Strip trailing padding */
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
for (end = thisrr->length - 1; end > 0 && thisrr->data[end] == 0;
end--)
Update the record layer to use TLSv1.3 style record construction Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 07:44:09 +08:00
continue;
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr->length = end;
thisrr->type = thisrr->data[end];
if (thisrr->type != SSL3_RT_APPLICATION_DATA
&& thisrr->type != SSL3_RT_ALERT
&& thisrr->type != SSL3_RT_HANDSHAKE) {
Update the record layer to use TLSv1.3 style record construction Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 07:44:09 +08:00
al = SSL_AD_UNEXPECTED_MESSAGE;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_BAD_RECORD_TYPE);
goto f_err;
}
}
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (thisrr->length > SSL3_RT_MAX_PLAIN_LENGTH) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
al = SSL_AD_RECORD_OVERFLOW;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_DATA_LENGTH_TOO_LONG);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
goto f_err;
}
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
thisrr->off = 0;
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/*-
* So at this point the following is true
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
* thisrr->type is the type of record
* thisrr->length == number of bytes in record
* thisrr->off == offset to first valid byte
* thisrr->data == where to take bytes from, increment after use :-).
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
*/
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
/* just read a 0 length packet */
Change various repeated rr[someindex] references to a pointer Improves the readability of the code, and reduces the liklihood of errors. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-12-02 19:09:16 +08:00
if (thisrr->length == 0) {
Reject out of context empty records Previously if we received an empty record we just threw it away and ignored it. Really though if we get an empty record of a different content type to what we are expecting then that should be an error, i.e. we should reject out of context empty records. This commit makes the necessary changes to achieve that. RT#4395 Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-06-01 23:31:11 +08:00
RECORD_LAYER_inc_empty_record_count(&s->rlayer);
if (RECORD_LAYER_get_empty_record_count(&s->rlayer)
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
> MAX_EMPTY_RECORDS) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
al = SSL_AD_UNEXPECTED_MESSAGE;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_RECORD_TOO_SMALL);
goto f_err;
}
Reject out of context empty records Previously if we received an empty record we just threw it away and ignored it. Really though if we get an empty record of a different content type to what we are expecting then that should be an error, i.e. we should reject out of context empty records. This commit makes the necessary changes to achieve that. RT#4395 Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-06-01 23:31:11 +08:00
} else {
RECORD_LAYER_reset_empty_record_count(&s->rlayer);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
}
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
}
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
Check max_early_data against the amount of early data we actually receive Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2737)
2017-02-23 22:29:36 +08:00
if (s->early_data_state == SSL_EARLY_DATA_READING) {
thisrr = &rr[0];
if (thisrr->type == SSL3_RT_APPLICATION_DATA
&& !early_data_count_ok(s, thisrr->length, 0, &al))
goto f_err;
}
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
RECORD_LAYER_set_numrpipes(&s->rlayer, num_recs);
return 1;
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
f_err:
ssl3_send_alert(s, SSL3_AL_FATAL, al);
err:
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
return ret;
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
}
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
int ssl3_do_uncompress(SSL *ssl, SSL3_RECORD *rr)
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
{
#ifndef OPENSSL_NO_COMP
int i;
Lazily initialise the compression buffer With read pipelining we use multiple SSL3_RECORD structures for reading. There are SSL_MAX_PIPELINES (32) of them defined (typically not all of these would be used). Each one has a 16k compression buffer allocated! This results in a significant amount of memory being consumed which, most of the time, is not needed. This change swaps the allocation of the compression buffer to be lazy so that it is only done immediately before it is actually used. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-13 19:44:04 +08:00
if (rr->comp == NULL) {
rr->comp = (unsigned char *)
OPENSSL_malloc(SSL3_RT_MAX_ENCRYPTED_LENGTH);
}
if (rr->comp == NULL)
return 0;
Further libssl size_t-ify of reading Writing still to be done Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 19:05:25 +08:00
/* TODO(size_t): Convert this call */
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
i = COMP_expand_block(ssl->expand, rr->comp,
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
SSL3_RT_MAX_PLAIN_LENGTH, rr->data, (int)rr->length);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
if (i < 0)
Lazily initialise the compression buffer With read pipelining we use multiple SSL3_RECORD structures for reading. There are SSL_MAX_PIPELINES (32) of them defined (typically not all of these would be used). Each one has a 16k compression buffer allocated! This results in a significant amount of memory being consumed which, most of the time, is not needed. This change swaps the allocation of the compression buffer to be lazy so that it is only done immediately before it is actually used. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-13 19:44:04 +08:00
return 0;
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
else
rr->length = i;
rr->data = rr->comp;
#endif
Lazily initialise the compression buffer With read pipelining we use multiple SSL3_RECORD structures for reading. There are SSL_MAX_PIPELINES (32) of them defined (typically not all of these would be used). Each one has a 16k compression buffer allocated! This results in a significant amount of memory being consumed which, most of the time, is not needed. This change swaps the allocation of the compression buffer to be lazy so that it is only done immediately before it is actually used. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-13 19:44:04 +08:00
return 1;
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
}
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
int ssl3_do_compress(SSL *ssl, SSL3_RECORD *wr)
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
{
#ifndef OPENSSL_NO_COMP
int i;
Further libssl size_t-ify of reading Writing still to be done Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 19:05:25 +08:00
/* TODO(size_t): Convert this call */
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
i = COMP_compress_block(ssl->compress, wr->data,
Convert TLS record construction to use WPACKET Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-11-19 00:35:46 +08:00
(int)(wr->length + SSL3_RT_MAX_COMPRESSED_OVERHEAD),
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
wr->input, (int)wr->length);
if (i < 0)
return (0);
else
wr->length = i;
wr->input = wr->data;
#endif
return (1);
}
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
/*-
Rename the numpipes argument to ssl3_enc/tls1_enc The numpipes argument to ssl3_enc/tls1_enc is actually the number of records passed in the array. To make this clearer rename the argument to |n_recs|. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:17:42 +08:00
* ssl3_enc encrypts/decrypts |n_recs| records in |inrecs|
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
*
* Returns:
* 0: (in non-constant time) if the record is publically invalid (i.e. too
* short etc).
* 1: if the record's padding is valid / the encryption was successful.
* -1: if the record's padding is invalid or, if sending, an internal error
* occurred.
*/
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
int ssl3_enc(SSL *s, SSL3_RECORD *inrecs, size_t n_recs, int sending)
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
{
SSL3_RECORD *rec;
EVP_CIPHER_CTX *ds;
Further libssl size_t-ify of reading Writing still to be done Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 19:05:25 +08:00
size_t l, i;
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
size_t bs, mac_size = 0;
int imac_size;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
const EVP_CIPHER *enc;
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
rec = inrecs;
Rename the numpipes argument to ssl3_enc/tls1_enc The numpipes argument to ssl3_enc/tls1_enc is actually the number of records passed in the array. To make this clearer rename the argument to |n_recs|. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:17:42 +08:00
/*
* We shouldn't ever be called with more than one record in the SSLv3 case
*/
if (n_recs != 1)
return 0;
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if (sending) {
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
ds = s->enc_write_ctx;
if (s->enc_write_ctx == NULL)
enc = NULL;
else
enc = EVP_CIPHER_CTX_cipher(s->enc_write_ctx);
} else {
ds = s->enc_read_ctx;
if (s->enc_read_ctx == NULL)
enc = NULL;
else
enc = EVP_CIPHER_CTX_cipher(s->enc_read_ctx);
}
if ((s->session == NULL) || (ds == NULL) || (enc == NULL)) {
memmove(rec->data, rec->input, rec->length);
rec->input = rec->data;
} else {
l = rec->length;
Further libssl size_t-ify of reading Writing still to be done Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 19:05:25 +08:00
/* TODO(size_t): Convert this call */
Adapt all EVP_CIPHER_CTX users for it becoming opaque Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-12-14 05:08:41 +08:00
bs = EVP_CIPHER_CTX_block_size(ds);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
/* COMPRESS */
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if ((bs != 1) && sending) {
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
i = bs - (l % bs);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
/* we need to add 'i-1' padding bytes */
l += i;
/*
* the last of these zero bytes will be overwritten with the
* padding length.
*/
memset(&rec->input[rec->length], 0, i);
rec->length += i;
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
rec->input[l - 1] = (unsigned char)(i - 1);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if (!sending) {
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
if (l == 0 || l % bs != 0)
return 0;
/* otherwise, rec->length >= bs */
}
Further libssl size_t-ify of reading Writing still to be done Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 19:05:25 +08:00
/* TODO(size_t): Convert this call */
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
if (EVP_Cipher(ds, rec->data, rec->input, (unsigned int)l) < 1)
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
return -1;
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
if (EVP_MD_CTX_md(s->read_hash) != NULL) {
/* TODO(size_t): convert me */
imac_size = EVP_MD_CTX_size(s->read_hash);
if (imac_size < 0)
return -1;
mac_size = (size_t)imac_size;
}
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if ((bs != 1) && !sending)
Remove unused parameters from internal functions Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-14 11:33:56 +08:00
return ssl3_cbc_remove_padding(rec, bs, mac_size);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
return (1);
}
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
#define MAX_PADDING 256
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
/*-
Rename the numpipes argument to ssl3_enc/tls1_enc The numpipes argument to ssl3_enc/tls1_enc is actually the number of records passed in the array. To make this clearer rename the argument to |n_recs|. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:17:42 +08:00
* tls1_enc encrypts/decrypts |n_recs| in |recs|.
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
*
* Returns:
* 0: (in non-constant time) if the record is publically invalid (i.e. too
* short etc).
* 1: if the record's padding is valid / the encryption was successful.
* -1: if the record's padding/AEAD-authenticator is invalid or, if sending,
* an internal error occurred.
*/
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
int tls1_enc(SSL *s, SSL3_RECORD *recs, size_t n_recs, int sending)
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
{
EVP_CIPHER_CTX *ds;
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
size_t reclen[SSL_MAX_PIPELINES];
unsigned char buf[SSL_MAX_PIPELINES][EVP_AEAD_TLS1_AAD_LEN];
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
int i, pad = 0, ret, tmpr;
size_t bs, mac_size = 0, ctr, padnum, loop;
unsigned char padval;
int imac_size;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
const EVP_CIPHER *enc;
Check for zero records and return immediately Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2822)
2017-03-02 10:54:06 +08:00
if (n_recs == 0)
return 0;
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if (sending) {
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
if (EVP_MD_CTX_md(s->write_hash)) {
int n = EVP_MD_CTX_size(s->write_hash);
OPENSSL_assert(n >= 0);
}
ds = s->enc_write_ctx;
if (s->enc_write_ctx == NULL)
enc = NULL;
else {
int ivlen;
enc = EVP_CIPHER_CTX_cipher(s->enc_write_ctx);
/* For TLSv1.1 and later explicit IV */
if (SSL_USE_EXPLICIT_IV(s)
&& EVP_CIPHER_mode(enc) == EVP_CIPH_CBC_MODE)
ivlen = EVP_CIPHER_iv_length(enc);
else
ivlen = 0;
if (ivlen > 1) {
Rename the numpipes argument to ssl3_enc/tls1_enc The numpipes argument to ssl3_enc/tls1_enc is actually the number of records passed in the array. To make this clearer rename the argument to |n_recs|. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:17:42 +08:00
for (ctr = 0; ctr < n_recs; ctr++) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
if (recs[ctr].data != recs[ctr].input) {
/*
* we can't write into the input stream: Can this ever
* happen?? (steve)
*/
SSLerr(SSL_F_TLS1_ENC, ERR_R_INTERNAL_ERROR);
return -1;
} else if (RAND_bytes(recs[ctr].input, ivlen) <= 0) {
SSLerr(SSL_F_TLS1_ENC, ERR_R_INTERNAL_ERROR);
return -1;
}
}
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
}
} else {
if (EVP_MD_CTX_md(s->read_hash)) {
int n = EVP_MD_CTX_size(s->read_hash);
OPENSSL_assert(n >= 0);
}
ds = s->enc_read_ctx;
if (s->enc_read_ctx == NULL)
enc = NULL;
else
enc = EVP_CIPHER_CTX_cipher(s->enc_read_ctx);
}
if ((s->session == NULL) || (ds == NULL) || (enc == NULL)) {
Rename the numpipes argument to ssl3_enc/tls1_enc The numpipes argument to ssl3_enc/tls1_enc is actually the number of records passed in the array. To make this clearer rename the argument to |n_recs|. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:17:42 +08:00
for (ctr = 0; ctr < n_recs; ctr++) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
memmove(recs[ctr].data, recs[ctr].input, recs[ctr].length);
recs[ctr].input = recs[ctr].data;
}
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
ret = 1;
} else {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
bs = EVP_CIPHER_block_size(EVP_CIPHER_CTX_cipher(ds));
Rename the numpipes argument to ssl3_enc/tls1_enc The numpipes argument to ssl3_enc/tls1_enc is actually the number of records passed in the array. To make this clearer rename the argument to |n_recs|. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:17:42 +08:00
if (n_recs > 1) {
Fix a few if(, for(, while( inside code. Fix some indentation at the same time Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1292)
2016-06-29 06:18:50 +08:00
if (!(EVP_CIPHER_flags(EVP_CIPHER_CTX_cipher(ds))
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
& EVP_CIPH_FLAG_PIPELINE)) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
/*
* We shouldn't have been called with pipeline data if the
* cipher doesn't support pipelining
*/
SSLerr(SSL_F_TLS1_ENC, SSL_R_PIPELINE_FAILURE);
return -1;
}
}
Rename the numpipes argument to ssl3_enc/tls1_enc The numpipes argument to ssl3_enc/tls1_enc is actually the number of records passed in the array. To make this clearer rename the argument to |n_recs|. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:17:42 +08:00
for (ctr = 0; ctr < n_recs; ctr++) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
reclen[ctr] = recs[ctr].length;
if (EVP_CIPHER_flags(EVP_CIPHER_CTX_cipher(ds))
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
& EVP_CIPH_FLAG_AEAD_CIPHER) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
unsigned char *seq;
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
seq = sending ? RECORD_LAYER_get_write_sequence(&s->rlayer)
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
: RECORD_LAYER_get_read_sequence(&s->rlayer);
if (SSL_IS_DTLS(s)) {
/* DTLS does not support pipelining */
unsigned char dtlsseq[9], *p = dtlsseq;
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
s2n(sending ? DTLS_RECORD_LAYER_get_w_epoch(&s->rlayer) :
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
DTLS_RECORD_LAYER_get_r_epoch(&s->rlayer), p);
memcpy(p, &seq[2], 6);
memcpy(buf[ctr], dtlsseq, 8);
} else {
memcpy(buf[ctr], seq, 8);
for (i = 7; i >= 0; i--) { /* increment */
++seq[i];
if (seq[i] != 0)
break;
}
}
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
buf[ctr][8] = recs[ctr].type;
buf[ctr][9] = (unsigned char)(s->version >> 8);
buf[ctr][10] = (unsigned char)(s->version);
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
buf[ctr][11] = (unsigned char)(recs[ctr].length >> 8);
buf[ctr][12] = (unsigned char)(recs[ctr].length & 0xff);
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
pad = EVP_CIPHER_CTX_ctrl(ds, EVP_CTRL_AEAD_TLS1_AAD,
EVP_AEAD_TLS1_AAD_LEN, buf[ctr]);
if (pad <= 0)
return -1;
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if (sending) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
reclen[ctr] += pad;
recs[ctr].length += pad;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
} else if ((bs != 1) && sending) {
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
padnum = bs - (reclen[ctr] % bs);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
/* Add weird padding of upto 256 bytes */
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
if (padnum > MAX_PADDING)
return -1;
/* we need to add 'padnum' padding bytes of value padval */
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
padval = (unsigned char)(padnum - 1);
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
for (loop = reclen[ctr]; loop < reclen[ctr] + padnum; loop++)
recs[ctr].input[loop] = padval;
reclen[ctr] += padnum;
recs[ctr].length += padnum;
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
}
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if (!sending) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
if (reclen[ctr] == 0 || reclen[ctr] % bs != 0)
return 0;
}
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
Rename the numpipes argument to ssl3_enc/tls1_enc The numpipes argument to ssl3_enc/tls1_enc is actually the number of records passed in the array. To make this clearer rename the argument to |n_recs|. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:17:42 +08:00
if (n_recs > 1) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
unsigned char *data[SSL_MAX_PIPELINES];
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
/* Set the output buffers */
Fix a few if(, for(, while( inside code. Fix some indentation at the same time Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1292)
2016-06-29 06:18:50 +08:00
for (ctr = 0; ctr < n_recs; ctr++) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
data[ctr] = recs[ctr].data;
}
if (EVP_CIPHER_CTX_ctrl(ds, EVP_CTRL_SET_PIPELINE_OUTPUT_BUFS,
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
(int)n_recs, data) <= 0) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
SSLerr(SSL_F_TLS1_ENC, SSL_R_PIPELINE_FAILURE);
}
/* Set the input buffers */
Fix a few if(, for(, while( inside code. Fix some indentation at the same time Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1292)
2016-06-29 06:18:50 +08:00
for (ctr = 0; ctr < n_recs; ctr++) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
data[ctr] = recs[ctr].input;
}
if (EVP_CIPHER_CTX_ctrl(ds, EVP_CTRL_SET_PIPELINE_INPUT_BUFS,
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
(int)n_recs, data) <= 0
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
|| EVP_CIPHER_CTX_ctrl(ds, EVP_CTRL_SET_PIPELINE_INPUT_LENS,
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
(int)n_recs, reclen) <= 0) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
SSLerr(SSL_F_TLS1_ENC, SSL_R_PIPELINE_FAILURE);
return -1;
}
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
/* TODO(size_t): Convert this call */
tmpr = EVP_Cipher(ds, recs[0].data, recs[0].input,
(unsigned int)reclen[0]);
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
if ((EVP_CIPHER_flags(EVP_CIPHER_CTX_cipher(ds))
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
& EVP_CIPH_FLAG_CUSTOM_CIPHER)
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
? (tmpr < 0)
: (tmpr == 0))
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
return -1; /* AEAD can fail to verify MAC */
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if (sending == 0) {
CCM support. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-07-31 23:54:35 +08:00
if (EVP_CIPHER_mode(enc) == EVP_CIPH_GCM_MODE) {
Rename the numpipes argument to ssl3_enc/tls1_enc The numpipes argument to ssl3_enc/tls1_enc is actually the number of records passed in the array. To make this clearer rename the argument to |n_recs|. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:17:42 +08:00
for (ctr = 0; ctr < n_recs; ctr++) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
recs[ctr].data += EVP_GCM_TLS_EXPLICIT_IV_LEN;
recs[ctr].input += EVP_GCM_TLS_EXPLICIT_IV_LEN;
recs[ctr].length -= EVP_GCM_TLS_EXPLICIT_IV_LEN;
}
CCM support. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-07-31 23:54:35 +08:00
} else if (EVP_CIPHER_mode(enc) == EVP_CIPH_CCM_MODE) {
Rename the numpipes argument to ssl3_enc/tls1_enc The numpipes argument to ssl3_enc/tls1_enc is actually the number of records passed in the array. To make this clearer rename the argument to |n_recs|. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:17:42 +08:00
for (ctr = 0; ctr < n_recs; ctr++) {
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
recs[ctr].data += EVP_CCM_TLS_EXPLICIT_IV_LEN;
recs[ctr].input += EVP_CCM_TLS_EXPLICIT_IV_LEN;
recs[ctr].length -= EVP_CCM_TLS_EXPLICIT_IV_LEN;
}
CCM support. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-07-31 23:54:35 +08:00
}
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
ret = 1;
Don't change the state of the ETM flags until CCS processing In 1.1.0 changing the ciphersuite during a renegotiation can result in a crash leading to a DoS attack. In master this does not occur with TLS (instead you get an internal error, which is still wrong but not a security issue) - but the problem still exists in the DTLS code. The problem is caused by changing the flag indicating whether to use ETM or not immediately on negotiation of ETM, rather than at CCS. Therefore, during a renegotiation, if the ETM state is changing (usually due to a change of ciphersuite), then an error/crash will occur. Due to the fact that there are separate CCS messages for read and write we actually now need two flags to determine whether to use ETM or not. CVE-2017-3733 Reviewed-by: Richard Levitte <levitte@openssl.org>
2017-02-03 22:06:20 +08:00
if (!SSL_READ_ETM(s) && EVP_MD_CTX_md(s->read_hash) != NULL) {
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
imac_size = EVP_MD_CTX_size(s->read_hash);
if (imac_size < 0)
return -1;
mac_size = (size_t)imac_size;
}
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if ((bs != 1) && !sending) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
int tmpret;
Rename the numpipes argument to ssl3_enc/tls1_enc The numpipes argument to ssl3_enc/tls1_enc is actually the number of records passed in the array. To make this clearer rename the argument to |n_recs|. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:17:42 +08:00
for (ctr = 0; ctr < n_recs; ctr++) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
tmpret = tls1_cbc_remove_padding(s, &recs[ctr], bs, mac_size);
Ensure we unpad in constant time for read pipelining The read pipelining code broke constant time unpadding. See GitHub issue #1438 Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-16 21:07:29 +08:00
/*
* If tmpret == 0 then this means publicly invalid so we can
* short circuit things here. Otherwise we must respect constant
* time behaviour.
*/
if (tmpret == 0)
return 0;
ret = constant_time_select_int(constant_time_eq_int(tmpret, 1),
ret, -1);
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
}
}
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if (pad && !sending) {
Rename the numpipes argument to ssl3_enc/tls1_enc The numpipes argument to ssl3_enc/tls1_enc is actually the number of records passed in the array. To make this clearer rename the argument to |n_recs|. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-03-07 20:17:42 +08:00
for (ctr = 0; ctr < n_recs; ctr++) {
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
recs[ctr].length -= pad;
}
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
}
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
return ret;
}
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
int n_ssl3_mac(SSL *ssl, SSL3_RECORD *rec, unsigned char *md, int sending)
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
{
unsigned char *mac_sec, *seq;
const EVP_MD_CTX *hash;
unsigned char *p, rec_char;
size_t md_size;
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
size_t npad;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
int t;
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if (sending) {
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
mac_sec = &(ssl->s3->write_mac_secret[0]);
Move read_sequence and write_sequence from s->s3 to s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 22:26:50 +08:00
seq = RECORD_LAYER_get_write_sequence(&ssl->rlayer);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
hash = ssl->write_hash;
} else {
mac_sec = &(ssl->s3->read_mac_secret[0]);
Move read_sequence and write_sequence from s->s3 to s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 22:26:50 +08:00
seq = RECORD_LAYER_get_read_sequence(&ssl->rlayer);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
hash = ssl->read_hash;
}
t = EVP_MD_CTX_size(hash);
if (t < 0)
Convert the mac functions to just return 1 for success and 0 for failure Previously they return -1 for failure or the size of the mac. But the size was never used anywhere. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:44:28 +08:00
return 0;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
md_size = t;
npad = (48 / md_size) * md_size;
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if (!sending &&
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
EVP_CIPHER_CTX_mode(ssl->enc_read_ctx) == EVP_CIPH_CBC_MODE &&
ssl3_cbc_record_digest_supported(hash)) {
/*
* This is a CBC-encrypted record. We must avoid leaking any
* timing-side channel information about how many blocks of data we
* are hashing because that gives an attacker a timing-oracle.
*/
/*-
* npad is, at most, 48 bytes and that's with MD5:
* 16 + 48 + 8 (sequence bytes) + 1 + 2 = 75.
*
* With SHA-1 (the largest hash speced for SSLv3) the hash size
* goes up 4, but npad goes down by 8, resulting in a smaller
* total size.
*/
unsigned char header[75];
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
size_t j = 0;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
memcpy(header + j, mac_sec, md_size);
j += md_size;
memcpy(header + j, ssl3_pad_1, npad);
j += npad;
memcpy(header + j, seq, 8);
j += 8;
header[j++] = rec->type;
Fix some ssl3_record code witch converstion to/from size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:39:55 +08:00
header[j++] = (unsigned char)(rec->length >> 8);
header[j++] = (unsigned char)(rec->length & 0xff);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
/* Final param == is SSLv3 */
Ensure all EVP calls have their returns checked where appropriate There are lots of calls to EVP functions from within libssl There were various places where we should probably check the return value but don't. This adds these checks. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-11-07 00:31:21 +08:00
if (ssl3_cbc_digest_record(hash,
md, &md_size,
header, rec->input,
rec->length + md_size, rec->orig_len,
mac_sec, md_size, 1) <= 0)
Convert the mac functions to just return 1 for success and 0 for failure Previously they return -1 for failure or the size of the mac. But the size was never used anywhere. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:44:28 +08:00
return 0;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
} else {
unsigned int md_size_u;
/* Chop the digest off the end :-) */
Cleanup: fix all sources that used EVP_MD_CTX_(create|init|destroy) Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-12-02 07:49:35 +08:00
EVP_MD_CTX *md_ctx = EVP_MD_CTX_new();
Adjust all accesses to EVP_MD_CTX to use accessor functions. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-11-27 21:02:12 +08:00
if (md_ctx == NULL)
Convert the mac functions to just return 1 for success and 0 for failure Previously they return -1 for failure or the size of the mac. But the size was never used anywhere. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:44:28 +08:00
return 0;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
rec_char = rec->type;
p = md;
s2n(rec->length, p);
Adjust all accesses to EVP_MD_CTX to use accessor functions. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-11-27 21:02:12 +08:00
if (EVP_MD_CTX_copy_ex(md_ctx, hash) <= 0
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
|| EVP_DigestUpdate(md_ctx, mac_sec, md_size) <= 0
|| EVP_DigestUpdate(md_ctx, ssl3_pad_1, npad) <= 0
|| EVP_DigestUpdate(md_ctx, seq, 8) <= 0
|| EVP_DigestUpdate(md_ctx, &rec_char, 1) <= 0
|| EVP_DigestUpdate(md_ctx, md, 2) <= 0
|| EVP_DigestUpdate(md_ctx, rec->input, rec->length) <= 0
|| EVP_DigestFinal_ex(md_ctx, md, NULL) <= 0
|| EVP_MD_CTX_copy_ex(md_ctx, hash) <= 0
|| EVP_DigestUpdate(md_ctx, mac_sec, md_size) <= 0
|| EVP_DigestUpdate(md_ctx, ssl3_pad_2, npad) <= 0
|| EVP_DigestUpdate(md_ctx, md, md_size) <= 0
|| EVP_DigestFinal_ex(md_ctx, md, &md_size_u) <= 0) {
Cleanup: fix all sources that used EVP_MD_CTX_(create|init|destroy) Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-12-02 07:49:35 +08:00
EVP_MD_CTX_reset(md_ctx);
Convert the mac functions to just return 1 for success and 0 for failure Previously they return -1 for failure or the size of the mac. But the size was never used anywhere. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:44:28 +08:00
return 0;
Ensure all EVP calls have their returns checked where appropriate There are lots of calls to EVP functions from within libssl There were various places where we should probably check the return value but don't. This adds these checks. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-11-07 00:31:21 +08:00
}
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
Cleanup: fix all sources that used EVP_MD_CTX_(create|init|destroy) Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-12-02 07:49:35 +08:00
EVP_MD_CTX_free(md_ctx);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
ssl3_record_sequence_update(seq);
Convert the mac functions to just return 1 for success and 0 for failure Previously they return -1 for failure or the size of the mac. But the size was never used anywhere. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:44:28 +08:00
return 1;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
int tls1_mac(SSL *ssl, SSL3_RECORD *rec, unsigned char *md, int sending)
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
{
unsigned char *seq;
EVP_MD_CTX *hash;
size_t md_size;
int i;
Adjust all accesses to EVP_MD_CTX to use accessor functions. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-11-27 21:02:12 +08:00
EVP_MD_CTX *hmac = NULL, *mac_ctx;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
unsigned char header[13];
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
int stream_mac = (sending ? (ssl->mac_flags & SSL_MAC_FLAG_WRITE_MAC_STREAM)
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
: (ssl->mac_flags & SSL_MAC_FLAG_READ_MAC_STREAM));
int t;
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if (sending) {
Move read_sequence and write_sequence from s->s3 to s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 22:26:50 +08:00
seq = RECORD_LAYER_get_write_sequence(&ssl->rlayer);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
hash = ssl->write_hash;
} else {
Move read_sequence and write_sequence from s->s3 to s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 22:26:50 +08:00
seq = RECORD_LAYER_get_read_sequence(&ssl->rlayer);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
hash = ssl->read_hash;
}
t = EVP_MD_CTX_size(hash);
OPENSSL_assert(t >= 0);
md_size = t;
/* I should fix this up TLS TLS TLS TLS TLS XXXXXXXX */
if (stream_mac) {
mac_ctx = hash;
} else {
Cleanup: fix all sources that used EVP_MD_CTX_(create|init|destroy) Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-12-02 07:49:35 +08:00
hmac = EVP_MD_CTX_new();
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
if (hmac == NULL || !EVP_MD_CTX_copy(hmac, hash))
Convert the mac functions to just return 1 for success and 0 for failure Previously they return -1 for failure or the size of the mac. But the size was never used anywhere. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:44:28 +08:00
return 0;
Adjust all accesses to EVP_MD_CTX to use accessor functions. Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-11-27 21:02:12 +08:00
mac_ctx = hmac;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
if (SSL_IS_DTLS(ssl)) {
unsigned char dtlsseq[8], *p = dtlsseq;
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
s2n(sending ? DTLS_RECORD_LAYER_get_w_epoch(&ssl->rlayer) :
Move r_epoch and w_epoch from s->d1 to s->rlayer.d Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 23:14:24 +08:00
DTLS_RECORD_LAYER_get_r_epoch(&ssl->rlayer), p);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
memcpy(p, &seq[2], 6);
memcpy(header, dtlsseq, 8);
} else
memcpy(header, seq, 8);
header[8] = rec->type;
header[9] = (unsigned char)(ssl->version >> 8);
header[10] = (unsigned char)(ssl->version);
Fix misc size_t issues causing Windows warnings in 64 bit Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 22:11:24 +08:00
header[11] = (unsigned char)(rec->length >> 8);
header[12] = (unsigned char)(rec->length & 0xff);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
Fix some -Wshadow warnings Found using various (old-ish) versions of gcc. Reviewed-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2940)
2017-03-15 00:36:07 +08:00
if (!sending && !SSL_READ_ETM(ssl) &&
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
EVP_CIPHER_CTX_mode(ssl->enc_read_ctx) == EVP_CIPH_CBC_MODE &&
ssl3_cbc_record_digest_supported(mac_ctx)) {
/*
* This is a CBC-encrypted record. We must avoid leaking any
* timing-side channel information about how many blocks of data we
* are hashing because that gives an attacker a timing-oracle.
*/
/* Final param == not SSLv3 */
Ensure all EVP calls have their returns checked where appropriate There are lots of calls to EVP functions from within libssl There were various places where we should probably check the return value but don't. This adds these checks. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-11-07 00:31:21 +08:00
if (ssl3_cbc_digest_record(mac_ctx,
md, &md_size,
header, rec->input,
rec->length + md_size, rec->orig_len,
ssl->s3->read_mac_secret,
ssl->s3->read_mac_secret_size, 0) <= 0) {
Cleanup: fix all sources that used EVP_MD_CTX_(create|init|destroy) Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-12-02 07:49:35 +08:00
EVP_MD_CTX_free(hmac);
Ensure all EVP calls have their returns checked where appropriate There are lots of calls to EVP functions from within libssl There were various places where we should probably check the return value but don't. This adds these checks. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-11-07 00:31:21 +08:00
return -1;
}
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
} else {
Further libssl size_t-ify of reading Writing still to be done Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 19:05:25 +08:00
/* TODO(size_t): Convert these calls */
Ensure all EVP calls have their returns checked where appropriate There are lots of calls to EVP functions from within libssl There were various places where we should probably check the return value but don't. This adds these checks. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-11-07 00:31:21 +08:00
if (EVP_DigestSignUpdate(mac_ctx, header, sizeof(header)) <= 0
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
|| EVP_DigestSignUpdate(mac_ctx, rec->input, rec->length) <= 0
|| EVP_DigestSignFinal(mac_ctx, md, &md_size) <= 0) {
Cleanup: fix all sources that used EVP_MD_CTX_(create|init|destroy) Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-12-02 07:49:35 +08:00
EVP_MD_CTX_free(hmac);
Convert the mac functions to just return 1 for success and 0 for failure Previously they return -1 for failure or the size of the mac. But the size was never used anywhere. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:44:28 +08:00
return 0;
Ensure all EVP calls have their returns checked where appropriate There are lots of calls to EVP functions from within libssl There were various places where we should probably check the return value but don't. This adds these checks. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-11-07 00:31:21 +08:00
}
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
Cleanup: fix all sources that used EVP_MD_CTX_(create|init|destroy) Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-12-02 07:49:35 +08:00
EVP_MD_CTX_free(hmac);
Ensure all EVP calls have their returns checked where appropriate There are lots of calls to EVP functions from within libssl There were various places where we should probably check the return value but don't. This adds these checks. Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-11-07 00:31:21 +08:00
Remove outdated DEBUG flags. Add -DBIO_DEBUG to --strict-warnings. Remove comments about outdated debugging ifdef guards. Remove md_rand ifdef guarding an assert; it doesn't seem used. Remove the conf guards in conf_api since we use OPENSSL_assert, not assert. For pkcs12 stuff put OPENSSL_ in front of the macro name. Merge TLS_DEBUG into SSL_DEBUG. Various things just turned on/off asserts, mainly for checking non-NULL arguments, which is now removed: camellia, bn_ctx, crypto/modes. Remove some old debug code, that basically just printed things to stderr: DEBUG_PRINT_UNKNOWN_CIPHERSUITES, DEBUG_ZLIB, OPENSSL_RI_DEBUG, RL_DEBUG, RSA_DEBUG, SCRYPT_DEBUG. Remove OPENSSL_SSL_DEBUG_BROKEN_PROTOCOL. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-19 00:33:21 +08:00
#ifdef SSL_DEBUG
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
fprintf(stderr, "seq=");
{
int z;
for (z = 0; z < 8; z++)
fprintf(stderr, "%02X ", seq[z]);
fprintf(stderr, "\n");
}
fprintf(stderr, "rec=");
{
Further libssl size_t-ify of reading Writing still to be done Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 19:05:25 +08:00
size_t z;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
for (z = 0; z < rec->length; z++)
fprintf(stderr, "%02X ", rec->data[z]);
fprintf(stderr, "\n");
}
#endif
if (!SSL_IS_DTLS(ssl)) {
for (i = 7; i >= 0; i--) {
++seq[i];
if (seq[i] != 0)
break;
}
}
Remove outdated DEBUG flags. Add -DBIO_DEBUG to --strict-warnings. Remove comments about outdated debugging ifdef guards. Remove md_rand ifdef guarding an assert; it doesn't seem used. Remove the conf guards in conf_api since we use OPENSSL_assert, not assert. For pkcs12 stuff put OPENSSL_ in front of the macro name. Merge TLS_DEBUG into SSL_DEBUG. Various things just turned on/off asserts, mainly for checking non-NULL arguments, which is now removed: camellia, bn_ctx, crypto/modes. Remove some old debug code, that basically just printed things to stderr: DEBUG_PRINT_UNKNOWN_CIPHERSUITES, DEBUG_ZLIB, OPENSSL_RI_DEBUG, RL_DEBUG, RSA_DEBUG, SCRYPT_DEBUG. Remove OPENSSL_SSL_DEBUG_BROKEN_PROTOCOL. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-19 00:33:21 +08:00
#ifdef SSL_DEBUG
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
{
unsigned int z;
for (z = 0; z < md_size; z++)
fprintf(stderr, "%02X ", md[z]);
fprintf(stderr, "\n");
}
#endif
Convert the mac functions to just return 1 for success and 0 for failure Previously they return -1 for failure or the size of the mac. But the size was never used anywhere. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:44:28 +08:00
return 1;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
/*-
* ssl3_cbc_remove_padding removes padding from the decrypted, SSLv3, CBC
* record in |rec| by updating |rec->length| in constant time.
*
* block_size: the block size of the cipher used to encrypt the record.
* returns:
* 0: (in non-constant time) if the record is publicly invalid.
* 1: if the padding was valid
* -1: otherwise.
*/
Remove unused parameters from internal functions Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-14 11:33:56 +08:00
int ssl3_cbc_remove_padding(SSL3_RECORD *rec,
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
size_t block_size, size_t mac_size)
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
{
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
size_t padding_length;
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
size_t good;
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
const size_t overhead = 1 /* padding length byte */ + mac_size;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
/*
* These lengths are all public so we can test them in non-constant time.
*/
if (overhead > rec->length)
return 0;
padding_length = rec->data[rec->length - 1];
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
good = constant_time_ge_s(rec->length, padding_length + overhead);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
/* SSLv3 requires that the padding is minimal. */
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
good &= constant_time_ge_s(block_size, padding_length + 1);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
rec->length -= good & (padding_length + 1);
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
return constant_time_select_int_s(good, 1, -1);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
/*-
* tls1_cbc_remove_padding removes the CBC padding from the decrypted, TLS, CBC
* record in |rec| in constant time and returns 1 if the padding is valid and
* -1 otherwise. It also removes any explicit IV from the start of the record
* without leaking any timing about whether there was enough space after the
* padding was removed.
*
* block_size: the block size of the cipher used to encrypt the record.
* returns:
* 0: (in non-constant time) if the record is publicly invalid.
* 1: if the padding was valid
* -1: otherwise.
*/
int tls1_cbc_remove_padding(const SSL *s,
SSL3_RECORD *rec,
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
size_t block_size, size_t mac_size)
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
{
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
size_t good;
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
size_t padding_length, to_check, i;
const size_t overhead = 1 /* padding length byte */ + mac_size;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
/* Check if version requires explicit IV */
if (SSL_USE_EXPLICIT_IV(s)) {
/*
* These lengths are all public so we can test them in non-constant
* time.
*/
if (overhead + block_size > rec->length)
return 0;
/* We can now safely skip explicit IV */
rec->data += block_size;
rec->input += block_size;
rec->length -= block_size;
rec->orig_len -= block_size;
} else if (overhead > rec->length)
return 0;
padding_length = rec->data[rec->length - 1];
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
if (EVP_CIPHER_flags(EVP_CIPHER_CTX_cipher(s->enc_read_ctx)) &
EVP_CIPH_FLAG_AEAD_CIPHER) {
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
/* padding is already verified */
rec->length -= padding_length + 1;
return 1;
}
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
good = constant_time_ge_s(rec->length, overhead + padding_length);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
/*
* The padding consists of a length byte at the end of the record and
* then that many bytes of padding, all with the same value as the length
* byte. Thus, with the length byte included, there are i+1 bytes of
* padding. We can't check just |padding_length+1| bytes because that
* leaks decrypted information. Therefore we always have to check the
* maximum amount of padding possible. (Again, the length of the record
* is public information so we can use it.)
*/
Fix test of first of 255 CBC padding bytes. Thanks to Peter Gijsels for pointing out that if a CBC record has 255 bytes of padding, the first was not being checked. (This is an import of change 80842bdb from BoringSSL.) Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/1431)
2016-08-09 04:36:55 +08:00
to_check = 256; /* maximum amount of padding, inc length byte. */
if (to_check > rec->length)
to_check = rec->length;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
for (i = 0; i < to_check; i++) {
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
unsigned char mask = constant_time_ge_8_s(padding_length, i);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
unsigned char b = rec->data[rec->length - 1 - i];
/*
* The final |padding_length+1| bytes should all have the value
* |padding_length|. Therefore the XOR should be zero.
*/
good &= ~(mask & (padding_length ^ b));
}
/*
* If any of the final |padding_length+1| bytes had the wrong value, one
* or more of the lower eight bits of |good| will be cleared.
*/
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
good = constant_time_eq_s(0xff, good & 0xff);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
rec->length -= good & (padding_length + 1);
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
return constant_time_select_int_s(good, 1, -1);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
/*-
* ssl3_cbc_copy_mac copies |md_size| bytes from the end of |rec| to |out| in
* constant time (independent of the concrete value of rec->length, which may
* vary within a 256-byte window).
*
* ssl3_cbc_remove_padding or tls1_cbc_remove_padding must be called prior to
* this function.
*
* On entry:
* rec->orig_len >= md_size
* md_size <= EVP_MAX_MD_SIZE
*
* If CBC_MAC_ROTATE_IN_PLACE is defined then the rotation is performed with
* variable accesses in a 64-byte-aligned buffer. Assuming that this fits into
* a single or pair of cache-lines, then the variable memory accesses don't
* actually affect the timing. CPUs with smaller cache-lines [if any] are
* not multi-core and are not considered vulnerable to cache-timing attacks.
*/
#define CBC_MAC_ROTATE_IN_PLACE
void ssl3_cbc_copy_mac(unsigned char *out,
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
const SSL3_RECORD *rec, size_t md_size)
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
{
#if defined(CBC_MAC_ROTATE_IN_PLACE)
unsigned char rotated_mac_buf[64 + EVP_MAX_MD_SIZE];
unsigned char *rotated_mac;
#else
unsigned char rotated_mac[EVP_MAX_MD_SIZE];
#endif
/*
* mac_end is the index of |rec->data| just after the end of the MAC.
*/
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
size_t mac_end = rec->length;
size_t mac_start = mac_end - md_size;
Replace div-spoiler hack with simpler code This comes from a comment in GH issue #1027. Andy wrote the code, Rich made the PR. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2253)
2017-01-19 01:12:34 +08:00
size_t in_mac;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
/*
* scan_start contains the number of bytes that we can ignore because the
* MAC's position can only vary by 255 bytes.
*/
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
size_t scan_start = 0;
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
size_t i, j;
size_t rotate_offset;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
OPENSSL_assert(rec->orig_len >= md_size);
OPENSSL_assert(md_size <= EVP_MAX_MD_SIZE);
#if defined(CBC_MAC_ROTATE_IN_PLACE)
rotated_mac = rotated_mac_buf + ((0 - (size_t)rotated_mac_buf) & 63);
#endif
/* This information is public so it's safe to branch based on it. */
if (rec->orig_len > md_size + 255 + 1)
scan_start = rec->orig_len - (md_size + 255 + 1);
Replace div-spoiler hack with simpler code This comes from a comment in GH issue #1027. Andy wrote the code, Rich made the PR. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2253)
2017-01-19 01:12:34 +08:00
in_mac = 0;
rotate_offset = 0;
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
memset(rotated_mac, 0, md_size);
for (i = scan_start, j = 0; i < rec->orig_len; i++) {
Replace div-spoiler hack with simpler code This comes from a comment in GH issue #1027. Andy wrote the code, Rich made the PR. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2253)
2017-01-19 01:12:34 +08:00
size_t mac_started = constant_time_eq_s(i, mac_start);
size_t mac_ended = constant_time_lt_s(i, mac_end);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
unsigned char b = rec->data[i];
Replace div-spoiler hack with simpler code This comes from a comment in GH issue #1027. Andy wrote the code, Rich made the PR. Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/2253)
2017-01-19 01:12:34 +08:00
in_mac |= mac_started;
in_mac &= mac_ended;
rotate_offset |= j & mac_started;
rotated_mac[j++] |= b & in_mac;
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
j &= constant_time_lt_s(j, md_size);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
/* Now rotate the MAC */
#if defined(CBC_MAC_ROTATE_IN_PLACE)
j = 0;
for (i = 0; i < md_size; i++) {
/* in case cache-line is 32 bytes, touch second line */
((volatile unsigned char *)rotated_mac)[rotate_offset ^ 32];
out[j++] = rotated_mac[rotate_offset++];
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
rotate_offset &= constant_time_lt_s(rotate_offset, md_size);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
#else
memset(out, 0, md_size);
rotate_offset = md_size - rotate_offset;
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
rotate_offset &= constant_time_lt_s(rotate_offset, md_size);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
for (i = 0; i < md_size; i++) {
for (j = 0; j < md_size; j++)
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
out[j] |= rotated_mac[i] & constant_time_eq_8_s(j, rotate_offset);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
rotate_offset++;
Provide some constant time functions for dealing with size_t values Also implement the using of them Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-20 00:13:13 +08:00
rotate_offset &= constant_time_lt_s(rotate_offset, md_size);
Move more SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 01:14:43 +08:00
}
#endif
}
Fix DTLS replay protection The DTLS implementation provides some protection against replay attacks in accordance with RFC6347 section 4.1.2.6. A sliding "window" of valid record sequence numbers is maintained with the "right" hand edge of the window set to the highest sequence number we have received so far. Records that arrive that are off the "left" hand edge of the window are rejected. Records within the window are checked against a list of records received so far. If we already received it then we also reject the new record. If we have not already received the record, or the sequence number is off the right hand edge of the window then we verify the MAC of the record. If MAC verification fails then we discard the record. Otherwise we mark the record as received. If the sequence number was off the right hand edge of the window, then we slide the window along so that the right hand edge is in line with the newly received sequence number. Records may arrive for future epochs, i.e. a record from after a CCS being sent, can arrive before the CCS does if the packets get re-ordered. As we have not yet received the CCS we are not yet in a position to decrypt or validate the MAC of those records. OpenSSL places those records on an unprocessed records queue. It additionally updates the window immediately, even though we have not yet verified the MAC. This will only occur if currently in a handshake/renegotiation. This could be exploited by an attacker by sending a record for the next epoch (which does not have to decrypt or have a valid MAC), with a very large sequence number. This means the right hand edge of the window is moved very far to the right, and all subsequent legitimate packets are dropped causing a denial of service. A similar effect can be achieved during the initial handshake. In this case there is no MAC key negotiated yet. Therefore an attacker can send a message for the current epoch with a very large sequence number. The code will process the record as normal. If the hanshake message sequence number (as opposed to the record sequence number that we have been talking about so far) is in the future then the injected message is bufferred to be handled later, but the window is still updated. Therefore all subsequent legitimate handshake records are dropped. This aspect is not considered a security issue because there are many ways for an attacker to disrupt the initial handshake and prevent it from completing successfully (e.g. injection of a handshake message will cause the Finished MAC to fail and the handshake to be aborted). This issue comes about as a result of trying to do replay protection, but having no integrity mechanism in place yet. Does it even make sense to have replay protection in epoch 0? That issue isn't addressed here though. This addressed an OCAP Audit issue. CVE-2016-2181 Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-01 22:20:33 +08:00
int dtls1_process_record(SSL *s, DTLS1_BITMAP *bitmap)
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
{
int i, al;
int enc_err;
SSL_SESSION *sess;
SSL3_RECORD *rr;
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
int imac_size;
size_t mac_size;
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
unsigned char md[EVP_MAX_MD_SIZE];
rr = RECORD_LAYER_get_rrec(&s->rlayer);
sess = s->session;
/*
* At this point, s->packet_length == SSL3_RT_HEADER_LNGTH + rr->length,
* and we have that many bytes in s->packet
*/
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
rr->input = &(RECORD_LAYER_get_packet(&s->rlayer)[DTLS1_RT_HEADER_LENGTH]);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/*
* ok, we can now read from 's->packet' data into 'rr' rr->input points
* at rr->length bytes, which need to be copied into rr->data by either
* the decryption or by the decompression When the data is 'copied' into
* the rr->data buffer, rr->input will be pointed at the new buffer
*/
/*
* We now have - encrypted [ MAC [ compressed [ plain ] ] ] rr->length
* bytes of encrypted compressed stuff.
*/
/* check is not needed I believe */
if (rr->length > SSL3_RT_MAX_ENCRYPTED_LENGTH) {
al = SSL_AD_RECORD_OVERFLOW;
SSLerr(SSL_F_DTLS1_PROCESS_RECORD, SSL_R_ENCRYPTED_LENGTH_TOO_LONG);
goto f_err;
}
/* decrypt in place in 'rr->input' */
rr->data = rr->input;
rr->orig_len = rr->length;
Don't change the state of the ETM flags until CCS processing In 1.1.0 changing the ciphersuite during a renegotiation can result in a crash leading to a DoS attack. In master this does not occur with TLS (instead you get an internal error, which is still wrong but not a security issue) - but the problem still exists in the DTLS code. The problem is caused by changing the flag indicating whether to use ETM or not immediately on negotiation of ETM, rather than at CCS. Therefore, during a renegotiation, if the ETM state is changing (usually due to a change of ciphersuite), then an error/crash will occur. Due to the fact that there are separate CCS messages for read and write we actually now need two flags to determine whether to use ETM or not. CVE-2017-3733 Reviewed-by: Richard Levitte <levitte@openssl.org>
2017-02-03 22:06:20 +08:00
if (SSL_READ_ETM(s) && s->read_hash) {
Fix encrypt-then-mac implementation for DTLS OpenSSL 1.1.0 will negotiate EtM on DTLS but will then not actually *do* it. If we use DTLSv1.2 that will hopefully be harmless since we'll tend to use an AEAD ciphersuite anyway. But if we're using DTLSv1, then we certainly will end up using CBC, so EtM is relevant — and we fail to interoperate with anything that implements EtM correctly. Fixing it in HEAD and 1.1.0c will mean that 1.1.0[ab] are incompatible with 1.1.0c+... for the limited case of non-AEAD ciphers, where they're *already* incompatible with other implementations due to this bug anyway. That seems reasonable enough, so let's do it. The only alternative is just to turn it off for ever... which *still* leaves 1.0.0[ab] failing to communicate with non-OpenSSL implementations anyway. Tested against itself as well as against GnuTLS both with and without EtM. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
2016-10-13 06:12:04 +08:00
unsigned char *mac;
mac_size = EVP_MD_CTX_size(s->read_hash);
OPENSSL_assert(mac_size <= EVP_MAX_MD_SIZE);
if (rr->orig_len < mac_size) {
al = SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_DTLS1_PROCESS_RECORD, SSL_R_LENGTH_TOO_SHORT);
goto f_err;
}
rr->length -= mac_size;
mac = rr->data + rr->length;
i = s->method->ssl3_enc->mac(s, rr, md, 0 /* not send */ );
Convert the mac functions to just return 1 for success and 0 for failure Previously they return -1 for failure or the size of the mac. But the size was never used anywhere. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:44:28 +08:00
if (i == 0 || CRYPTO_memcmp(md, mac, (size_t)mac_size) != 0) {
Fix encrypt-then-mac implementation for DTLS OpenSSL 1.1.0 will negotiate EtM on DTLS but will then not actually *do* it. If we use DTLSv1.2 that will hopefully be harmless since we'll tend to use an AEAD ciphersuite anyway. But if we're using DTLSv1, then we certainly will end up using CBC, so EtM is relevant — and we fail to interoperate with anything that implements EtM correctly. Fixing it in HEAD and 1.1.0c will mean that 1.1.0[ab] are incompatible with 1.1.0c+... for the limited case of non-AEAD ciphers, where they're *already* incompatible with other implementations due to this bug anyway. That seems reasonable enough, so let's do it. The only alternative is just to turn it off for ever... which *still* leaves 1.0.0[ab] failing to communicate with non-OpenSSL implementations anyway. Tested against itself as well as against GnuTLS both with and without EtM. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org>
2016-10-13 06:12:04 +08:00
al = SSL_AD_BAD_RECORD_MAC;
SSLerr(SSL_F_DTLS1_PROCESS_RECORD,
SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC);
goto f_err;
}
}
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
enc_err = s->method->ssl3_enc->enc(s, rr, 1, 0);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/*-
* enc_err is:
* 0: (in non-constant time) if the record is publically invalid.
* 1: if the padding is valid
* -1: if the padding is invalid
*/
if (enc_err == 0) {
/* For DTLS we simply ignore bad packets. */
rr->length = 0;
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
RECORD_LAYER_reset_packet_length(&s->rlayer);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
goto err;
}
Remove outdated DEBUG flags. Add -DBIO_DEBUG to --strict-warnings. Remove comments about outdated debugging ifdef guards. Remove md_rand ifdef guarding an assert; it doesn't seem used. Remove the conf guards in conf_api since we use OPENSSL_assert, not assert. For pkcs12 stuff put OPENSSL_ in front of the macro name. Merge TLS_DEBUG into SSL_DEBUG. Various things just turned on/off asserts, mainly for checking non-NULL arguments, which is now removed: camellia, bn_ctx, crypto/modes. Remove some old debug code, that basically just printed things to stderr: DEBUG_PRINT_UNKNOWN_CIPHERSUITES, DEBUG_ZLIB, OPENSSL_RI_DEBUG, RL_DEBUG, RSA_DEBUG, SCRYPT_DEBUG. Remove OPENSSL_SSL_DEBUG_BROKEN_PROTOCOL. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-19 00:33:21 +08:00
#ifdef SSL_DEBUG
Further libssl size_t-ify of reading Writing still to be done Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 19:05:25 +08:00
printf("dec %ld\n", rr->length);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
{
Further libssl size_t-ify of reading Writing still to be done Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 19:05:25 +08:00
size_t z;
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
for (z = 0; z < rr->length; z++)
printf("%02X%c", rr->data[z], ((z + 1) % 16) ? ' ' : '\n');
}
printf("\n");
#endif
/* r->length is now the compressed data plus mac */
Don't change the state of the ETM flags until CCS processing In 1.1.0 changing the ciphersuite during a renegotiation can result in a crash leading to a DoS attack. In master this does not occur with TLS (instead you get an internal error, which is still wrong but not a security issue) - but the problem still exists in the DTLS code. The problem is caused by changing the flag indicating whether to use ETM or not immediately on negotiation of ETM, rather than at CCS. Therefore, during a renegotiation, if the ETM state is changing (usually due to a change of ciphersuite), then an error/crash will occur. Due to the fact that there are separate CCS messages for read and write we actually now need two flags to determine whether to use ETM or not. CVE-2017-3733 Reviewed-by: Richard Levitte <levitte@openssl.org>
2017-02-03 22:06:20 +08:00
if ((sess != NULL) && !SSL_READ_ETM(s) &&
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
(s->enc_read_ctx != NULL) && (EVP_MD_CTX_md(s->read_hash) != NULL)) {
/* s->read_hash != NULL => mac_size != -1 */
unsigned char *mac = NULL;
unsigned char mac_tmp[EVP_MAX_MD_SIZE];
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
/* TODO(size_t): Convert this to do size_t properly */
imac_size = EVP_MD_CTX_size(s->read_hash);
if (imac_size < 0) {
al = SSL_AD_INTERNAL_ERROR;
SSLerr(SSL_F_DTLS1_PROCESS_RECORD, ERR_LIB_EVP);
goto f_err;
}
mac_size = (size_t)imac_size;
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
OPENSSL_assert(mac_size <= EVP_MAX_MD_SIZE);
/*
* orig_len is the length of the record before any padding was
* removed. This is public information, as is the MAC in use,
* therefore we can safely process the record in a different amount
* of time if it's too short to possibly contain a MAC.
*/
if (rr->orig_len < mac_size ||
/* CBC records must have a padding length byte too. */
(EVP_CIPHER_CTX_mode(s->enc_read_ctx) == EVP_CIPH_CBC_MODE &&
rr->orig_len < mac_size + 1)) {
al = SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_DTLS1_PROCESS_RECORD, SSL_R_LENGTH_TOO_SHORT);
goto f_err;
}
if (EVP_CIPHER_CTX_mode(s->enc_read_ctx) == EVP_CIPH_CBC_MODE) {
/*
* We update the length so that the TLS header bytes can be
* constructed correctly but we need to extract the MAC in
* constant time from within the record, without leaking the
* contents of the padding bytes.
*/
mac = mac_tmp;
ssl3_cbc_copy_mac(mac_tmp, rr, mac_size);
rr->length -= mac_size;
} else {
/*
* In this case there's no padding, so |rec->orig_len| equals
* |rec->length| and we checked that there's enough bytes for
* |mac_size| above.
*/
rr->length -= mac_size;
mac = &rr->data[rr->length];
}
Implement write pipeline support in libssl Use the new pipeline cipher capability to encrypt multiple records being written out all in one go. Two new SSL/SSL_CTX parameters can be used to control how this works: max_pipelines and split_send_fragment. max_pipelines defines the maximum number of pipelines that can ever be used in one go for a single connection. It must always be less than or equal to SSL_MAX_PIPELINES (currently defined to be 32). By default only one pipeline will be used (i.e. normal non-parallel operation). split_send_fragment defines how data is split up into pipelines. The number of pipelines used will be determined by the amount of data provided to the SSL_write call divided by split_send_fragment. For example if split_send_fragment is set to 2000 and max_pipelines is 4 then: SSL_write called with 0-2000 bytes == 1 pipeline used SSL_write called with 2001-4000 bytes == 2 pipelines used SSL_write called with 4001-6000 bytes == 3 pipelines used SSL_write_called with 6001+ bytes == 4 pipelines used split_send_fragment must always be less than or equal to max_send_fragment. By default it is set to be equal to max_send_fragment. This will mean that the same number of records will always be created as would have been created in the non-parallel case, although the data will be apportioned differently. In the parallel case data will be spread equally between the pipelines. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-09-22 18:12:50 +08:00
i = s->method->ssl3_enc->mac(s, rr, md, 0 /* not send */ );
Convert the mac functions to just return 1 for success and 0 for failure Previously they return -1 for failure or the size of the mac. But the size was never used anywhere. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-19 21:44:28 +08:00
if (i == 0 || mac == NULL
Convert some misc record layer functions for size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-10-04 05:15:10 +08:00
|| CRYPTO_memcmp(md, mac, mac_size) != 0)
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
enc_err = -1;
if (rr->length > SSL3_RT_MAX_COMPRESSED_LENGTH + mac_size)
enc_err = -1;
}
if (enc_err < 0) {
/* decryption failed, silently discard message */
rr->length = 0;
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
RECORD_LAYER_reset_packet_length(&s->rlayer);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
goto err;
}
/* r->length is now just compressed */
if (s->expand != NULL) {
if (rr->length > SSL3_RT_MAX_COMPRESSED_LENGTH) {
al = SSL_AD_RECORD_OVERFLOW;
SSLerr(SSL_F_DTLS1_PROCESS_RECORD,
SSL_R_COMPRESSED_LENGTH_TOO_LONG);
goto f_err;
}
Implement read pipeline support in libssl Read pipelining is controlled in a slightly different way than with write pipelining. While reading we are constrained by the number of records that the peer (and the network) can provide to us in one go. The more records we can get in one go the more opportunity we have to parallelise the processing. There are two parameters that affect this: * The number of pipelines that we are willing to process in one go. This is controlled by max_pipelines (as for write pipelining) * The size of our read buffer. A subsequent commit will provide an API for adjusting the size of the buffer. Another requirement for this to work is that "read_ahead" must be set. The read_ahead parameter will attempt to read as much data into our read buffer as the network can provide. Without this set, data is read into the read buffer on demand. Setting the max_pipelines parameter to a value greater than 1 will automatically also turn read_ahead on. Finally, the read pipelining as currently implemented will only parallelise the processing of application data records. This would only make a difference for renegotiation so is unlikely to have a significant impact. Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-01-12 22:52:35 +08:00
if (!ssl3_do_uncompress(s, rr)) {
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
al = SSL_AD_DECOMPRESSION_FAILURE;
SSLerr(SSL_F_DTLS1_PROCESS_RECORD, SSL_R_BAD_DECOMPRESSION);
goto f_err;
}
}
if (rr->length > SSL3_RT_MAX_PLAIN_LENGTH) {
al = SSL_AD_RECORD_OVERFLOW;
SSLerr(SSL_F_DTLS1_PROCESS_RECORD, SSL_R_DATA_LENGTH_TOO_LONG);
goto f_err;
}
rr->off = 0;
/*-
* So at this point the following is true
* ssl->s3->rrec.type is the type of record
* ssl->s3->rrec.length == number of bytes in record
* ssl->s3->rrec.off == offset to first valid byte
* ssl->s3->rrec.data == where to take bytes from, increment
* after use :-).
*/
/* we have pulled in a full packet so zero things */
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
RECORD_LAYER_reset_packet_length(&s->rlayer);
Fix DTLS replay protection The DTLS implementation provides some protection against replay attacks in accordance with RFC6347 section 4.1.2.6. A sliding "window" of valid record sequence numbers is maintained with the "right" hand edge of the window set to the highest sequence number we have received so far. Records that arrive that are off the "left" hand edge of the window are rejected. Records within the window are checked against a list of records received so far. If we already received it then we also reject the new record. If we have not already received the record, or the sequence number is off the right hand edge of the window then we verify the MAC of the record. If MAC verification fails then we discard the record. Otherwise we mark the record as received. If the sequence number was off the right hand edge of the window, then we slide the window along so that the right hand edge is in line with the newly received sequence number. Records may arrive for future epochs, i.e. a record from after a CCS being sent, can arrive before the CCS does if the packets get re-ordered. As we have not yet received the CCS we are not yet in a position to decrypt or validate the MAC of those records. OpenSSL places those records on an unprocessed records queue. It additionally updates the window immediately, even though we have not yet verified the MAC. This will only occur if currently in a handshake/renegotiation. This could be exploited by an attacker by sending a record for the next epoch (which does not have to decrypt or have a valid MAC), with a very large sequence number. This means the right hand edge of the window is moved very far to the right, and all subsequent legitimate packets are dropped causing a denial of service. A similar effect can be achieved during the initial handshake. In this case there is no MAC key negotiated yet. Therefore an attacker can send a message for the current epoch with a very large sequence number. The code will process the record as normal. If the hanshake message sequence number (as opposed to the record sequence number that we have been talking about so far) is in the future then the injected message is bufferred to be handled later, but the window is still updated. Therefore all subsequent legitimate handshake records are dropped. This aspect is not considered a security issue because there are many ways for an attacker to disrupt the initial handshake and prevent it from completing successfully (e.g. injection of a handshake message will cause the Finished MAC to fail and the handshake to be aborted). This issue comes about as a result of trying to do replay protection, but having no integrity mechanism in place yet. Does it even make sense to have replay protection in epoch 0? That issue isn't addressed here though. This addressed an OCAP Audit issue. CVE-2016-2181 Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-01 22:20:33 +08:00
/* Mark receipt of record. */
dtls1_record_bitmap_update(s, bitmap);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
return (1);
f_err:
ssl3_send_alert(s, SSL3_AL_FATAL, al);
err:
return (0);
}
/*
More typo fixes Fix some comments too [skip ci] Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/3069)
2017-03-29 05:57:28 +08:00
* Retrieve a buffered record that belongs to the current epoch, i.e. processed
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
*/
#define dtls1_get_processed_record(s) \
dtls1_retrieve_buffered_record((s), \
Moved processed_rcds and unprocessed_rcds from s->d1 to s->rlayer.d Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-04 00:05:28 +08:00
&(DTLS_RECORD_LAYER_get_processed_rcds(&s->rlayer)))
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/*-
* Call this to get a new input record.
* It will return <= 0 if more data is needed, normally due to an error
* or non-blocking IO.
* When it finishes, one packet has been decoded and can be found in
* ssl->s3->rrec.type - is the type of record
* ssl->s3->rrec.data, - data
* ssl->s3->rrec.length, - number of bytes
*/
/* used only by dtls1_read_bytes */
int dtls1_get_record(SSL *s)
{
int ssl_major, ssl_minor;
Convert record layer to use size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 16:24:19 +08:00
int rret;
size_t more, n;
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
SSL3_RECORD *rr;
unsigned char *p = NULL;
unsigned short version;
DTLS1_BITMAP *bitmap;
unsigned int is_next_epoch;
rr = RECORD_LAYER_get_rrec(&s->rlayer);
Fix DTLS unprocessed records bug During a DTLS handshake we may get records destined for the next epoch arrive before we have processed the CCS. In that case we can't decrypt or verify the record yet, so we buffer it for later use. When we do receive the CCS we work through the queue of unprocessed records and process them. Unfortunately the act of processing wipes out any existing packet data that we were still working through. This includes any records from the new epoch that were in the same packet as the CCS. We should only process the buffered records if we've not got any data left. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-05 16:51:08 +08:00
again:
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/*
* The epoch may have changed. If so, process all the pending records.
* This is a non-blocking operation.
*/
Fix DTLS replay protection The DTLS implementation provides some protection against replay attacks in accordance with RFC6347 section 4.1.2.6. A sliding "window" of valid record sequence numbers is maintained with the "right" hand edge of the window set to the highest sequence number we have received so far. Records that arrive that are off the "left" hand edge of the window are rejected. Records within the window are checked against a list of records received so far. If we already received it then we also reject the new record. If we have not already received the record, or the sequence number is off the right hand edge of the window then we verify the MAC of the record. If MAC verification fails then we discard the record. Otherwise we mark the record as received. If the sequence number was off the right hand edge of the window, then we slide the window along so that the right hand edge is in line with the newly received sequence number. Records may arrive for future epochs, i.e. a record from after a CCS being sent, can arrive before the CCS does if the packets get re-ordered. As we have not yet received the CCS we are not yet in a position to decrypt or validate the MAC of those records. OpenSSL places those records on an unprocessed records queue. It additionally updates the window immediately, even though we have not yet verified the MAC. This will only occur if currently in a handshake/renegotiation. This could be exploited by an attacker by sending a record for the next epoch (which does not have to decrypt or have a valid MAC), with a very large sequence number. This means the right hand edge of the window is moved very far to the right, and all subsequent legitimate packets are dropped causing a denial of service. A similar effect can be achieved during the initial handshake. In this case there is no MAC key negotiated yet. Therefore an attacker can send a message for the current epoch with a very large sequence number. The code will process the record as normal. If the hanshake message sequence number (as opposed to the record sequence number that we have been talking about so far) is in the future then the injected message is bufferred to be handled later, but the window is still updated. Therefore all subsequent legitimate handshake records are dropped. This aspect is not considered a security issue because there are many ways for an attacker to disrupt the initial handshake and prevent it from completing successfully (e.g. injection of a handshake message will cause the Finished MAC to fail and the handshake to be aborted). This issue comes about as a result of trying to do replay protection, but having no integrity mechanism in place yet. Does it even make sense to have replay protection in epoch 0? That issue isn't addressed here though. This addressed an OCAP Audit issue. CVE-2016-2181 Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-01 22:20:33 +08:00
if (!dtls1_process_buffered_records(s))
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
return -1;
/* if we're renegotiating, then there may be buffered records */
if (dtls1_get_processed_record(s))
return 1;
/* get something from the wire */
Fix DTLS unprocessed records bug During a DTLS handshake we may get records destined for the next epoch arrive before we have processed the CCS. In that case we can't decrypt or verify the record yet, so we buffer it for later use. When we do receive the CCS we work through the queue of unprocessed records and process them. Unfortunately the act of processing wipes out any existing packet data that we were still working through. This includes any records from the new epoch that were in the same packet as the CCS. We should only process the buffered records if we've not got any data left. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-05 16:51:08 +08:00
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/* check if we have the header */
Move s->rstate to s->rlayer.rstate Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 18:48:28 +08:00
if ((RECORD_LAYER_get_rstate(&s->rlayer) != SSL_ST_READ_BODY) ||
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
(RECORD_LAYER_get_packet_length(&s->rlayer) < DTLS1_RT_HEADER_LENGTH)) {
Convert record layer to use size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 16:24:19 +08:00
rret = ssl3_read_n(s, DTLS1_RT_HEADER_LENGTH,
SSL3_BUFFER_get_len(&s->rlayer.rbuf), 0, 1, &n);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/* read timeout is handled by dtls1_read_bytes */
Convert record layer to use size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 16:24:19 +08:00
if (rret <= 0)
return rret; /* error or non-blocking */
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/* this packet contained a partial record, dump it */
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
if (RECORD_LAYER_get_packet_length(&s->rlayer) !=
DTLS1_RT_HEADER_LENGTH) {
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
RECORD_LAYER_reset_packet_length(&s->rlayer);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
goto again;
}
Move s->rstate to s->rlayer.rstate Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 18:48:28 +08:00
RECORD_LAYER_set_rstate(&s->rlayer, SSL_ST_READ_BODY);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
p = RECORD_LAYER_get_packet(&s->rlayer);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
if (s->msg_callback)
s->msg_callback(0, 0, SSL3_RT_HEADER, p, DTLS1_RT_HEADER_LENGTH,
s, s->msg_callback_arg);
/* Pull apart the header into the DTLS1_RECORD */
rr->type = *(p++);
ssl_major = *(p++);
ssl_minor = *(p++);
version = (ssl_major << 8) | ssl_minor;
/* sequence number is 64 bits, with top 2 bytes = epoch */
n2s(p, rr->epoch);
Move read_sequence and write_sequence from s->s3 to s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 22:26:50 +08:00
memcpy(&(RECORD_LAYER_get_read_sequence(&s->rlayer)[2]), p, 6);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
p += 6;
n2s(p, rr->length);
/* Lets check version */
if (!s->first_packet) {
if (version != s->version) {
/* unexpected version, silently discard */
rr->length = 0;
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
RECORD_LAYER_reset_packet_length(&s->rlayer);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
goto again;
}
}
if ((version & 0xff00) != (s->version & 0xff00)) {
/* wrong version, silently discard record */
rr->length = 0;
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
RECORD_LAYER_reset_packet_length(&s->rlayer);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
goto again;
}
if (rr->length > SSL3_RT_MAX_ENCRYPTED_LENGTH) {
/* record too long, silently discard it */
rr->length = 0;
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
RECORD_LAYER_reset_packet_length(&s->rlayer);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
goto again;
}
Move s->rstate to s->rlayer.rstate Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 18:48:28 +08:00
/* now s->rlayer.rstate == SSL_ST_READ_BODY */
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
}
Move s->rstate to s->rlayer.rstate Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 18:48:28 +08:00
/* s->rlayer.rstate == SSL_ST_READ_BODY, get and decode the data */
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
if (rr->length >
RECORD_LAYER_get_packet_length(&s->rlayer) - DTLS1_RT_HEADER_LENGTH) {
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/* now s->packet_length == DTLS1_RT_HEADER_LENGTH */
Convert record layer to use size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 16:24:19 +08:00
more = rr->length;
rret = ssl3_read_n(s, more, more, 1, 1, &n);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/* this packet contained a partial record, dump it */
Convert record layer to use size_t Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-09-06 16:24:19 +08:00
if (rret <= 0 || n != more) {
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
rr->length = 0;
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
RECORD_LAYER_reset_packet_length(&s->rlayer);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
goto again;
}
/*
* now n == rr->length, and s->packet_length ==
* DTLS1_RT_HEADER_LENGTH + rr->length
*/
}
Move s->rstate to s->rlayer.rstate Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 18:48:28 +08:00
/* set state for later operations */
RECORD_LAYER_set_rstate(&s->rlayer, SSL_ST_READ_HEADER);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
/* match epochs. NULL means the packet is dropped on the floor */
bitmap = dtls1_get_bitmap(s, rr, &is_next_epoch);
if (bitmap == NULL) {
rr->length = 0;
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
RECORD_LAYER_reset_packet_length(&s->rlayer); /* dump this record */
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
goto again; /* get another record */
}
#ifndef OPENSSL_NO_SCTP
/* Only do replay check if no SCTP bio */
if (!BIO_dgram_is_sctp(SSL_get_rbio(s))) {
#endif
Remove remaining old listen code The old implementation of DTLSv1_listen which has now been replaced still had a few vestiges scattered throughout the code. This commit removes them. Reviewed-by: Andy Polyakov <appro@openssl.org>
2015-04-10 06:31:35 +08:00
/* Check whether this is a repeat, or aged record. */
Fix DTLS replay protection The DTLS implementation provides some protection against replay attacks in accordance with RFC6347 section 4.1.2.6. A sliding "window" of valid record sequence numbers is maintained with the "right" hand edge of the window set to the highest sequence number we have received so far. Records that arrive that are off the "left" hand edge of the window are rejected. Records within the window are checked against a list of records received so far. If we already received it then we also reject the new record. If we have not already received the record, or the sequence number is off the right hand edge of the window then we verify the MAC of the record. If MAC verification fails then we discard the record. Otherwise we mark the record as received. If the sequence number was off the right hand edge of the window, then we slide the window along so that the right hand edge is in line with the newly received sequence number. Records may arrive for future epochs, i.e. a record from after a CCS being sent, can arrive before the CCS does if the packets get re-ordered. As we have not yet received the CCS we are not yet in a position to decrypt or validate the MAC of those records. OpenSSL places those records on an unprocessed records queue. It additionally updates the window immediately, even though we have not yet verified the MAC. This will only occur if currently in a handshake/renegotiation. This could be exploited by an attacker by sending a record for the next epoch (which does not have to decrypt or have a valid MAC), with a very large sequence number. This means the right hand edge of the window is moved very far to the right, and all subsequent legitimate packets are dropped causing a denial of service. A similar effect can be achieved during the initial handshake. In this case there is no MAC key negotiated yet. Therefore an attacker can send a message for the current epoch with a very large sequence number. The code will process the record as normal. If the hanshake message sequence number (as opposed to the record sequence number that we have been talking about so far) is in the future then the injected message is bufferred to be handled later, but the window is still updated. Therefore all subsequent legitimate handshake records are dropped. This aspect is not considered a security issue because there are many ways for an attacker to disrupt the initial handshake and prevent it from completing successfully (e.g. injection of a handshake message will cause the Finished MAC to fail and the handshake to be aborted). This issue comes about as a result of trying to do replay protection, but having no integrity mechanism in place yet. Does it even make sense to have replay protection in epoch 0? That issue isn't addressed here though. This addressed an OCAP Audit issue. CVE-2016-2181 Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-01 22:20:33 +08:00
/*
* TODO: Does it make sense to have replay protection in epoch 0 where
* we have no integrity negotiated yet?
*/
Remove remaining old listen code The old implementation of DTLSv1_listen which has now been replaced still had a few vestiges scattered throughout the code. This commit removes them. Reviewed-by: Andy Polyakov <appro@openssl.org>
2015-04-10 06:31:35 +08:00
if (!dtls1_record_replay_check(s, bitmap)) {
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
rr->length = 0;
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
RECORD_LAYER_reset_packet_length(&s->rlayer); /* dump this record */
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
goto again; /* get another record */
}
#ifndef OPENSSL_NO_SCTP
}
#endif
/* just read a 0 length packet */
if (rr->length == 0)
goto again;
/*
* If this record is from the next epoch (either HM or ALERT), and a
* handshake is currently in progress, buffer it since it cannot be
Remove remaining old listen code The old implementation of DTLSv1_listen which has now been replaced still had a few vestiges scattered throughout the code. This commit removes them. Reviewed-by: Andy Polyakov <appro@openssl.org>
2015-04-10 06:31:35 +08:00
* processed at this time.
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
*/
if (is_next_epoch) {
Move in_handshake into STATEM The SSL variable |in_handshake| seems misplaced. It would be better to have it in the STATEM structure. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-10-22 20:57:18 +08:00
if ((SSL_in_init(s) || ossl_statem_get_in_handshake(s))) {
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
if (dtls1_buffer_record
Moved processed_rcds and unprocessed_rcds from s->d1 to s->rlayer.d Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-04 00:05:28 +08:00
(s, &(DTLS_RECORD_LAYER_get_unprocessed_rcds(&s->rlayer)),
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
rr->seq_num) < 0)
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
return -1;
}
rr->length = 0;
Move s->packet and s->packet_length into s->rlayer Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-03 04:55:15 +08:00
RECORD_LAYER_reset_packet_length(&s->rlayer);
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
goto again;
}
Fix DTLS replay protection The DTLS implementation provides some protection against replay attacks in accordance with RFC6347 section 4.1.2.6. A sliding "window" of valid record sequence numbers is maintained with the "right" hand edge of the window set to the highest sequence number we have received so far. Records that arrive that are off the "left" hand edge of the window are rejected. Records within the window are checked against a list of records received so far. If we already received it then we also reject the new record. If we have not already received the record, or the sequence number is off the right hand edge of the window then we verify the MAC of the record. If MAC verification fails then we discard the record. Otherwise we mark the record as received. If the sequence number was off the right hand edge of the window, then we slide the window along so that the right hand edge is in line with the newly received sequence number. Records may arrive for future epochs, i.e. a record from after a CCS being sent, can arrive before the CCS does if the packets get re-ordered. As we have not yet received the CCS we are not yet in a position to decrypt or validate the MAC of those records. OpenSSL places those records on an unprocessed records queue. It additionally updates the window immediately, even though we have not yet verified the MAC. This will only occur if currently in a handshake/renegotiation. This could be exploited by an attacker by sending a record for the next epoch (which does not have to decrypt or have a valid MAC), with a very large sequence number. This means the right hand edge of the window is moved very far to the right, and all subsequent legitimate packets are dropped causing a denial of service. A similar effect can be achieved during the initial handshake. In this case there is no MAC key negotiated yet. Therefore an attacker can send a message for the current epoch with a very large sequence number. The code will process the record as normal. If the hanshake message sequence number (as opposed to the record sequence number that we have been talking about so far) is in the future then the injected message is bufferred to be handled later, but the window is still updated. Therefore all subsequent legitimate handshake records are dropped. This aspect is not considered a security issue because there are many ways for an attacker to disrupt the initial handshake and prevent it from completing successfully (e.g. injection of a handshake message will cause the Finished MAC to fail and the handshake to be aborted). This issue comes about as a result of trying to do replay protection, but having no integrity mechanism in place yet. Does it even make sense to have replay protection in epoch 0? That issue isn't addressed here though. This addressed an OCAP Audit issue. CVE-2016-2181 Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-07-01 22:20:33 +08:00
if (!dtls1_process_record(s, bitmap)) {
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
rr->length = 0;
Indent ssl/ Run util/openssl-format-source on ssl/ Some comments and hand-formatted tables were fixed up manually by disabling auto-formatting. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-08-06 01:03:17 +08:00
RECORD_LAYER_reset_packet_length(&s->rlayer); /* dump this record */
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
goto again; /* get another record */
}
return (1);
}
Reference in New Issue Copy Permalink