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
a2a0c86bb0
openssl/ssl/record/ssl3_record.c

1629 lines
55 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
*/
#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
*/
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
void SSL3_RECORD_clear(SSL3_RECORD *r, unsigned int 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;
unsigned int 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
}
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
void SSL3_RECORD_release(SSL3_RECORD *r, unsigned int 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 int i;
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;
int left, len;
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;
}
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)
{
int ssl_major, ssl_minor, al;
int enc_err, n, i, ret = -1;
SSL3_RECORD *rr;
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];
short version;
unsigned 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
unsigned int num_recs = 0;
unsigned int max_recs;
unsigned int 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
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 {
/* 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)) {
n = ssl3_read_n(s, SSL3_RT_HEADER_LENGTH,
SSL3_BUFFER_get_len(rbuf), 0, num_recs == 0 ? 1 : 0);
if (n <= 0)
return (n); /* error or non-blocking */
RECORD_LAYER_set_rstate(&s->rlayer, SSL_ST_READ_BODY);
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
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 whether this is a regular record or an SSLv2 style record.
Make the checks for an SSLv2 style record stricter SSLv2 is no longer supported in 1.1.0, however we *do* still accept an SSLv2 style ClientHello, as long as we then subsequently negotiate a protocol version >= SSLv3. The record format for SSLv2 style ClientHellos is quite different to SSLv3+. We only accept this format in the first record of an initial ClientHello. Previously we checked this by confirming s->first_packet is set and s->server is true. However, this really only tells us that we are dealing with an initial ClientHello, not that it is the first record (s->first_packet is badly named...it really means this is the first message). To check this is the first record of the initial ClientHello we should also check that we've not received any data yet (s->init_num == 0), and that we've not had any empty records. GitHub Issue #1298 Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-07-22 21:58:19 +08:00
* The latter can only be used in the first record of an initial
* ClientHello for old clients. Initial ClientHello means
Address feedback on SSLv2 ClientHello processing Feedback on the previous SSLv2 ClientHello processing fix was that it breaks layering by reading init_num in the record layer. It also does not detect if there was a previous non-fatal warning. This is an alternative approach that directly tracks in the record layer whether this is the first record. GitHub Issue #1298 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-08-02 00:15:13 +08:00
* s->first_packet is set and s->server is true. The first record
* means s->rlayer.is_first_record is true. Probably this is
* sufficient in itself instead of s->first_packet, but I am
* cautious. We check s->read_hash and s->enc_read_ctx to ensure
* this does not apply during renegotiation.
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
*/
Make the checks for an SSLv2 style record stricter SSLv2 is no longer supported in 1.1.0, however we *do* still accept an SSLv2 style ClientHello, as long as we then subsequently negotiate a protocol version >= SSLv3. The record format for SSLv2 style ClientHellos is quite different to SSLv3+. We only accept this format in the first record of an initial ClientHello. Previously we checked this by confirming s->first_packet is set and s->server is true. However, this really only tells us that we are dealing with an initial ClientHello, not that it is the first record (s->first_packet is badly named...it really means this is the first message). To check this is the first record of the initial ClientHello we should also check that we've not received any data yet (s->init_num == 0), and that we've not had any empty records. GitHub Issue #1298 Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-07-22 21:58:19 +08:00
if (s->first_packet && s->server
Address feedback on SSLv2 ClientHello processing Feedback on the previous SSLv2 ClientHello processing fix was that it breaks layering by reading init_num in the record layer. It also does not detect if there was a previous non-fatal warning. This is an alternative approach that directly tracks in the record layer whether this is the first record. GitHub Issue #1298 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-08-02 00:15:13 +08:00
&& RECORD_LAYER_is_first_record(&s->rlayer)
Make the checks for an SSLv2 style record stricter SSLv2 is no longer supported in 1.1.0, however we *do* still accept an SSLv2 style ClientHello, as long as we then subsequently negotiate a protocol version >= SSLv3. The record format for SSLv2 style ClientHellos is quite different to SSLv3+. We only accept this format in the first record of an initial ClientHello. Previously we checked this by confirming s->first_packet is set and s->server is true. However, this really only tells us that we are dealing with an initial ClientHello, not that it is the first record (s->first_packet is badly named...it really means this is the first message). To check this is the first record of the initial ClientHello we should also check that we've not received any data yet (s->init_num == 0), and that we've not had any empty records. GitHub Issue #1298 Reviewed-by: Emilia Käsper <emilia@openssl.org>
2016-07-22 21:58:19 +08:00
&& s->read_hash == NULL && s->enc_read_ctx == 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
&& (p[0] & 0x80) && (p[2] == 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
*/
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
rr[num_recs].type = SSL3_RT_HANDSHAKE;
rr[num_recs].rec_version = SSL2_VERSION;
rr[num_recs].length = ((p[0] & 0x7f) << 8) | p[1];
There is only one read buffer Pipelining introduced the concept of multiple records being read in one go. Therefore we work with an array of SSL3_RECORD objects. The pipelining change erroneously made a change in ssl3_get_record() to apply the current record offset to the SSL3_BUFFER we are using for reading. This is wrong - there is only ever one read buffer. This reverts that change. In practice this should make little difference because the code block in question is only ever used when we are processing a single record. Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
2016-04-26 23:00:09 +08:00
if (rr[num_recs].length > SSL3_BUFFER_get_len(rbuf)
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
- SSL2_RT_HEADER_LENGTH) {
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
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 (rr[num_recs].length < MIN_SSL2_RECORD_LEN) {
al = SSL_AD_HANDSHAKE_FAILURE;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_LENGTH_TOO_SHORT);
goto f_err;
}
} else {
/* SSLv3+ style record */
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 */
rr[num_recs].type = *(p++);
ssl_major = *(p++);
ssl_minor = *(p++);
version = (ssl_major << 8) | ssl_minor;
rr[num_recs].rec_version = version;
n2s(p, rr[num_recs].length);
/* Lets check version */
if (!s->first_packet && version != s->version) {
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_WRONG_VERSION_NUMBER);
if ((s->version & 0xFF00) == (version & 0xFF00)
&& !s->enc_write_ctx && !s->write_hash) {
if (rr->type == SSL3_RT_ALERT) {
/*
* 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.
*/
goto 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
/*
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
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 (rr[num_recs].length >
SSL3_BUFFER_get_len(rbuf) - SSL3_RT_HEADER_LENGTH) {
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
}
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
*/
if (rr[num_recs].rec_version == SSL2_VERSION) {
i = rr[num_recs].length + SSL2_RT_HEADER_LENGTH
- SSL3_RT_HEADER_LENGTH;
} else {
i = rr[num_recs].length;
}
if (i > 0) {
/* 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
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
n = ssl3_read_n(s, i, i, 1, 0);
if (n <= 0)
return (n); /* error or non-blocking io */
}
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
/*
* At this point, s->packet_length == SSL3_RT_HEADER_LENGTH + rr->length,
* or s->packet_length == SSL2_RT_HEADER_LENGTH + rr->length
* and we have that many bytes in s->packet
*/
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 (rr[num_recs].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
rr[num_recs].input =
&(RECORD_LAYER_get_packet(&s->rlayer)[SSL2_RT_HEADER_LENGTH]);
} else {
rr[num_recs].input =
&(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
/*
* 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
*/
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
/*
* We now have - encrypted [ MAC [ compressed [ plain ] ] ] rr->length
* bytes of encrypted compressed stuff.
*/
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
/* check is not needed I believe */
if (rr[num_recs].length > SSL3_RT_MAX_ENCRYPTED_LENGTH) {
al = SSL_AD_RECORD_OVERFLOW;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_ENCRYPTED_LENGTH_TOO_LONG);
goto f_err;
}
/* decrypt in place in 'rr->input' */
rr[num_recs].data = rr[num_recs].input;
rr[num_recs].orig_len = rr[num_recs].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 */
rr[num_recs].read = 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
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 Feedback on the previous SSLv2 ClientHello processing fix was that it breaks layering by reading init_num in the record layer. It also does not detect if there was a previous non-fatal warning. This is an alternative approach that directly tracks in the record layer whether this is the first record. GitHub Issue #1298 Reviewed-by: Tim Hudson <tjh@openssl.org>
2016-08-02 00:15:13 +08:00
RECORD_LAYER_set_first_record(&s->rlayer, 0);
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
&& rr[num_recs-1].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))
& 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.
*/
if (SSL_USE_ETM(s) && s->read_hash) {
unsigned char *mac;
mac_size = EVP_MD_CTX_size(s->read_hash);
OPENSSL_assert(mac_size <= 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
for (j = 0; j < num_recs; j++) {
if (rr[j].length < mac_size) {
al = SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_LENGTH_TOO_SHORT);
goto f_err;
}
rr[j].length -= mac_size;
mac = rr[j].data + rr[j].length;
i = s->method->ssl3_enc->mac(s, &rr[j], md, 0 /* not send */ );
if (i < 0 || CRYPTO_memcmp(md, mac, (size_t)mac_size) != 0) {
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
}
}
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);
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) {
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
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("dec %d\n", rr->length);
{
unsigned int z;
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 */
if ((sess != NULL) &&
(s->enc_read_ctx != NULL) &&
(EVP_MD_CTX_md(s->read_hash) != NULL) && !SSL_USE_ETM(s)) {
/* 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);
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++) {
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
*/
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 (rr[j].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[j].orig_len < mac_size + 1)) {
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;
ssl3_cbc_copy_mac(mac_tmp, &rr[j], mac_size);
rr[j].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[j].length -= mac_size;
mac = &rr[j].data[rr[j].length];
}
i = s->method->ssl3_enc->mac(s, &rr[j], md, 0 /* not send */ );
if (i < 0 || mac == NULL
|| CRYPTO_memcmp(md, mac, (size_t)mac_size) != 0)
enc_err = -1;
if (rr->length > SSL3_RT_MAX_COMPRESSED_LENGTH + mac_size)
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) {
/*
* 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++) {
/* rr[j].length is now just compressed */
if (s->expand != NULL) {
if (rr[j].length > SSL3_RT_MAX_COMPRESSED_LENGTH) {
al = SSL_AD_RECORD_OVERFLOW;
SSLerr(SSL_F_SSL3_GET_RECORD, SSL_R_COMPRESSED_LENGTH_TOO_LONG);
goto f_err;
}
if (!ssl3_do_uncompress(s, &rr[j])) {
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
if (rr[j].length > SSL3_RT_MAX_PLAIN_LENGTH) {
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;
}
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
rr[j].off = 0;
/*-
* So at this point the following is true
* rr[j].type is the type of record
* rr[j].length == number of bytes in record
* rr[j].off == offset to first valid byte
* rr[j].data == where to take bytes from, increment after use :-).
*/
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 */
if (rr[j].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)
> 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
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;
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,
SSL3_RT_MAX_PLAIN_LENGTH, rr->data,
(int)rr->length);
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;
i = COMP_compress_block(ssl->compress, wr->data,
SSL3_RT_MAX_COMPRESSED_LENGTH,
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.
*/
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
int ssl3_enc(SSL *s, SSL3_RECORD *inrecs, unsigned int n_recs, int send)
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;
unsigned long l;
int bs, i, mac_size = 0;
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;
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 (send) {
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;
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 */
if ((bs != 1) && send) {
i = bs - ((int)l % bs);
/* 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;
rec->input[l - 1] = (i - 1);
}
if (!send) {
if (l == 0 || l % bs != 0)
return 0;
/* otherwise, rec->length >= bs */
}
if (EVP_Cipher(ds, rec->data, rec->input, l) < 1)
return -1;
if (EVP_MD_CTX_md(s->read_hash) != NULL)
mac_size = EVP_MD_CTX_size(s->read_hash);
if ((bs != 1) && !send)
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);
}
/*-
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.
*/
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
int tls1_enc(SSL *s, SSL3_RECORD *recs, unsigned int n_recs, int send)
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];
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 bs, i, j, k, pad = 0, ret, mac_size = 0;
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
unsigned int ctr;
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 (send) {
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))
& 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))
& EVP_CIPH_FLAG_AEAD_CIPHER) {
unsigned char *seq;
seq = send ? RECORD_LAYER_get_write_sequence(&s->rlayer)
: RECORD_LAYER_get_read_sequence(&s->rlayer);
if (SSL_IS_DTLS(s)) {
/* DTLS does not support pipelining */
unsigned char dtlsseq[9], *p = dtlsseq;
s2n(send ? DTLS_RECORD_LAYER_get_w_epoch(&s->rlayer) :
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);
buf[ctr][11] = recs[ctr].length >> 8;
buf[ctr][12] = recs[ctr].length & 0xff;
pad = EVP_CIPHER_CTX_ctrl(ds, EVP_CTRL_AEAD_TLS1_AAD,
EVP_AEAD_TLS1_AAD_LEN, buf[ctr]);
if (pad <= 0)
return -1;
if (send) {
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
}
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
} else if ((bs != 1) && send) {
i = bs - ((int)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
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 need to add 'i' padding bytes of value j */
j = i - 1;
for (k = (int)reclen[ctr]; k < (int)(reclen[ctr] + i); k++)
recs[ctr].input[k] = j;
reclen[ctr] += i;
recs[ctr].length += i;
}
if (!send) {
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,
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
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,
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
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,
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
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
}
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 = EVP_Cipher(ds, recs[0].data, recs[0].input, reclen[0]);
if ((EVP_CIPHER_flags(EVP_CIPHER_CTX_cipher(ds))
& EVP_CIPH_FLAG_CUSTOM_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
? (i < 0)
: (i == 0))
return -1; /* AEAD can fail to verify MAC */
CCM support. Reviewed-by: Tim Hudson <tjh@openssl.org>
2015-07-31 23:54:35 +08:00
if (send == 0) {
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;
if (!SSL_USE_ETM(s) && EVP_MD_CTX_md(s->read_hash) != NULL)
mac_size = EVP_MD_CTX_size(s->read_hash);
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 ((bs != 1) && !send) {
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);
if (tmpret == -1)
return -1;
ret &= tmpret;
}
}
if (pad && !send) {
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;
}
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 n_ssl3_mac(SSL *ssl, SSL3_RECORD *rec, unsigned char *md, int send)
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;
int npad;
int t;
if (send) {
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)
return -1;
md_size = t;
npad = (48 / md_size) * md_size;
if (!send &&
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];
unsigned j = 0;
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;
header[j++] = rec->length >> 8;
header[j++] = rec->length & 0xff;
/* 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)
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 {
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)
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
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
|| 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);
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
md_size = md_size_u;
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);
return (md_size);
}
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 tls1_mac(SSL *ssl, SSL3_RECORD *rec, unsigned char *md, int send)
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];
int stream_mac = (send ? (ssl->mac_flags & SSL_MAC_FLAG_WRITE_MAC_STREAM)
: (ssl->mac_flags & SSL_MAC_FLAG_READ_MAC_STREAM));
int t;
if (send) {
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();
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 (hmac == NULL
|| !EVP_MD_CTX_copy(hmac, hash))
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;
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;
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
s2n(send ? DTLS_RECORD_LAYER_get_w_epoch(&ssl->rlayer) :
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);
header[11] = (rec->length) >> 8;
header[12] = (rec->length) & 0xff;
if (!send && !SSL_USE_ETM(ssl) &&
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 {
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
|| 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);
Remove an OPENSSL_assert which could fail An OPENSSL_assert was being used which could fail (e.g. on a malloc failure). Reviewed-by: Rich Salz <rsalz@openssl.org>
2015-10-31 00:50:17 +08:00
return -1;
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
if (!send && !SSL_USE_ETM(ssl) && FIPS_mode())
check return values for EVP_Digest*() APIs Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-06-18 22:46:13 +08:00
if (!tls_fips_digest_extra(ssl->enc_read_ctx,
mac_ctx, rec->input,
rec->length, rec->orig_len)) {
EVP_MD_CTX_free(hmac);
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
}
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=");
{
unsigned int z;
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
return (md_size);
}
/*-
* 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,
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 block_size, unsigned mac_size)
{
unsigned padding_length, good;
const unsigned overhead = 1 /* padding length byte */ + mac_size;
/*
* 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];
good = constant_time_ge(rec->length, padding_length + overhead);
/* SSLv3 requires that the padding is minimal. */
good &= constant_time_ge(block_size, padding_length + 1);
rec->length -= good & (padding_length + 1);
return constant_time_select_int(good, 1, -1);
}
/*-
* 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,
unsigned block_size, unsigned mac_size)
{
unsigned padding_length, good, to_check, i;
const unsigned overhead = 1 /* padding length byte */ + mac_size;
/* 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];
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
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;
}
good = constant_time_ge(rec->length, overhead + padding_length);
/*
* 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++) {
unsigned char mask = constant_time_ge_8(padding_length, i);
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.
*/
good = constant_time_eq(0xff, good & 0xff);
rec->length -= good & (padding_length + 1);
return constant_time_select_int(good, 1, -1);
}
/*-
* 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,
const SSL3_RECORD *rec, unsigned md_size)
{
#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.
*/
unsigned mac_end = rec->length;
unsigned mac_start = mac_end - md_size;
/*
* scan_start contains the number of bytes that we can ignore because the
* MAC's position can only vary by 255 bytes.
*/
unsigned scan_start = 0;
unsigned i, j;
unsigned div_spoiler;
unsigned rotate_offset;
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);
/*
* div_spoiler contains a multiple of md_size that is used to cause the
* modulo operation to be constant time. Without this, the time varies
* based on the amount of padding when running on Intel chips at least.
* The aim of right-shifting md_size is so that the compiler doesn't
* figure out that it can remove div_spoiler as that would require it to
* prove that md_size is always even, which I hope is beyond it.
*/
div_spoiler = md_size >> 1;
div_spoiler <<= (sizeof(div_spoiler) - 1) * 8;
rotate_offset = (div_spoiler + mac_start - scan_start) % md_size;
memset(rotated_mac, 0, md_size);
for (i = scan_start, j = 0; i < rec->orig_len; i++) {
unsigned char mac_started = constant_time_ge_8(i, mac_start);
unsigned char mac_ended = constant_time_ge_8(i, mac_end);
unsigned char b = rec->data[i];
rotated_mac[j++] |= b & mac_started & ~mac_ended;
j &= constant_time_lt(j, md_size);
}
/* 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++];
rotate_offset &= constant_time_lt(rotate_offset, md_size);
}
#else
memset(out, 0, md_size);
rotate_offset = md_size - rotate_offset;
rotate_offset &= constant_time_lt(rotate_offset, md_size);
for (i = 0; i < md_size; i++) {
for (j = 0; j < md_size; j++)
out[j] |= rotated_mac[i] & constant_time_eq_8(j, rotate_offset);
rotate_offset++;
rotate_offset &= constant_time_lt(rotate_offset, md_size);
}
#endif
}
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 dtls1_process_record(SSL *s)
{
int i, al;
int enc_err;
SSL_SESSION *sess;
SSL3_RECORD *rr;
unsigned int mac_size;
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;
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
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("dec %d\n", rr->length);
{
unsigned int z;
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 */
if ((sess != NULL) &&
(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];
mac_size = EVP_MD_CTX_size(s->read_hash);
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 */ );
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 || mac == NULL
|| CRYPTO_memcmp(md, mac, (size_t)mac_size) != 0)
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);
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);
}
/*
* retrieve a buffered record that belongs to the current epoch, ie,
* processed
*/
#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;
int i, n;
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);
/*
* The epoch may have changed. If so, process all the pending records.
* This is a non-blocking operation.
*/
if (dtls1_process_buffered_records(s) < 0)
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 */
again:
/* 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)) {
Move SSL3_RECORD oriented functions into ssl3_record.c Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-02-02 00:47:15 +08:00
n = ssl3_read_n(s, DTLS1_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_BUFFER_get_len(&s->rlayer.rbuf), 0, 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
/* read timeout is handled by dtls1_read_bytes */
if (n <= 0)
return (n); /* error or non-blocking */
/* this packet contained a partial record, dump it */
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 (RECORD_LAYER_get_packet_length(&s->rlayer) != DTLS1_RT_HEADER_LENGTH) {
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 */
i = rr->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
n = ssl3_read_n(s, i, i, 1, 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
/* this packet contained a partial record, dump it */
if (n != i) {
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;
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
/* 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. */
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)),
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;
/* Mark receipt of record. */
dtls1_record_bitmap_update(s, bitmap);
}
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 (!dtls1_process_record(s)) {
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 */
}
dtls1_record_bitmap_update(s, bitmap); /* Mark receipt of record. */
return (1);
}
Reference in New Issue Copy Permalink