diff options
Diffstat (limited to 'doc/man3/SSL_read_early_data.pod')
| -rw-r--r-- | doc/man3/SSL_read_early_data.pod | 8 |
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/man3/SSL_read_early_data.pod b/doc/man3/SSL_read_early_data.pod index d3552c928b..27d210f89b 100644 --- a/doc/man3/SSL_read_early_data.pod +++ b/doc/man3/SSL_read_early_data.pod @@ -203,7 +203,7 @@ early data settings for the SSL_CTX and SSL objects respectively. Generally a server application will either use both of SSL_read_early_data() and SSL_CTX_set_max_early_data() (or SSL_set_max_early_data()), 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</REPLAY PROTECTION> below). If the server rejects the early data sent by a client then it will skip over @@ -221,7 +221,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. 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 @@ -286,7 +286,7 @@ retry with a lower maximum protocol version. When early data is in use the TLS 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 @@ -317,7 +317,7 @@ cache. Applications should be designed with this in mind in order to minimise the possibility of replay attacks. The OpenSSL replay protection does not apply to external Pre Shared Keys (PSKs) -(e.g. see SSL_CTX_set_psk_find_session_callback(3)). Therefore extreme caution +(e.g. see SSL_CTX_set_psk_find_session_callback(3)). Therefore, extreme caution should be applied when combining external PSKs with early data. Some applications may mitigate the replay risks in other ways. For those |