2015-07-29 02:34:45 +01:00
|
|
|
/* Copyright (c) 2015, Google Inc.
|
|
|
|
*
|
|
|
|
* Permission to use, copy, modify, and/or distribute this software for any
|
|
|
|
* purpose with or without fee is hereby granted, provided that the above
|
|
|
|
* copyright notice and this permission notice appear in all copies.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
|
|
|
|
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
|
|
|
|
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
|
|
|
|
* SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
|
|
|
|
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
|
|
|
|
* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
|
|
|
|
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */
|
|
|
|
|
|
|
|
#include <openssl/ssl.h>
|
|
|
|
|
|
|
|
#include <assert.h>
|
|
|
|
#include <limits.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
#include <openssl/bio.h>
|
|
|
|
#include <openssl/err.h>
|
|
|
|
#include <openssl/mem.h>
|
|
|
|
|
2016-12-13 06:07:13 +00:00
|
|
|
#include "../crypto/internal.h"
|
2015-07-29 02:34:45 +01:00
|
|
|
#include "internal.h"
|
|
|
|
|
|
|
|
|
2017-07-15 00:36:07 +01:00
|
|
|
/* BIO uses int instead of size_t. No lengths will exceed uint16_t, so this will
|
|
|
|
* not overflow. */
|
|
|
|
static_assert(0xffff <= INT_MAX, "uint16_t does not fit in int");
|
2015-07-29 02:34:45 +01:00
|
|
|
|
2017-07-15 00:36:07 +01:00
|
|
|
static_assert((SSL3_ALIGN_PAYLOAD & (SSL3_ALIGN_PAYLOAD - 1)) == 0,
|
|
|
|
"SSL3_ALIGN_PAYLOAD must be a power of 2");
|
2015-07-29 02:34:45 +01:00
|
|
|
|
Size TLS read buffers based on the size requested.
Like the write half, rather than allocating the maximum size needed and
relying on the malloc implementation to pool this sanely, allocate the
size the TLS record-layer code believes it needs.
As currently arranged, this will cause us to alternate from a small
allocation (for the record header) and then an allocation sized to the
record itself. Windows is reportedly bad at pooling large allocations,
so, *if the server sends us smaller records*, this will avoid hitting
the problem cases.
If the server sends us size 16k records, the maximum allowed by ther
protocol, we simply must buffer up to that amount and will continue to
allocate similar sizes as before (although slightly smaller; this CL
also fixes small double-counting we did on the allocation sizes).
Separately, we'll gather some metrics in Chromium to see what common
record sizes are to determine if this optimization is sufficient. This
is intended as an easy optimization we can do now, in advance of ongoing
work to fix the extra layer of buffering between Chromium and BoringSSL
with an in-place decrypt API.
Bug: chromium:524258
Change-Id: I233df29df1212154c49fee4285ccc37be12f81dc
Reviewed-on: https://boringssl-review.googlesource.com/17329
Reviewed-by: Adam Langley <agl@google.com>
2017-06-22 23:07:15 +01:00
|
|
|
/* ensure_buffer ensures |buf| has capacity at least |cap|, aligned such that
|
|
|
|
* data written after |header_len| is aligned to a |SSL3_ALIGN_PAYLOAD|-byte
|
2015-07-29 02:34:45 +01:00
|
|
|
* boundary. It returns one on success and zero on error. */
|
Size TLS read buffers based on the size requested.
Like the write half, rather than allocating the maximum size needed and
relying on the malloc implementation to pool this sanely, allocate the
size the TLS record-layer code believes it needs.
As currently arranged, this will cause us to alternate from a small
allocation (for the record header) and then an allocation sized to the
record itself. Windows is reportedly bad at pooling large allocations,
so, *if the server sends us smaller records*, this will avoid hitting
the problem cases.
If the server sends us size 16k records, the maximum allowed by ther
protocol, we simply must buffer up to that amount and will continue to
allocate similar sizes as before (although slightly smaller; this CL
also fixes small double-counting we did on the allocation sizes).
Separately, we'll gather some metrics in Chromium to see what common
record sizes are to determine if this optimization is sufficient. This
is intended as an easy optimization we can do now, in advance of ongoing
work to fix the extra layer of buffering between Chromium and BoringSSL
with an in-place decrypt API.
Bug: chromium:524258
Change-Id: I233df29df1212154c49fee4285ccc37be12f81dc
Reviewed-on: https://boringssl-review.googlesource.com/17329
Reviewed-by: Adam Langley <agl@google.com>
2017-06-22 23:07:15 +01:00
|
|
|
static int ensure_buffer(SSL3_BUFFER *buf, size_t header_len, size_t cap) {
|
|
|
|
if (cap > 0xffff) {
|
2015-07-29 02:34:45 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Size TLS read buffers based on the size requested.
Like the write half, rather than allocating the maximum size needed and
relying on the malloc implementation to pool this sanely, allocate the
size the TLS record-layer code believes it needs.
As currently arranged, this will cause us to alternate from a small
allocation (for the record header) and then an allocation sized to the
record itself. Windows is reportedly bad at pooling large allocations,
so, *if the server sends us smaller records*, this will avoid hitting
the problem cases.
If the server sends us size 16k records, the maximum allowed by ther
protocol, we simply must buffer up to that amount and will continue to
allocate similar sizes as before (although slightly smaller; this CL
also fixes small double-counting we did on the allocation sizes).
Separately, we'll gather some metrics in Chromium to see what common
record sizes are to determine if this optimization is sufficient. This
is intended as an easy optimization we can do now, in advance of ongoing
work to fix the extra layer of buffering between Chromium and BoringSSL
with an in-place decrypt API.
Bug: chromium:524258
Change-Id: I233df29df1212154c49fee4285ccc37be12f81dc
Reviewed-on: https://boringssl-review.googlesource.com/17329
Reviewed-by: Adam Langley <agl@google.com>
2017-06-22 23:07:15 +01:00
|
|
|
if (buf->cap >= cap) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2015-07-29 02:34:45 +01:00
|
|
|
/* Add up to |SSL3_ALIGN_PAYLOAD| - 1 bytes of slack for alignment. */
|
2017-07-12 21:31:08 +01:00
|
|
|
uint8_t *new_buf = (uint8_t *)OPENSSL_malloc(cap + SSL3_ALIGN_PAYLOAD - 1);
|
Size TLS read buffers based on the size requested.
Like the write half, rather than allocating the maximum size needed and
relying on the malloc implementation to pool this sanely, allocate the
size the TLS record-layer code believes it needs.
As currently arranged, this will cause us to alternate from a small
allocation (for the record header) and then an allocation sized to the
record itself. Windows is reportedly bad at pooling large allocations,
so, *if the server sends us smaller records*, this will avoid hitting
the problem cases.
If the server sends us size 16k records, the maximum allowed by ther
protocol, we simply must buffer up to that amount and will continue to
allocate similar sizes as before (although slightly smaller; this CL
also fixes small double-counting we did on the allocation sizes).
Separately, we'll gather some metrics in Chromium to see what common
record sizes are to determine if this optimization is sufficient. This
is intended as an easy optimization we can do now, in advance of ongoing
work to fix the extra layer of buffering between Chromium and BoringSSL
with an in-place decrypt API.
Bug: chromium:524258
Change-Id: I233df29df1212154c49fee4285ccc37be12f81dc
Reviewed-on: https://boringssl-review.googlesource.com/17329
Reviewed-by: Adam Langley <agl@google.com>
2017-06-22 23:07:15 +01:00
|
|
|
if (new_buf == NULL) {
|
2015-07-29 02:34:45 +01:00
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_MALLOC_FAILURE);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Size TLS read buffers based on the size requested.
Like the write half, rather than allocating the maximum size needed and
relying on the malloc implementation to pool this sanely, allocate the
size the TLS record-layer code believes it needs.
As currently arranged, this will cause us to alternate from a small
allocation (for the record header) and then an allocation sized to the
record itself. Windows is reportedly bad at pooling large allocations,
so, *if the server sends us smaller records*, this will avoid hitting
the problem cases.
If the server sends us size 16k records, the maximum allowed by ther
protocol, we simply must buffer up to that amount and will continue to
allocate similar sizes as before (although slightly smaller; this CL
also fixes small double-counting we did on the allocation sizes).
Separately, we'll gather some metrics in Chromium to see what common
record sizes are to determine if this optimization is sufficient. This
is intended as an easy optimization we can do now, in advance of ongoing
work to fix the extra layer of buffering between Chromium and BoringSSL
with an in-place decrypt API.
Bug: chromium:524258
Change-Id: I233df29df1212154c49fee4285ccc37be12f81dc
Reviewed-on: https://boringssl-review.googlesource.com/17329
Reviewed-by: Adam Langley <agl@google.com>
2017-06-22 23:07:15 +01:00
|
|
|
/* Offset the buffer such that the record body is aligned. */
|
|
|
|
size_t new_offset =
|
|
|
|
(0 - header_len - (uintptr_t)new_buf) & (SSL3_ALIGN_PAYLOAD - 1);
|
|
|
|
|
|
|
|
if (buf->buf != NULL) {
|
|
|
|
OPENSSL_memcpy(new_buf + new_offset, buf->buf + buf->offset, buf->len);
|
|
|
|
OPENSSL_free(buf->buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
buf->buf = new_buf;
|
|
|
|
buf->offset = new_offset;
|
2015-07-29 02:34:45 +01:00
|
|
|
buf->cap = cap;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void consume_buffer(SSL3_BUFFER *buf, size_t len) {
|
|
|
|
if (len > buf->len) {
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
buf->offset += (uint16_t)len;
|
|
|
|
buf->len -= (uint16_t)len;
|
|
|
|
buf->cap -= (uint16_t)len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void clear_buffer(SSL3_BUFFER *buf) {
|
|
|
|
OPENSSL_free(buf->buf);
|
2016-12-13 06:07:13 +00:00
|
|
|
OPENSSL_memset(buf, 0, sizeof(SSL3_BUFFER));
|
2015-07-29 02:34:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
uint8_t *ssl_read_buffer(SSL *ssl) {
|
|
|
|
return ssl->s3->read_buffer.buf + ssl->s3->read_buffer.offset;
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t ssl_read_buffer_len(const SSL *ssl) {
|
|
|
|
return ssl->s3->read_buffer.len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dtls_read_buffer_next_packet(SSL *ssl) {
|
|
|
|
SSL3_BUFFER *buf = &ssl->s3->read_buffer;
|
|
|
|
|
|
|
|
if (buf->len > 0) {
|
|
|
|
/* It is an error to call |dtls_read_buffer_extend| when the read buffer is
|
|
|
|
* not empty. */
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read a single packet from |ssl->rbio|. |buf->cap| must fit in an int. */
|
|
|
|
int ret = BIO_read(ssl->rbio, buf->buf + buf->offset, (int)buf->cap);
|
|
|
|
if (ret <= 0) {
|
2016-03-12 03:56:19 +00:00
|
|
|
ssl->rwstate = SSL_READING;
|
2015-07-29 02:34:45 +01:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
/* |BIO_read| was bound by |buf->cap|, so this cannot overflow. */
|
|
|
|
buf->len = (uint16_t)ret;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int tls_read_buffer_extend_to(SSL *ssl, size_t len) {
|
|
|
|
SSL3_BUFFER *buf = &ssl->s3->read_buffer;
|
|
|
|
|
|
|
|
if (len > buf->cap) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_BUFFER_TOO_SMALL);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read until the target length is reached. */
|
|
|
|
while (buf->len < len) {
|
|
|
|
/* The amount of data to read is bounded by |buf->cap|, which must fit in an
|
|
|
|
* int. */
|
|
|
|
int ret = BIO_read(ssl->rbio, buf->buf + buf->offset + buf->len,
|
|
|
|
(int)(len - buf->len));
|
|
|
|
if (ret <= 0) {
|
2016-03-12 03:56:19 +00:00
|
|
|
ssl->rwstate = SSL_READING;
|
2015-07-29 02:34:45 +01:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
/* |BIO_read| was bound by |buf->cap - buf->len|, so this cannot
|
|
|
|
* overflow. */
|
|
|
|
buf->len += (uint16_t)ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ssl_read_buffer_extend_to(SSL *ssl, size_t len) {
|
|
|
|
/* |ssl_read_buffer_extend_to| implicitly discards any consumed data. */
|
|
|
|
ssl_read_buffer_discard(ssl);
|
|
|
|
|
Size TLS read buffers based on the size requested.
Like the write half, rather than allocating the maximum size needed and
relying on the malloc implementation to pool this sanely, allocate the
size the TLS record-layer code believes it needs.
As currently arranged, this will cause us to alternate from a small
allocation (for the record header) and then an allocation sized to the
record itself. Windows is reportedly bad at pooling large allocations,
so, *if the server sends us smaller records*, this will avoid hitting
the problem cases.
If the server sends us size 16k records, the maximum allowed by ther
protocol, we simply must buffer up to that amount and will continue to
allocate similar sizes as before (although slightly smaller; this CL
also fixes small double-counting we did on the allocation sizes).
Separately, we'll gather some metrics in Chromium to see what common
record sizes are to determine if this optimization is sufficient. This
is intended as an easy optimization we can do now, in advance of ongoing
work to fix the extra layer of buffering between Chromium and BoringSSL
with an in-place decrypt API.
Bug: chromium:524258
Change-Id: I233df29df1212154c49fee4285ccc37be12f81dc
Reviewed-on: https://boringssl-review.googlesource.com/17329
Reviewed-by: Adam Langley <agl@google.com>
2017-06-22 23:07:15 +01:00
|
|
|
if (SSL_is_dtls(ssl)) {
|
2017-07-15 00:36:07 +01:00
|
|
|
static_assert(
|
Size TLS read buffers based on the size requested.
Like the write half, rather than allocating the maximum size needed and
relying on the malloc implementation to pool this sanely, allocate the
size the TLS record-layer code believes it needs.
As currently arranged, this will cause us to alternate from a small
allocation (for the record header) and then an allocation sized to the
record itself. Windows is reportedly bad at pooling large allocations,
so, *if the server sends us smaller records*, this will avoid hitting
the problem cases.
If the server sends us size 16k records, the maximum allowed by ther
protocol, we simply must buffer up to that amount and will continue to
allocate similar sizes as before (although slightly smaller; this CL
also fixes small double-counting we did on the allocation sizes).
Separately, we'll gather some metrics in Chromium to see what common
record sizes are to determine if this optimization is sufficient. This
is intended as an easy optimization we can do now, in advance of ongoing
work to fix the extra layer of buffering between Chromium and BoringSSL
with an in-place decrypt API.
Bug: chromium:524258
Change-Id: I233df29df1212154c49fee4285ccc37be12f81dc
Reviewed-on: https://boringssl-review.googlesource.com/17329
Reviewed-by: Adam Langley <agl@google.com>
2017-06-22 23:07:15 +01:00
|
|
|
DTLS1_RT_HEADER_LENGTH + SSL3_RT_MAX_ENCRYPTED_LENGTH <= 0xffff,
|
2017-07-15 00:36:07 +01:00
|
|
|
"DTLS read buffer is too large");
|
Size TLS read buffers based on the size requested.
Like the write half, rather than allocating the maximum size needed and
relying on the malloc implementation to pool this sanely, allocate the
size the TLS record-layer code believes it needs.
As currently arranged, this will cause us to alternate from a small
allocation (for the record header) and then an allocation sized to the
record itself. Windows is reportedly bad at pooling large allocations,
so, *if the server sends us smaller records*, this will avoid hitting
the problem cases.
If the server sends us size 16k records, the maximum allowed by ther
protocol, we simply must buffer up to that amount and will continue to
allocate similar sizes as before (although slightly smaller; this CL
also fixes small double-counting we did on the allocation sizes).
Separately, we'll gather some metrics in Chromium to see what common
record sizes are to determine if this optimization is sufficient. This
is intended as an easy optimization we can do now, in advance of ongoing
work to fix the extra layer of buffering between Chromium and BoringSSL
with an in-place decrypt API.
Bug: chromium:524258
Change-Id: I233df29df1212154c49fee4285ccc37be12f81dc
Reviewed-on: https://boringssl-review.googlesource.com/17329
Reviewed-by: Adam Langley <agl@google.com>
2017-06-22 23:07:15 +01:00
|
|
|
|
|
|
|
/* The |len| parameter is ignored in DTLS. */
|
|
|
|
len = DTLS1_RT_HEADER_LENGTH + SSL3_RT_MAX_ENCRYPTED_LENGTH;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!ensure_buffer(&ssl->s3->read_buffer, ssl_record_prefix_len(ssl), len)) {
|
2015-07-29 02:34:45 +01:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ssl->rbio == NULL) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_BIO_NOT_SET);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ret;
|
2016-08-02 21:22:34 +01:00
|
|
|
if (SSL_is_dtls(ssl)) {
|
2015-07-29 02:34:45 +01:00
|
|
|
/* |len| is ignored for a datagram transport. */
|
|
|
|
ret = dtls_read_buffer_next_packet(ssl);
|
|
|
|
} else {
|
|
|
|
ret = tls_read_buffer_extend_to(ssl, len);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ret <= 0) {
|
|
|
|
/* If the buffer was empty originally and remained empty after attempting to
|
|
|
|
* extend it, release the buffer until the next attempt. */
|
|
|
|
ssl_read_buffer_discard(ssl);
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ssl_read_buffer_consume(SSL *ssl, size_t len) {
|
|
|
|
SSL3_BUFFER *buf = &ssl->s3->read_buffer;
|
|
|
|
|
|
|
|
consume_buffer(buf, len);
|
2016-06-02 20:42:01 +01:00
|
|
|
|
|
|
|
/* The TLS stack never reads beyond the current record, so there will never be
|
|
|
|
* unconsumed data. If read-ahead is ever reimplemented,
|
|
|
|
* |ssl_read_buffer_discard| will require a |memcpy| to shift the excess back
|
|
|
|
* to the front of the buffer, to ensure there is enough space for the next
|
|
|
|
* record. */
|
2016-08-02 21:22:34 +01:00
|
|
|
assert(SSL_is_dtls(ssl) || len == 0 || buf->len == 0);
|
2015-07-29 02:34:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void ssl_read_buffer_discard(SSL *ssl) {
|
|
|
|
if (ssl->s3->read_buffer.len == 0) {
|
|
|
|
ssl_read_buffer_clear(ssl);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void ssl_read_buffer_clear(SSL *ssl) {
|
|
|
|
clear_buffer(&ssl->s3->read_buffer);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
int ssl_write_buffer_is_pending(const SSL *ssl) {
|
|
|
|
return ssl->s3->write_buffer.len > 0;
|
|
|
|
}
|
|
|
|
|
2017-07-15 00:36:07 +01:00
|
|
|
static_assert(SSL3_RT_HEADER_LENGTH * 2 +
|
|
|
|
SSL3_RT_SEND_MAX_ENCRYPTED_OVERHEAD * 2 +
|
|
|
|
SSL3_RT_MAX_PLAIN_LENGTH <=
|
|
|
|
0xffff,
|
|
|
|
"maximum TLS write buffer is too large");
|
2015-07-29 02:34:45 +01:00
|
|
|
|
2017-07-15 00:36:07 +01:00
|
|
|
static_assert(DTLS1_RT_HEADER_LENGTH + SSL3_RT_SEND_MAX_ENCRYPTED_OVERHEAD +
|
|
|
|
SSL3_RT_MAX_PLAIN_LENGTH <=
|
|
|
|
0xffff,
|
|
|
|
"maximum DTLS write buffer is too large");
|
2015-07-29 02:34:45 +01:00
|
|
|
|
|
|
|
int ssl_write_buffer_init(SSL *ssl, uint8_t **out_ptr, size_t max_len) {
|
|
|
|
SSL3_BUFFER *buf = &ssl->s3->write_buffer;
|
|
|
|
|
|
|
|
if (buf->buf != NULL) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, ERR_R_INTERNAL_ERROR);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
Size TLS read buffers based on the size requested.
Like the write half, rather than allocating the maximum size needed and
relying on the malloc implementation to pool this sanely, allocate the
size the TLS record-layer code believes it needs.
As currently arranged, this will cause us to alternate from a small
allocation (for the record header) and then an allocation sized to the
record itself. Windows is reportedly bad at pooling large allocations,
so, *if the server sends us smaller records*, this will avoid hitting
the problem cases.
If the server sends us size 16k records, the maximum allowed by ther
protocol, we simply must buffer up to that amount and will continue to
allocate similar sizes as before (although slightly smaller; this CL
also fixes small double-counting we did on the allocation sizes).
Separately, we'll gather some metrics in Chromium to see what common
record sizes are to determine if this optimization is sufficient. This
is intended as an easy optimization we can do now, in advance of ongoing
work to fix the extra layer of buffering between Chromium and BoringSSL
with an in-place decrypt API.
Bug: chromium:524258
Change-Id: I233df29df1212154c49fee4285ccc37be12f81dc
Reviewed-on: https://boringssl-review.googlesource.com/17329
Reviewed-by: Adam Langley <agl@google.com>
2017-06-22 23:07:15 +01:00
|
|
|
if (!ensure_buffer(buf, ssl_seal_align_prefix_len(ssl), max_len)) {
|
2015-07-29 02:34:45 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
*out_ptr = buf->buf + buf->offset;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ssl_write_buffer_set_len(SSL *ssl, size_t len) {
|
|
|
|
SSL3_BUFFER *buf = &ssl->s3->write_buffer;
|
|
|
|
|
|
|
|
if (len > buf->cap) {
|
|
|
|
abort();
|
|
|
|
}
|
|
|
|
buf->len = len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int tls_write_buffer_flush(SSL *ssl) {
|
|
|
|
SSL3_BUFFER *buf = &ssl->s3->write_buffer;
|
|
|
|
|
|
|
|
while (buf->len > 0) {
|
|
|
|
int ret = BIO_write(ssl->wbio, buf->buf + buf->offset, buf->len);
|
|
|
|
if (ret <= 0) {
|
2016-03-12 03:56:19 +00:00
|
|
|
ssl->rwstate = SSL_WRITING;
|
2015-07-29 02:34:45 +01:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
consume_buffer(buf, (size_t)ret);
|
|
|
|
}
|
|
|
|
ssl_write_buffer_clear(ssl);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int dtls_write_buffer_flush(SSL *ssl) {
|
|
|
|
SSL3_BUFFER *buf = &ssl->s3->write_buffer;
|
|
|
|
if (buf->len == 0) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
int ret = BIO_write(ssl->wbio, buf->buf + buf->offset, buf->len);
|
2015-11-02 22:16:13 +00:00
|
|
|
if (ret <= 0) {
|
2016-03-12 03:56:19 +00:00
|
|
|
ssl->rwstate = SSL_WRITING;
|
2015-11-02 22:16:13 +00:00
|
|
|
/* If the write failed, drop the write buffer anyway. Datagram transports
|
|
|
|
* can't write half a packet, so the caller is expected to retry from the
|
|
|
|
* top. */
|
|
|
|
ssl_write_buffer_clear(ssl);
|
|
|
|
return ret;
|
|
|
|
}
|
2015-07-29 02:34:45 +01:00
|
|
|
ssl_write_buffer_clear(ssl);
|
2015-11-02 22:16:13 +00:00
|
|
|
return 1;
|
2015-07-29 02:34:45 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
int ssl_write_buffer_flush(SSL *ssl) {
|
|
|
|
if (ssl->wbio == NULL) {
|
|
|
|
OPENSSL_PUT_ERROR(SSL, SSL_R_BIO_NOT_SET);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2016-08-02 21:22:34 +01:00
|
|
|
if (SSL_is_dtls(ssl)) {
|
2015-07-29 02:34:45 +01:00
|
|
|
return dtls_write_buffer_flush(ssl);
|
|
|
|
} else {
|
|
|
|
return tls_write_buffer_flush(ssl);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void ssl_write_buffer_clear(SSL *ssl) {
|
|
|
|
clear_buffer(&ssl->s3->write_buffer);
|
|
|
|
}
|