aboutsummaryrefslogtreecommitdiffstats
path: root/secure/lib/libcrypto/man/man3/SSL_read_early_data.3
diff options
context:
space:
mode:
Diffstat (limited to 'secure/lib/libcrypto/man/man3/SSL_read_early_data.3')
-rw-r--r--secure/lib/libcrypto/man/man3/SSL_read_early_data.323
1 files changed, 12 insertions, 11 deletions
diff --git a/secure/lib/libcrypto/man/man3/SSL_read_early_data.3 b/secure/lib/libcrypto/man/man3/SSL_read_early_data.3
index f49ddc3d2251..582a9de29ed5 100644
--- a/secure/lib/libcrypto/man/man3/SSL_read_early_data.3
+++ b/secure/lib/libcrypto/man/man3/SSL_read_early_data.3
@@ -1,4 +1,4 @@
-.\" Automatically generated by Pod::Man 4.11 (Pod::Simple 3.40)
+.\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.40)
.\"
.\" Standard preamble:
.\" ========================================================================
@@ -133,7 +133,7 @@
.\" ========================================================================
.\"
.IX Title "SSL_READ_EARLY_DATA 3"
-.TH SSL_READ_EARLY_DATA 3 "2020-04-21" "1.1.1g" "OpenSSL"
+.TH SSL_READ_EARLY_DATA 3 "2020-09-22" "1.1.1h" "OpenSSL"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
@@ -179,10 +179,11 @@ SSL_set_max_early_data, SSL_CTX_set_max_early_data, SSL_get_max_early_data, SSL_
These functions are used to send and receive early data where TLSv1.3 has been
negotiated. Early data can be sent by the client immediately after its initial
ClientHello without having to wait for the server to complete the handshake.
-Early data can only be sent if a session has previously been established with
-the server, and the server is known to support it. Additionally these functions
-can be used to send data from the server to the client when the client has not
-yet completed the authentication stage of the handshake.
+Early data can be sent if a session has previously been established with the
+server or when establishing a new session using an out-of-band \s-1PSK,\s0 and only
+when the server is known to support it. Additionally these functions can be used
+to send data from the server to the client when the client has not yet completed
+the authentication stage of the handshake.
.PP
Early data has weaker security properties than other data sent over an \s-1SSL/TLS\s0
connection. In particular the data does not have forward secrecy. There are also
@@ -316,7 +317,7 @@ early data settings for the \s-1SSL_CTX\s0 and \s-1SSL\s0 objects respectively.
server application will either use both of \fBSSL_read_early_data()\fR and
\&\fBSSL_CTX_set_max_early_data()\fR (or \fBSSL_set_max_early_data()\fR), or neither of them,
since there is no practical benefit from using only one of them. If the maximum
-early data setting for a server is non-zero then replay protection is
+early data setting for a server is nonzero then replay protection is
automatically enabled (see \*(L"\s-1REPLAY PROTECTION\*(R"\s0 below).
.PP
If the server rejects the early data sent by a client then it will skip over
@@ -334,7 +335,7 @@ max_early_data for the session and the recv_max_early_data setting for the
server. If a client sends more data than this then the connection will abort.
.PP
The configured value for max_early_data on a server may change over time as
-required. However clients may have tickets containing the previously configured
+required. However, clients may have tickets containing the previously configured
max_early_data value. The recv_max_early_data should always be equal to or
higher than any recently configured max_early_data value in order to avoid
aborted connections. The recv_max_early_data should never be set to less than
@@ -397,7 +398,7 @@ retry with a lower maximum protocol version.
When early data is in use the \s-1TLS\s0 protocol provides no security guarantees that
the same early data was not replayed across multiple connections. As a
mitigation for this issue OpenSSL automatically enables replay protection if the
-server is configured with a non-zero max early data value. With replay
+server is configured with a nonzero max early data value. With replay
protection enabled sessions are forced to be single use only. If a client
attempts to reuse a session ticket more than once, then the second and
subsequent attempts will fall back to a full handshake (and any early data that
@@ -428,7 +429,7 @@ cache. Applications should be designed with this in mind in order to minimise
the possibility of replay attacks.
.PP
The OpenSSL replay protection does not apply to external Pre Shared Keys (PSKs)
-(e.g. see \fBSSL_CTX_set_psk_find_session_callback\fR\|(3)). Therefore extreme caution
+(e.g. see \fBSSL_CTX_set_psk_find_session_callback\fR\|(3)). Therefore, extreme caution
should be applied when combining external PSKs with early data.
.PP
Some applications may mitigate the replay risks in other ways. For those
@@ -472,7 +473,7 @@ the server, or \s-1SSL_EARLY_DATA_NOT_SENT\s0 if no early data was sent.
All of the functions described above were added in OpenSSL 1.1.1.
.SH "COPYRIGHT"
.IX Header "COPYRIGHT"
-Copyright 2017\-2019 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2017\-2020 The OpenSSL Project Authors. All Rights Reserved.
.PP
Licensed under the OpenSSL license (the \*(L"License\*(R"). You may not use
this file except in compliance with the License. You can obtain a copy