You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

tls_record.c 18 KiB

Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
Factor out the buffering and low-level record code. This begins decoupling the transport from the SSL state machine. The buffering logic is hidden behind an opaque API. Fields like ssl->packet and ssl->packet_length are gone. ssl3_get_record and dtls1_get_record now call low-level tls_open_record and dtls_open_record functions that unpack a single record independent of who owns the buffer. Both may be called in-place. This removes ssl->rstate which was redundant with the buffer length. Future work will push the buffer up the stack until it is above the handshake. Then we can expose SSL_open and SSL_seal APIs which act like *_open_record but return a slightly larger enum due to other events being possible. Likewise the handshake state machine will be detached from its buffer. The existing SSL_read, SSL_write, etc., APIs will be implemented on top of SSL_open, etc., combined with ssl_read_buffer_* and ssl_write_buffer_*. (Which is why ssl_read_buffer_extend still tries to abstract between TLS's and DTLS's fairly different needs.) The new buffering logic does not support read-ahead (removed previously) since it lacks a memmove on ssl_read_buffer_discard for TLS, but this could be added if desired. The old buffering logic wasn't quite right anyway; it tried to avoid the memmove in some cases and could get stuck too far into the buffer and not accept records. (The only time the memmove is optional is in DTLS or if enough of the record header is available to know that the entire next record would fit in the buffer.) The new logic also now actually decrypts the ciphertext in-place again, rather than almost in-place when there's an explicit nonce/IV. (That accidentally switched in https://boringssl-review.googlesource.com/#/c/4792/; see 3d59e04bce96474099ba76786a2337e99ae14505.) BUG=468889 Change-Id: I403c1626253c46897f47c7ae93aeab1064b767b2 Reviewed-on: https://boringssl-review.googlesource.com/5715 Reviewed-by: Adam Langley <agl@google.com>
9 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509
  1. /* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)
  2. * All rights reserved.
  3. *
  4. * This package is an SSL implementation written
  5. * by Eric Young (eay@cryptsoft.com).
  6. * The implementation was written so as to conform with Netscapes SSL.
  7. *
  8. * This library is free for commercial and non-commercial use as long as
  9. * the following conditions are aheared to. The following conditions
  10. * apply to all code found in this distribution, be it the RC4, RSA,
  11. * lhash, DES, etc., code; not just the SSL code. The SSL documentation
  12. * included with this distribution is covered by the same copyright terms
  13. * except that the holder is Tim Hudson (tjh@cryptsoft.com).
  14. *
  15. * Copyright remains Eric Young's, and as such any Copyright notices in
  16. * the code are not to be removed.
  17. * If this package is used in a product, Eric Young should be given attribution
  18. * as the author of the parts of the library used.
  19. * This can be in the form of a textual message at program startup or
  20. * in documentation (online or textual) provided with the package.
  21. *
  22. * Redistribution and use in source and binary forms, with or without
  23. * modification, are permitted provided that the following conditions
  24. * are met:
  25. * 1. Redistributions of source code must retain the copyright
  26. * notice, this list of conditions and the following disclaimer.
  27. * 2. Redistributions in binary form must reproduce the above copyright
  28. * notice, this list of conditions and the following disclaimer in the
  29. * documentation and/or other materials provided with the distribution.
  30. * 3. All advertising materials mentioning features or use of this software
  31. * must display the following acknowledgement:
  32. * "This product includes cryptographic software written by
  33. * Eric Young (eay@cryptsoft.com)"
  34. * The word 'cryptographic' can be left out if the rouines from the library
  35. * being used are not cryptographic related :-).
  36. * 4. If you include any Windows specific code (or a derivative thereof) from
  37. * the apps directory (application code) you must include an acknowledgement:
  38. * "This product includes software written by Tim Hudson (tjh@cryptsoft.com)"
  39. *
  40. * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND
  41. * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  42. * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
  43. * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
  44. * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  45. * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
  46. * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  47. * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
  48. * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
  49. * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
  50. * SUCH DAMAGE.
  51. *
  52. * The licence and distribution terms for any publically available version or
  53. * derivative of this code cannot be changed. i.e. this code cannot simply be
  54. * copied and put under another distribution licence
  55. * [including the GNU Public Licence.]
  56. */
  57. /* ====================================================================
  58. * Copyright (c) 1998-2002 The OpenSSL Project. All rights reserved.
  59. *
  60. * Redistribution and use in source and binary forms, with or without
  61. * modification, are permitted provided that the following conditions
  62. * are met:
  63. *
  64. * 1. Redistributions of source code must retain the above copyright
  65. * notice, this list of conditions and the following disclaimer.
  66. *
  67. * 2. Redistributions in binary form must reproduce the above copyright
  68. * notice, this list of conditions and the following disclaimer in
  69. * the documentation and/or other materials provided with the
  70. * distribution.
  71. *
  72. * 3. All advertising materials mentioning features or use of this
  73. * software must display the following acknowledgment:
  74. * "This product includes software developed by the OpenSSL Project
  75. * for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
  76. *
  77. * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
  78. * endorse or promote products derived from this software without
  79. * prior written permission. For written permission, please contact
  80. * openssl-core@openssl.org.
  81. *
  82. * 5. Products derived from this software may not be called "OpenSSL"
  83. * nor may "OpenSSL" appear in their names without prior written
  84. * permission of the OpenSSL Project.
  85. *
  86. * 6. Redistributions of any form whatsoever must retain the following
  87. * acknowledgment:
  88. * "This product includes software developed by the OpenSSL Project
  89. * for use in the OpenSSL Toolkit (http://www.openssl.org/)"
  90. *
  91. * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
  92. * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  93. * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
  94. * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
  95. * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  96. * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
  97. * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
  98. * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
  99. * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
  100. * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
  101. * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
  102. * OF THE POSSIBILITY OF SUCH DAMAGE.
  103. * ====================================================================
  104. *
  105. * This product includes cryptographic software written by Eric Young
  106. * (eay@cryptsoft.com). This product includes software written by Tim
  107. * Hudson (tjh@cryptsoft.com). */
  108. #include <openssl/ssl.h>
  109. #include <assert.h>
  110. #include <string.h>
  111. #include <openssl/bytestring.h>
  112. #include <openssl/err.h>
  113. #include <openssl/mem.h>
  114. #include "internal.h"
  115. #include "../crypto/internal.h"
  116. /* kMaxEmptyRecords is the number of consecutive, empty records that will be
  117. * processed. Without this limit an attacker could send empty records at a
  118. * faster rate than we can process and cause record processing to loop
  119. * forever. */
  120. static const uint8_t kMaxEmptyRecords = 32;
  121. /* kMaxEarlyDataSkipped is the maximum amount of data processed when skipping
  122. * over early data. Without this limit an attacker could send records at a
  123. * faster rate than we can process and cause trial decryption to loop
  124. * forever. */
  125. static const size_t kMaxEarlyDataSkipped = 16384;
  126. /* kMaxWarningAlerts is the number of consecutive warning alerts that will be
  127. * processed. */
  128. static const uint8_t kMaxWarningAlerts = 4;
  129. /* ssl_needs_record_splitting returns one if |ssl|'s current outgoing cipher
  130. * state needs record-splitting and zero otherwise. */
  131. static int ssl_needs_record_splitting(const SSL *ssl) {
  132. return ssl->s3->aead_write_ctx != NULL &&
  133. ssl3_protocol_version(ssl) < TLS1_1_VERSION &&
  134. (ssl->mode & SSL_MODE_CBC_RECORD_SPLITTING) != 0 &&
  135. SSL_CIPHER_is_block_cipher(ssl->s3->aead_write_ctx->cipher);
  136. }
  137. int ssl_record_sequence_update(uint8_t *seq, size_t seq_len) {
  138. for (size_t i = seq_len - 1; i < seq_len; i--) {
  139. ++seq[i];
  140. if (seq[i] != 0) {
  141. return 1;
  142. }
  143. }
  144. OPENSSL_PUT_ERROR(SSL, ERR_R_OVERFLOW);
  145. return 0;
  146. }
  147. size_t ssl_record_prefix_len(const SSL *ssl) {
  148. if (SSL_is_dtls(ssl)) {
  149. return DTLS1_RT_HEADER_LENGTH +
  150. SSL_AEAD_CTX_explicit_nonce_len(ssl->s3->aead_read_ctx);
  151. } else {
  152. return SSL3_RT_HEADER_LENGTH +
  153. SSL_AEAD_CTX_explicit_nonce_len(ssl->s3->aead_read_ctx);
  154. }
  155. }
  156. size_t ssl_seal_align_prefix_len(const SSL *ssl) {
  157. if (SSL_is_dtls(ssl)) {
  158. return DTLS1_RT_HEADER_LENGTH +
  159. SSL_AEAD_CTX_explicit_nonce_len(ssl->s3->aead_write_ctx);
  160. } else {
  161. size_t ret = SSL3_RT_HEADER_LENGTH +
  162. SSL_AEAD_CTX_explicit_nonce_len(ssl->s3->aead_write_ctx);
  163. if (ssl_needs_record_splitting(ssl)) {
  164. ret += SSL3_RT_HEADER_LENGTH;
  165. ret += ssl_cipher_get_record_split_len(ssl->s3->aead_write_ctx->cipher);
  166. }
  167. return ret;
  168. }
  169. }
  170. size_t SSL_max_seal_overhead(const SSL *ssl) {
  171. size_t ret = SSL_AEAD_CTX_max_overhead(ssl->s3->aead_write_ctx);
  172. if (SSL_is_dtls(ssl)) {
  173. ret += DTLS1_RT_HEADER_LENGTH;
  174. } else {
  175. ret += SSL3_RT_HEADER_LENGTH;
  176. }
  177. /* TLS 1.3 needs an extra byte for the encrypted record type. */
  178. if (ssl->s3->have_version &&
  179. ssl3_protocol_version(ssl) >= TLS1_3_VERSION) {
  180. ret += 1;
  181. }
  182. if (!SSL_is_dtls(ssl) && ssl_needs_record_splitting(ssl)) {
  183. ret *= 2;
  184. }
  185. return ret;
  186. }
  187. enum ssl_open_record_t tls_open_record(SSL *ssl, uint8_t *out_type, CBS *out,
  188. size_t *out_consumed, uint8_t *out_alert,
  189. uint8_t *in, size_t in_len) {
  190. *out_consumed = 0;
  191. CBS cbs;
  192. CBS_init(&cbs, in, in_len);
  193. /* Decode the record header. */
  194. uint8_t type;
  195. uint16_t version, ciphertext_len;
  196. if (!CBS_get_u8(&cbs, &type) ||
  197. !CBS_get_u16(&cbs, &version) ||
  198. !CBS_get_u16(&cbs, &ciphertext_len)) {
  199. *out_consumed = SSL3_RT_HEADER_LENGTH;
  200. return ssl_open_record_partial;
  201. }
  202. int version_ok;
  203. if (ssl->s3->aead_read_ctx == NULL) {
  204. /* Only check the first byte. Enforcing beyond that can prevent decoding
  205. * version negotiation failure alerts. */
  206. version_ok = (version >> 8) == SSL3_VERSION_MAJOR;
  207. } else if (ssl3_protocol_version(ssl) < TLS1_3_VERSION) {
  208. /* Earlier versions of TLS switch the record version. */
  209. version_ok = version == ssl->version;
  210. } else {
  211. /* Starting TLS 1.3, the version field is frozen at {3, 1}. */
  212. version_ok = version == TLS1_VERSION;
  213. }
  214. if (!version_ok) {
  215. OPENSSL_PUT_ERROR(SSL, SSL_R_WRONG_VERSION_NUMBER);
  216. *out_alert = SSL_AD_PROTOCOL_VERSION;
  217. return ssl_open_record_error;
  218. }
  219. /* Check the ciphertext length. */
  220. if (ciphertext_len > SSL3_RT_MAX_ENCRYPTED_LENGTH) {
  221. OPENSSL_PUT_ERROR(SSL, SSL_R_ENCRYPTED_LENGTH_TOO_LONG);
  222. *out_alert = SSL_AD_RECORD_OVERFLOW;
  223. return ssl_open_record_error;
  224. }
  225. /* Extract the body. */
  226. CBS body;
  227. if (!CBS_get_bytes(&cbs, &body, ciphertext_len)) {
  228. *out_consumed = SSL3_RT_HEADER_LENGTH + (size_t)ciphertext_len;
  229. return ssl_open_record_partial;
  230. }
  231. ssl_do_msg_callback(ssl, 0 /* read */, SSL3_RT_HEADER, in,
  232. SSL3_RT_HEADER_LENGTH);
  233. *out_consumed = in_len - CBS_len(&cbs);
  234. /* Skip early data received when expecting a second ClientHello if we rejected
  235. * 0RTT. */
  236. if (ssl->s3->skip_early_data &&
  237. ssl->s3->aead_read_ctx == NULL &&
  238. type == SSL3_RT_APPLICATION_DATA) {
  239. goto skipped_data;
  240. }
  241. /* Decrypt the body in-place. */
  242. if (!SSL_AEAD_CTX_open(ssl->s3->aead_read_ctx, out, type, version,
  243. ssl->s3->read_sequence, (uint8_t *)CBS_data(&body),
  244. CBS_len(&body))) {
  245. if (ssl->s3->skip_early_data &&
  246. ssl->s3->aead_read_ctx != NULL) {
  247. ERR_clear_error();
  248. goto skipped_data;
  249. }
  250. OPENSSL_PUT_ERROR(SSL, SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC);
  251. *out_alert = SSL_AD_BAD_RECORD_MAC;
  252. return ssl_open_record_error;
  253. }
  254. ssl->s3->skip_early_data = 0;
  255. if (!ssl_record_sequence_update(ssl->s3->read_sequence, 8)) {
  256. *out_alert = SSL_AD_INTERNAL_ERROR;
  257. return ssl_open_record_error;
  258. }
  259. /* TLS 1.3 hides the record type inside the encrypted data. */
  260. if (ssl->s3->have_version &&
  261. ssl3_protocol_version(ssl) >= TLS1_3_VERSION &&
  262. ssl->s3->aead_read_ctx != NULL) {
  263. /* The outer record type is always application_data. */
  264. if (type != SSL3_RT_APPLICATION_DATA) {
  265. OPENSSL_PUT_ERROR(SSL, SSL_R_INVALID_OUTER_RECORD_TYPE);
  266. *out_alert = SSL_AD_DECODE_ERROR;
  267. return ssl_open_record_error;
  268. }
  269. do {
  270. if (!CBS_get_last_u8(out, &type)) {
  271. OPENSSL_PUT_ERROR(SSL, SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC);
  272. *out_alert = SSL_AD_DECRYPT_ERROR;
  273. return ssl_open_record_error;
  274. }
  275. } while (type == 0);
  276. }
  277. /* Check the plaintext length. */
  278. if (CBS_len(out) > SSL3_RT_MAX_PLAIN_LENGTH) {
  279. OPENSSL_PUT_ERROR(SSL, SSL_R_DATA_LENGTH_TOO_LONG);
  280. *out_alert = SSL_AD_RECORD_OVERFLOW;
  281. return ssl_open_record_error;
  282. }
  283. /* Limit the number of consecutive empty records. */
  284. if (CBS_len(out) == 0) {
  285. ssl->s3->empty_record_count++;
  286. if (ssl->s3->empty_record_count > kMaxEmptyRecords) {
  287. OPENSSL_PUT_ERROR(SSL, SSL_R_TOO_MANY_EMPTY_FRAGMENTS);
  288. *out_alert = SSL_AD_UNEXPECTED_MESSAGE;
  289. return ssl_open_record_error;
  290. }
  291. /* Apart from the limit, empty records are returned up to the caller. This
  292. * allows the caller to reject records of the wrong type. */
  293. } else {
  294. ssl->s3->empty_record_count = 0;
  295. }
  296. if (type == SSL3_RT_ALERT) {
  297. return ssl_process_alert(ssl, out_alert, CBS_data(out), CBS_len(out));
  298. }
  299. ssl->s3->warning_alert_count = 0;
  300. *out_type = type;
  301. return ssl_open_record_success;
  302. skipped_data:
  303. ssl->s3->early_data_skipped += *out_consumed;
  304. if (ssl->s3->early_data_skipped < *out_consumed) {
  305. ssl->s3->early_data_skipped = kMaxEarlyDataSkipped + 1;
  306. }
  307. if (ssl->s3->early_data_skipped > kMaxEarlyDataSkipped) {
  308. OPENSSL_PUT_ERROR(SSL, SSL_R_TOO_MUCH_SKIPPED_EARLY_DATA);
  309. *out_alert = SSL_AD_UNEXPECTED_MESSAGE;
  310. return ssl_open_record_error;
  311. }
  312. return ssl_open_record_discard;
  313. }
  314. static int do_seal_record(SSL *ssl, uint8_t *out, size_t *out_len,
  315. size_t max_out, uint8_t type, const uint8_t *in,
  316. size_t in_len) {
  317. if (max_out < SSL3_RT_HEADER_LENGTH) {
  318. OPENSSL_PUT_ERROR(SSL, SSL_R_BUFFER_TOO_SMALL);
  319. return 0;
  320. }
  321. /* Either |in| and |out| don't alias or |in| aligns with the
  322. * ciphertext. |tls_seal_record| forbids aliasing, but TLS 1.3 aliases them
  323. * internally. */
  324. assert(!buffers_alias(in, in_len, out, max_out) ||
  325. in ==
  326. out + SSL3_RT_HEADER_LENGTH +
  327. SSL_AEAD_CTX_explicit_nonce_len(ssl->s3->aead_write_ctx));
  328. out[0] = type;
  329. /* The TLS record-layer version number is meaningless and, starting in
  330. * TLS 1.3, is frozen at TLS 1.0. But for historical reasons, SSL 3.0
  331. * ClientHellos should use SSL 3.0 and pre-TLS-1.3 expects the version
  332. * to change after version negotiation. */
  333. uint16_t wire_version = TLS1_VERSION;
  334. if (ssl->version == SSL3_VERSION ||
  335. (ssl->s3->have_version && ssl3_protocol_version(ssl) < TLS1_3_VERSION)) {
  336. wire_version = ssl->version;
  337. }
  338. out[1] = wire_version >> 8;
  339. out[2] = wire_version & 0xff;
  340. size_t ciphertext_len;
  341. if (!SSL_AEAD_CTX_seal(ssl->s3->aead_write_ctx, out + SSL3_RT_HEADER_LENGTH,
  342. &ciphertext_len, max_out - SSL3_RT_HEADER_LENGTH,
  343. type, wire_version, ssl->s3->write_sequence, in,
  344. in_len) ||
  345. !ssl_record_sequence_update(ssl->s3->write_sequence, 8)) {
  346. return 0;
  347. }
  348. if (ciphertext_len >= 1 << 16) {
  349. OPENSSL_PUT_ERROR(SSL, ERR_R_OVERFLOW);
  350. return 0;
  351. }
  352. out[3] = ciphertext_len >> 8;
  353. out[4] = ciphertext_len & 0xff;
  354. *out_len = SSL3_RT_HEADER_LENGTH + ciphertext_len;
  355. ssl_do_msg_callback(ssl, 1 /* write */, SSL3_RT_HEADER, out,
  356. SSL3_RT_HEADER_LENGTH);
  357. return 1;
  358. }
  359. int tls_seal_record(SSL *ssl, uint8_t *out, size_t *out_len, size_t max_out,
  360. uint8_t type, const uint8_t *in, size_t in_len) {
  361. if (buffers_alias(in, in_len, out, max_out)) {
  362. OPENSSL_PUT_ERROR(SSL, SSL_R_OUTPUT_ALIASES_INPUT);
  363. return 0;
  364. }
  365. size_t frag_len = 0;
  366. /* TLS 1.3 hides the actual record type inside the encrypted data. */
  367. if (ssl->s3->have_version &&
  368. ssl3_protocol_version(ssl) >= TLS1_3_VERSION &&
  369. ssl->s3->aead_write_ctx != NULL) {
  370. size_t padding = SSL3_RT_HEADER_LENGTH + 1;
  371. if (in_len > in_len + padding || max_out < in_len + padding) {
  372. OPENSSL_PUT_ERROR(SSL, SSL_R_BUFFER_TOO_SMALL);
  373. return 0;
  374. }
  375. memmove(out + SSL3_RT_HEADER_LENGTH, in, in_len);
  376. out[SSL3_RT_HEADER_LENGTH + in_len] = type;
  377. in = out + SSL3_RT_HEADER_LENGTH;
  378. type = SSL3_RT_APPLICATION_DATA;
  379. in_len++;
  380. }
  381. if (type == SSL3_RT_APPLICATION_DATA && in_len > 1 &&
  382. ssl_needs_record_splitting(ssl)) {
  383. if (!do_seal_record(ssl, out, &frag_len, max_out, type, in, 1)) {
  384. return 0;
  385. }
  386. in++;
  387. in_len--;
  388. out += frag_len;
  389. max_out -= frag_len;
  390. #if !defined(BORINGSSL_UNSAFE_FUZZER_MODE)
  391. assert(SSL3_RT_HEADER_LENGTH + ssl_cipher_get_record_split_len(
  392. ssl->s3->aead_write_ctx->cipher) ==
  393. frag_len);
  394. #endif
  395. }
  396. if (!do_seal_record(ssl, out, out_len, max_out, type, in, in_len)) {
  397. return 0;
  398. }
  399. *out_len += frag_len;
  400. return 1;
  401. }
  402. enum ssl_open_record_t ssl_process_alert(SSL *ssl, uint8_t *out_alert,
  403. const uint8_t *in, size_t in_len) {
  404. /* Alerts records may not contain fragmented or multiple alerts. */
  405. if (in_len != 2) {
  406. *out_alert = SSL_AD_DECODE_ERROR;
  407. OPENSSL_PUT_ERROR(SSL, SSL_R_BAD_ALERT);
  408. return ssl_open_record_error;
  409. }
  410. ssl_do_msg_callback(ssl, 0 /* read */, SSL3_RT_ALERT, in, in_len);
  411. const uint8_t alert_level = in[0];
  412. const uint8_t alert_descr = in[1];
  413. uint16_t alert = (alert_level << 8) | alert_descr;
  414. ssl_do_info_callback(ssl, SSL_CB_READ_ALERT, alert);
  415. if (alert_level == SSL3_AL_WARNING) {
  416. if (alert_descr == SSL_AD_CLOSE_NOTIFY) {
  417. ssl->s3->recv_shutdown = ssl_shutdown_close_notify;
  418. return ssl_open_record_close_notify;
  419. }
  420. /* Warning alerts do not exist in TLS 1.3. */
  421. if (ssl->s3->have_version &&
  422. ssl3_protocol_version(ssl) >= TLS1_3_VERSION) {
  423. *out_alert = SSL_AD_DECODE_ERROR;
  424. OPENSSL_PUT_ERROR(SSL, SSL_R_BAD_ALERT);
  425. return ssl_open_record_error;
  426. }
  427. ssl->s3->warning_alert_count++;
  428. if (ssl->s3->warning_alert_count > kMaxWarningAlerts) {
  429. *out_alert = SSL_AD_UNEXPECTED_MESSAGE;
  430. OPENSSL_PUT_ERROR(SSL, SSL_R_TOO_MANY_WARNING_ALERTS);
  431. return ssl_open_record_error;
  432. }
  433. return ssl_open_record_discard;
  434. }
  435. if (alert_level == SSL3_AL_FATAL) {
  436. ssl->s3->recv_shutdown = ssl_shutdown_fatal_alert;
  437. char tmp[16];
  438. OPENSSL_PUT_ERROR(SSL, SSL_AD_REASON_OFFSET + alert_descr);
  439. BIO_snprintf(tmp, sizeof(tmp), "%d", alert_descr);
  440. ERR_add_error_data(2, "SSL alert number ", tmp);
  441. return ssl_open_record_fatal_alert;
  442. }
  443. *out_alert = SSL_AD_ILLEGAL_PARAMETER;
  444. OPENSSL_PUT_ERROR(SSL, SSL_R_UNKNOWN_ALERT_TYPE);
  445. return ssl_open_record_error;
  446. }