Update pre9

doc/man3/RAND_add.pod

@@ -2,7 +2,8 @@
 
 =head1 NAME
 
-RAND_add, RAND_poll, RAND_seed, RAND_status, RAND_event, RAND_screen
+RAND_add, RAND_poll, RAND_seed, RAND_status, RAND_event, RAND_screen,
+RAND_keep_random_devices_open
 - add randomness to the PRNG or get its status
 
 =head1 SYNOPSIS
@@ -15,6 +16,8 @@ RAND_add, RAND_poll, RAND_seed, RAND_status, RAND_event, RAND_screen
  void RAND_add(const void *buf, int num, double randomness);
  void RAND_seed(const void *buf, int num);
 
+ void RAND_keep_random_devices_open(int keep);
+
 Deprecated:
 
  #if OPENSSL_API_COMPAT < 0x10100000L
@@ -54,6 +57,15 @@ should consider using L<RAND_load_file(3)> instead.
 
 RAND_seed() is equivalent to RAND_add() with B<randomness> set to B<num>.
 
+RAND_keep_random_devices_open() is used to control file descriptor
+usage by the random seed sources. Some seed sources maintain open file
+descriptors by default, which allows such sources to operate in a
+chroot(2) jail without the associated device nodes being available. When
+the B<keep> argument is zero, this call disables the retention of file
+descriptors. Conversely, a non-zero argument enables the retention of
+file descriptors. This function is usually called during initialization
+and it takes effect immediately.
+
 RAND_event() and RAND_screen() are equivalent to RAND_poll() and exist
 for compatibility reasons only. See HISTORY section below.
 

doc/man3/SSL_CTX_set_options.pod

@@ -145,13 +145,39 @@ DTLS connections.
 
 =item SSL_OP_NO_TICKET
 
-Normally clients and servers will, where possible, transparently make use
-of RFC4507bis tickets for stateless session resumption.
+SSL/TLS supports two mechanisms for resuming sessions: session ids and stateless
+session tickets.
 
-If this option is set this functionality is disabled and tickets will
-not be used by clients or servers.
+When using session ids a copy of the session information is
+cached on the server and a unique id is sent to the client. When the client
+wishes to resume it provides the unique id so that the server can retrieve the
+session information from its cache.
 
-This option only applies to TLSv1.2 and below. It is ignored for TLSv1.3.
+When using stateless session tickets the server uses a session ticket encryption
+key to encrypt the session information. This encrypted data is sent to the
+client as a "ticket". When the client wishes to resume it sends the encrypted
+data back to the server. The server uses its key to decrypt the data and resume
+the session. In this way the server can operate statelessly - no session
+information needs to be cached locally.
+
+The TLSv1.3 protocol only supports tickets and does not directly support session
+ids. However OpenSSL allows two modes of ticket operation in TLSv1.3: stateful
+and stateless. Stateless tickets work the same way as in TLSv1.2 and below.
+Stateful tickets mimic the session id behaviour available in TLSv1.2 and below.
+The session information is cached on the server and the session id is wrapped up
+in a ticket and sent back to the client. When the client wishes to resume, it
+presents a ticket in the same way as for stateless tickets. The server can then
+extract the session id from the ticket and retrieve the session information from
+its cache.
+
+By default OpenSSL will use stateless tickets. The SSL_OP_NO_TICKET option will
+cause stateless tickets to not be issued. In TLSv1.2 and below this means no
+ticket gets sent to the client at all. In TLSv1.3 a stateful ticket will be
+sent. This is a server-side option only.
+
+In TLSv1.3 it is possible to suppress all tickets (stateful and stateless) from
+being sent by calling L<SSL_CTX_set_num_tickets(3)> or
+L<SSL_set_num_tickets(3)>.
 
 =item SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION
 

doc/man3/SSL_read_early_data.pod

@@ -226,12 +226,14 @@ was submitted will be ignored). Note that single use tickets are enforced even
 if a client does not send any early data.
 
 The replay protection mechanism relies on the internal OpenSSL server session
-cache (see L<SSL_CTX_set_session_cache_mode(3)>). By default sessions will be
-added to the cache whenever a session ticket is issued. When a client attempts
-to resume the session OpenSSL will check for its presence in the internal cache.
-If it exists then the resumption is allowed and the session is removed from the
-cache. If it does not exist then the resumption is not allowed and a full
-handshake will occur.
+cache (see L<SSL_CTX_set_session_cache_mode(3)>). When replay protection is
+being used the server will operate as if the SSL_OP_NO_TICKET option had been
+selected (see L<SSL_CTX_set_options(3)>). Sessions will be added to the cache
+whenever a session ticket is issued. When a client attempts to resume the
+session, OpenSSL will check for its presence in the internal cache. If it exists
+then the resumption is allowed and the session is removed from the cache. If it
+does not exist then the resumption is not allowed and a full handshake will
+occur.
 
 Note that some applications may maintain an external cache of sessions (see
 L<SSL_CTX_sess_set_new_cb(3)> and similar functions). It is the application's