update

doc/ssl/SSL_CIPHER_get_name.pod

@@ -23,8 +23,12 @@ SSL_CIPHER_get_bits() returns the number of secret bits used for B<cipher>. If
 B<alg_bits> is not NULL, it contains the number of bits processed by the
 chosen algorithm. If B<cipher> is NULL, 0 is returned.
 
-SSL_CIPHER_get_version() returns the protocol version for B<cipher>, currently
-"SSLv2", "SSLv3", or "TLSv1". If B<cipher> is NULL, "(NONE)" is returned.
+SSL_CIPHER_get_version() returns string which indicates the SSL/TLS protocol
+version that first defined the cipher.
+This is currently B<SSLv2> or B<TLSv1/SSLv3>.
+In some cases it should possibly return "TLSv1.2" but does not;
+use SSL_CIPHER_description() instead.
+If B<cipher> is NULL, "(NONE)" is returned.
 
 SSL_CIPHER_description() returns a textual description of the cipher used
 into the buffer B<buf> of length B<len> provided. B<len> must be at least
@@ -52,7 +56,8 @@ Textual representation of the cipher name.
 
 =item <protocol version>
 
-Protocol version: B<SSLv2>, B<SSLv3>. The TLSv1 ciphers are flagged with SSLv3.
+Protocol version: B<SSLv2>, B<SSLv3>, B<TLSv1.2>. The TLSv1.0 ciphers are
+flagged with SSLv3. No new ciphers were added by TLSv1.1.
 
 =item Kx=<key exchange>
 
@@ -91,6 +96,10 @@ Some examples for the output of SSL_CIPHER_description():
  RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
  EXP-RC4-MD5             SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export
 
+A comp[lete list can be retrieved by invoking the following command:
+
+ openssl ciphers -v ALL
+
 =head1 BUGS
 
 If SSL_CIPHER_description() is called with B<cipher> being NULL, the
@@ -100,6 +109,16 @@ If SSL_CIPHER_description() cannot handle a built-in cipher, the according
 description of the cipher property is B<unknown>. This case should not
 occur.
 
+The standard terminology for ephemeral Diffie-Hellman schemes is DHE
+(finite field) or ECDHE (elliptic curve).  This version of OpenSSL
+idiosyncratically reports these schemes as EDH and EECDH, even though
+it also accepts the standard terminology.
+
+It is recommended to use the standard terminology (DHE and ECDHE)
+during configuration (e.g. via SSL_CTX_set_cipher_list) for clarity of
+configuration.  OpenSSL versions after 1.0.2 will report the standard
+terms via SSL_CIPHER_get_name and SSL_CIPHER_description.
+
 =head1 RETURN VALUES
 
 See DESCRIPTION
@@ -107,6 +126,7 @@ See DESCRIPTION
 =head1 SEE ALSO
 
 L<ssl(3)|ssl(3)>, L<SSL_get_current_cipher(3)|SSL_get_current_cipher(3)>,
-L<SSL_get_ciphers(3)|SSL_get_ciphers(3)>, L<ciphers(1)|ciphers(1)>
+L<SSL_get_ciphers(3)|SSL_get_ciphers(3)>, L<ciphers(1)|ciphers(1)>,
+L<SSL_CTX_set_cipher_list(3)|SSL_CTX_set_cipher_list(3)>
 
 =cut

doc/ssl/SSL_COMP_add_compression_method.pod

@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-SSL_COMP_add_compression_method - handle SSL/TLS integrated compression methods
+SSL_COMP_add_compression_method, SSL_COMP_free_compression_methods - handle SSL/TLS integrated compression methods
 
 =head1 SYNOPSIS
 
@@ -10,6 +10,8 @@ SSL_COMP_add_compression_method - handle SSL/TLS integrated compression methods
 
  int SSL_COMP_add_compression_method(int id, COMP_METHOD *cm);
 
+ +void SSL_COMP_free_compression_methods(void);
+
 =head1 DESCRIPTION
 
 SSL_COMP_add_compression_method() adds the compression method B<cm> with
@@ -17,6 +19,10 @@ the identifier B<id> to the list of available compression methods. This
 list is globally maintained for all SSL operations within this application.
 It cannot be set for specific SSL_CTX or SSL objects.
 
+SSL_COMP_free_compression_methods() frees the internal table of
+compression methods that were built internally, and possibly
+augmented by adding SSL_COMP_add_compression_method().
+
 =head1 NOTES
 
 The TLS standard (or SSLv3) allows the integration of compression methods
@@ -38,8 +44,8 @@ its own compression methods and will unconditionally activate compression
 when a matching identifier is found. There is no way to restrict the list
 of compression methods supported on a per connection basis.
 
-The OpenSSL library has the compression methods B<COMP_rle()> and (when
-especially enabled during compilation) B<COMP_zlib()> available.
+If enabled during compilation, the OpenSSL library will have the
+COMP_zlib() compression method available.
 
 =head1 WARNINGS
 
@@ -53,11 +59,11 @@ SSL_COMP_add_compression_method() may return the following values:
 
 =over 4
 
-=item 0
+=item Z<>0
 
 The operation succeeded.
 
-=item 1
+=item Z<>1
 
 The operation failed. Check the error queue to find out the reason.
 

doc/ssl/SSL_CONF_CTX_new.pod

@@ -0,0 +1,40 @@
+=pod
+
+=head1 NAME
+
+SSL_CONF_CTX_new, SSL_CONF_CTX_free - SSL configuration allocation functions
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ SSL_CONF_CTX *SSL_CONF_CTX_new(void);
+ void SSL_CONF_CTX_free(SSL_CONF_CTX *cctx);
+
+=head1 DESCRIPTION
+
+The function SSL_CONF_CTX_new() allocates and initialises an B<SSL_CONF_CTX>
+structure for use with the SSL_CONF functions.
+
+The function SSL_CONF_CTX_free() frees up the context B<cctx>.
+
+=head1 RETURN VALUES
+
+SSL_CONF_CTX_new() returns either the newly allocated B<SSL_CONF_CTX> structure
+or B<NULL> if an error occurs.
+
+SSL_CONF_CTX_free() does not return a value.
+
+=head1 SEE ALSO
+
+L<SSL_CONF_CTX_set_flags(3)|SSL_CONF_CTX_set_flags(3)>,
+L<SSL_CONF_CTX_set_ssl_ctx(3)|SSL_CONF_CTX_set_ssl_ctx(3)>,
+L<SSL_CONF_CTX_set1_prefix(3)|SSL_CONF_CTX_set1_prefix(3)>,
+L<SSL_CONF_cmd(3)|SSL_CONF_cmd(3)>,
+L<SSL_CONF_cmd_argv(3)|SSL_CONF_cmd_argv(3)>
+
+=head1 HISTORY
+
+These functions were first added to OpenSSL 1.0.2
+
+=cut

doc/ssl/SSL_CONF_CTX_set1_prefix.pod

@@ -0,0 +1,49 @@
+=pod
+
+=head1 NAME
+
+SSL_CONF_CTX_set1_prefix - Set configuration context command prefix
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ unsigned int SSL_CONF_CTX_set1_prefix(SSL_CONF_CTX *cctx, const char *prefix);
+
+=head1 DESCRIPTION
+
+The function SSL_CONF_CTX_set1_prefix() sets the command prefix of B<cctx>
+to B<prefix>. If B<prefix> is B<NULL> it is restored to the default value.
+
+=head1 NOTES
+
+Command prefixes alter the commands recognised by subsequent SSL_CTX_cmd()
+calls. For example for files, if the prefix "SSL" is set then command names
+such as "SSLProtocol", "SSLOptions" etc. are recognised instead of "Protocol"
+and "Options". Similarly for command lines if the prefix is "--ssl-" then 
+"--ssl-no_tls1_2" is recognised instead of "-no_tls1_2".
+
+If the B<SSL_CONF_FLAG_CMDLINE> flag is set then prefix checks are case
+sensitive and "-" is the default. In the unlikely even an application
+explicitly wants to set no prefix it must be explicitly set to "".
+
+If the B<SSL_CONF_FLAG_FILE> flag is set then prefix checks are case
+insensitive and no prefix is the default.
+
+=head1 RETURN VALUES
+
+SSL_CONF_CTX_set1_prefix() returns 1 for success and 0 for failure.
+
+=head1 SEE ALSO
+
+L<SSL_CONF_CTX_new(3)|SSL_CONF_CTX_new(3)>,
+L<SSL_CONF_CTX_set_flags(3)|SSL_CONF_CTX_set_flags(3)>,
+L<SSL_CONF_CTX_set_ssl_ctx(3)|SSL_CONF_CTX_set_ssl_ctx(3)>,
+L<SSL_CONF_cmd(3)|SSL_CONF_cmd(3)>,
+L<SSL_CONF_cmd_argv(3)|SSL_CONF_cmd_argv(3)>
+
+=head1 HISTORY
+
+These functions were first added to OpenSSL 1.0.2
+
+=cut

doc/ssl/SSL_CONF_CTX_set_flags.pod

@@ -0,0 +1,68 @@
+=pod
+
+=head1 NAME
+
+SSL_CONF_CTX_set_flags, SSL_CONF_CTX_clear_flags - Set of clear SSL configuration context flags
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ unsigned int SSL_CONF_CTX_set_flags(SSL_CONF_CTX *cctx, unsigned int flags);
+ unsigned int SSL_CONF_CTX_clear_flags(SSL_CONF_CTX *cctx, unsigned int flags);
+
+=head1 DESCRIPTION
+
+The function SSL_CONF_CTX_set_flags() sets B<flags> in the context B<cctx>.
+
+The function SSL_CONF_CTX_clear_flags() clears B<flags> in the context B<cctx>.
+
+=head1 NOTES
+
+The flags set affect how subsequent calls to SSL_CONF_cmd() or
+SSL_CONF_argv() behave.
+
+Currently the following B<flags> values are recognised:
+
+=over 4
+
+=item SSL_CONF_FLAG_CMDLINE, SSL_CONF_FLAG_FILE
+
+recognise options intended for command line or configuration file use. At
+least one of these flags must be set.
+
+=item SSL_CONF_FLAG_CLIENT, SSL_CONF_FLAG_SERVER
+
+recognise options intended for use in SSL/TLS clients or servers. One or
+both of these flags must be set.
+
+=item SSL_CONF_FLAG_CERTIFICATE
+
+recognise certificate and private key options.
+
+=item SSL_CONF_FLAG_SHOW_ERRORS
+
+indicate errors relating to unrecognised options or missing arguments in
+the error queue. If this option isn't set such errors are only reflected
+in the return values of SSL_CONF_set_cmd() or SSL_CONF_set_argv()
+
+=back
+
+=head1 RETURN VALUES
+
+SSL_CONF_CTX_set_flags() and SSL_CONF_CTX_clear_flags() returns the new flags
+value after setting or clearing flags.
+
+=head1 SEE ALSO
+
+L<SSL_CONF_CTX_new(3)|SSL_CONF_CTX_new(3)>,
+L<SSL_CONF_CTX_set_ssl_ctx(3)|SSL_CONF_CTX_set_ssl_ctx(3)>,
+L<SSL_CONF_CTX_set1_prefix(3)|SSL_CONF_CTX_set1_prefix(3)>,
+L<SSL_CONF_cmd(3)|SSL_CONF_cmd(3)>,
+L<SSL_CONF_cmd_argv(3)|SSL_CONF_cmd_argv(3)>
+
+=head1 HISTORY
+
+These functions were first added to OpenSSL 1.0.2
+
+=cut

doc/ssl/SSL_CONF_CTX_set_ssl_ctx.pod

@@ -0,0 +1,47 @@
+=pod
+
+=head1 NAME
+
+SSL_CONF_CTX_set_ssl_ctx, SSL_CONF_CTX_set_ssl - set context to configure
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ void SSL_CONF_CTX_set_ssl_ctx(SSL_CONF_CTX *cctx, SSL_CTX *ctx);
+ void SSL_CONF_CTX_set_ssl(SSL_CONF_CTX *cctx, SSL *ssl);
+
+=head1 DESCRIPTION
+
+SSL_CONF_CTX_set_ssl_ctx() sets the context associated with B<cctx> to the
+B<SSL_CTX> structure B<ctx>. Any previous B<SSL> or B<SSL_CTX> associated with
+B<cctx> is cleared. Subsequent calls to SSL_CONF_cmd() will be sent to
+B<ctx>.
+
+SSL_CONF_CTX_set_ssl() sets the context associated with B<cctx> to the
+B<SSL> structure B<ssl>. Any previous B<SSL> or B<SSL_CTX> associated with
+B<cctx> is cleared. Subsequent calls to SSL_CONF_cmd() will be sent to
+B<ssl>.
+
+=head1 NOTES
+
+The context need not be set or it can be set to B<NULL> in which case only
+syntax checking of commands is performed, where possible.
+
+=head1 RETURN VALUES
+
+SSL_CONF_CTX_set_ssl_ctx() and SSL_CTX_set_ssl() do not return a value.
+
+=head1 SEE ALSO
+
+L<SSL_CONF_CTX_new(3)|SSL_CONF_CTX_new(3)>,
+L<SSL_CONF_CTX_set_flags(3)|SSL_CONF_CTX_set_flags(3)>,
+L<SSL_CONF_CTX_set1_prefix(3)|SSL_CONF_CTX_set1_prefix(3)>,
+L<SSL_CONF_cmd(3)|SSL_CONF_cmd(3)>,
+L<SSL_CONF_cmd_argv(3)|SSL_CONF_cmd_argv(3)>
+
+=head1 HISTORY
+
+These functions were first added to OpenSSL 1.0.2
+
+=cut

doc/ssl/SSL_CONF_cmd.pod

@@ -0,0 +1,438 @@
+=pod
+
+=head1 NAME
+
+SSL_CONF_cmd - send configuration command
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ int SSL_CONF_cmd(SSL_CONF_CTX *cctx, const char *cmd, const char *value);
+ int SSL_CONF_cmd_value_type(SSL_CONF_CTX *cctx, const char *cmd);
+ int SSL_CONF_finish(SSL_CONF_CTX *cctx);
+
+=head1 DESCRIPTION
+
+The function SSL_CONF_cmd() performs configuration operation B<cmd> with
+optional parameter B<value> on B<ctx>. Its purpose is to simplify application
+configuration of B<SSL_CTX> or B<SSL> structures by providing a common
+framework for command line options or configuration files.
+
+SSL_CONF_cmd_value_type() returns the type of value that B<cmd> refers to.
+
+The function SSL_CONF_finish() must be called after all configuration
+operations have been completed. It is used to finalise any operations
+or to process defaults.
+
+=head1 SUPPORTED COMMAND LINE COMMANDS
+
+Currently supported B<cmd> names for command lines (i.e. when the
+flag B<SSL_CONF_CMDLINE> is set) are listed below. Note: all B<cmd> names
+are case sensitive. Unless otherwise stated commands can be used by
+both clients and servers and the B<value> parameter is not used. The default
+prefix for command line commands is B<-> and that is reflected below.
+
+=over 4
+
+=item B<-sigalgs>
+
+This sets the supported signature algorithms for TLS v1.2. For clients this
+value is used directly for the supported signature algorithms extension. For
+servers it is used to determine which signature algorithms to support.
+
+The B<value> argument should be a colon separated list of signature algorithms
+in order of decreasing preference of the form B<algorithm+hash>. B<algorithm>
+is one of B<RSA>, B<DSA> or B<ECDSA> and B<hash> is a supported algorithm
+OID short name such as B<SHA1>, B<SHA224>, B<SHA256>, B<SHA384> of B<SHA512>.
+Note: algorithm and hash names are case sensitive.
+
+If this option is not set then all signature algorithms supported by the
+OpenSSL library are permissible.
+
+=item B<-client_sigalgs>
+
+This sets the supported signature algorithms associated with client
+authentication for TLS v1.2. For servers the value is used in the supported
+signature algorithms field of a certificate request. For clients it is
+used to determine which signature algorithm to with the client certificate.
+If a server does not request a certificate this option has no effect.
+
+The syntax of B<value> is identical to B<-sigalgs>. If not set then
+the value set for B<-sigalgs> will be used instead.
+
+=item B<-curves>
+
+This sets the supported elliptic curves. For clients the curves are
+sent using the supported curves extension. For servers it is used
+to determine which curve to use. This setting affects curves used for both
+signatures and key exchange, if applicable.
+
+The B<value> argument is a colon separated list of curves. The curve can be
+either the B<NIST> name (e.g. B<P-256>) or an OpenSSL OID name (e.g
+B<prime256v1>). Curve names are case sensitive.
+
+=item B<-named_curve>
+
+This sets the temporary curve used for ephemeral ECDH modes. Only used by 
+servers
+
+The B<value> argument is a curve name or the special value B<auto> which
+picks an appropriate curve based on client and server preferences. The curve
+can be either the B<NIST> name (e.g. B<P-256>) or an OpenSSL OID name
+(e.g B<prime256v1>). Curve names are case sensitive.
+
+=item B<-cipher>
+
+Sets the cipher suite list to B<value>. Note: syntax checking of B<value> is
+currently not performed unless a B<SSL> or B<SSL_CTX> structure is 
+associated with B<cctx>.
+
+=item B<-cert>
+
+Attempts to use the file B<value> as the certificate for the appropriate
+context. It currently uses SSL_CTX_use_certificate_chain_file() if an B<SSL_CTX>
+structure is set or SSL_use_certificate_file() with filetype PEM if an B<SSL>
+structure is set. This option is only supported if certificate operations
+are permitted.
+
+=item B<-key>
+
+Attempts to use the file B<value> as the private key for the appropriate
+context. This option is only supported if certificate operations
+are permitted. Note: if no B<-key> option is set then a private key is
+not loaded: it does not currently use the B<-cert> file.
+
+=item B<-dhparam>
+
+Attempts to use the file B<value> as the set of temporary DH parameters for
+the appropriate context. This option is only supported if certificate
+operations are permitted.
+
+=item B<-no_ssl2>, B<-no_ssl3>, B<-no_tls1>, B<-no_tls1_1>, B<-no_tls1_2>
+
+Disables protocol support for SSLv2, SSLv3, TLS 1.0, TLS 1.1 or TLS 1.2 
+by setting the corresponding options B<SSL_OP_NO_SSL2>, B<SSL_OP_NO_SSL3>,
+B<SSL_OP_NO_TLS1>, B<SSL_OP_NO_TLS1_1> and B<SSL_OP_NO_TLS1_2> respectively.
+
+=item B<-bugs>
+
+Various bug workarounds are set, same as setting B<SSL_OP_ALL>.
+
+=item B<-no_comp>
+
+Disables support for SSL/TLS compression, same as setting B<SSL_OP_NO_COMPRESS>.
+
+=item B<-no_ticket>
+
+Disables support for session tickets, same as setting B<SSL_OP_NO_TICKET>.
+
+=item B<-serverpref>
+
+Use server and not client preference order when determining which cipher suite,
+signature algorithm or elliptic curve to use for an incoming connection.
+Equivalent to B<SSL_OP_CIPHER_SERVER_PREFERENCE>. Only used by servers.
+
+=item B<-no_resumption_on_reneg>
+
+set SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION flag. Only used by servers.
+
+=item B<-legacyrenegotiation>
+
+permits the use of unsafe legacy renegotiation. Equivalent to setting
+B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION>.
+
+=item B<-legacy_server_connect>, B<-no_legacy_server_connect>
+
+permits or prohibits the use of unsafe legacy renegotiation for OpenSSL
+clients only. Equivalent to setting or clearing B<SSL_OP_LEGACY_SERVER_CONNECT>.
+Set by default.
+
+=item B<-strict>
+
+enables strict mode protocol handling. Equivalent to setting
+B<SSL_CERT_FLAG_TLS_STRICT>.
+
+=item B<-debug_broken_protocol>
+
+disables various checks and permits several kinds of broken protocol behaviour
+for testing purposes: it should B<NEVER> be used in anything other than a test
+environment. Only supported if OpenSSL is configured with
+B<-DOPENSSL_SSL_DEBUG_BROKEN_PROTOCOL>.
+
+=back
+
+=head1 SUPPORTED CONFIGURATION FILE COMMANDS
+
+Currently supported B<cmd> names for configuration files (i.e. when the
+flag B<SSL_CONF_FLAG_FILE> is set) are listed below. All configuration file
+B<cmd> names and are case insensitive so B<signaturealgorithms> is recognised
+as well as B<SignatureAlgorithms>. Unless otherwise stated the B<value> names
+are also case insensitive.
+
+Note: the command prefix (if set) alters the recognised B<cmd> values.
+
+=over 4
+
+=item B<CipherString>
+
+Sets the cipher suite list to B<value>. Note: syntax checking of B<value> is
+currently not performed unless an B<SSL> or B<SSL_CTX> structure is 
+associated with B<cctx>.
+
+=item B<Certificate>
+
+Attempts to use the file B<value> as the certificate for the appropriate
+context. It currently uses SSL_CTX_use_certificate_chain_file() if an B<SSL_CTX>
+structure is set or SSL_use_certificate_file() with filetype PEM if an B<SSL>
+structure is set. This option is only supported if certificate operations
+are permitted.
+
+=item B<PrivateKey>
+
+Attempts to use the file B<value> as the private key for the appropriate
+context. This option is only supported if certificate operations
+are permitted. Note: if no B<-key> option is set then a private key is
+not loaded: it does not currently use the B<Certificate> file.
+
+=item B<ServerInfoFile>
+
+Attempts to use the file B<value> in the "serverinfo" extension using the
+function SSL_CTX_use_serverinfo_file.
+
+=item B<DHParameters>
+
+Attempts to use the file B<value> as the set of temporary DH parameters for
+the appropriate context. This option is only supported if certificate
+operations are permitted.
+
+=item B<SignatureAlgorithms>
+
+This sets the supported signature algorithms for TLS v1.2. For clients this
+value is used directly for the supported signature algorithms extension. For
+servers it is used to determine which signature algorithms to support.
+
+The B<value> argument should be a colon separated list of signature algorithms
+in order of decreasing preference of the form B<algorithm+hash>. B<algorithm>
+is one of B<RSA>, B<DSA> or B<ECDSA> and B<hash> is a supported algorithm
+OID short name such as B<SHA1>, B<SHA224>, B<SHA256>, B<SHA384> of B<SHA512>.
+Note: algorithm and hash names are case sensitive.
+
+If this option is not set then all signature algorithms supported by the
+OpenSSL library are permissible.
+
+=item B<ClientSignatureAlgorithms>
+
+This sets the supported signature algorithms associated with client
+authentication for TLS v1.2. For servers the value is used in the supported
+signature algorithms field of a certificate request. For clients it is
+used to determine which signature algorithm to with the client certificate.
+
+The syntax of B<value> is identical to B<SignatureAlgorithms>. If not set then
+the value set for B<SignatureAlgorithms> will be used instead.
+
+=item B<Curves>
+
+This sets the supported elliptic curves. For clients the curves are
+sent using the supported curves extension. For servers it is used
+to determine which curve to use. This setting affects curves used for both
+signatures and key exchange, if applicable.
+
+The B<value> argument is a colon separated list of curves. The curve can be
+either the B<NIST> name (e.g. B<P-256>) or an OpenSSL OID name (e.g
+B<prime256v1>). Curve names are case sensitive.
+
+=item B<ECDHParameters>
+
+This sets the temporary curve used for ephemeral ECDH modes. Only used by 
+servers
+
+The B<value> argument is a curve name or the special value B<Automatic> which
+picks an appropriate curve based on client and server preferences. The curve
+can be either the B<NIST> name (e.g. B<P-256>) or an OpenSSL OID name
+(e.g B<prime256v1>). Curve names are case sensitive.
+
+=item B<Protocol>
+
+The supported versions of the SSL or TLS protocol.
+
+The B<value> argument is a comma separated list of supported protocols to
+enable or disable. If an protocol is preceded by B<-> that version is disabled.
+All versions are enabled by default, though applications may choose to
+explicitly disable some. Currently supported protocol values are B<SSLv2>,
+B<SSLv3>, B<TLSv1>, B<TLSv1.1> and B<TLSv1.2>. The special value B<ALL> refers
+to all supported versions.
+
+=item B<Options>
+
+The B<value> argument is a comma separated list of various flags to set.
+If a flag string is preceded B<-> it is disabled. See the
+B<SSL_CTX_set_options> function for more details of individual options.
+
+Each option is listed below. Where an operation is enabled by default
+the B<-flag> syntax is needed to disable it.
+
+B<SessionTicket>: session ticket support, enabled by default. Inverse of
+B<SSL_OP_NO_TICKET>: that is B<-SessionTicket> is the same as setting
+B<SSL_OP_NO_TICKET>.
+
+B<Compression>: SSL/TLS compression support, enabled by default. Inverse
+of B<SSL_OP_NO_COMPRESSION>.
+
+B<EmptyFragments>: use empty fragments as a countermeasure against a
+SSL 3.0/TLS 1.0 protocol vulnerability affecting CBC ciphers. It
+is set by default. Inverse of B<SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS>.
+
+B<Bugs>: enable various bug workarounds. Same as B<SSL_OP_ALL>.
+
+B<DHSingle>: enable single use DH keys, set by default. Inverse of
+B<SSL_OP_DH_SINGLE>. Only used by servers.
+
+B<ECDHSingle> enable single use ECDH keys, set by default. Inverse of
+B<SSL_OP_ECDH_SINGLE>. Only used by servers.
+
+B<ServerPreference> use server and not client preference order when
+determining which cipher suite, signature algorithm or elliptic curve
+to use for an incoming connection.  Equivalent to
+B<SSL_OP_CIPHER_SERVER_PREFERENCE>. Only used by servers.
+
+B<NoResumptionOnRenegotiation> set
+B<SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION> flag. Only used by servers.
+
+B<UnsafeLegacyRenegotiation> permits the use of unsafe legacy renegotiation.
+Equivalent to B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION>.
+
+B<UnsafeLegacyServerConnect> permits the use of unsafe legacy renegotiation
+for OpenSSL clients only. Equivalent to B<SSL_OP_LEGACY_SERVER_CONNECT>.
+Set by default.
+
+=back
+
+=head1 SUPPORTED COMMAND TYPES
+
+The function SSL_CONF_cmd_value_type() currently returns one of the following
+types:
+
+=over 4
+
+=item B<SSL_CONF_TYPE_UNKNOWN>
+
+The B<cmd> string is unrecognised, this return value can be use to flag
+syntax errors.
+
+=item B<SSL_CONF_TYPE_STRING>
+
+The value is a string without any specific structure.
+
+=item B<SSL_CONF_TYPE_FILE>
+
+The value is a file name.
+
+=item B<SSL_CONF_TYPE_DIR>
+
+The value is a directory name.
+
+=back
+
+=head1 NOTES
+
+The order of operations is significant. This can be used to set either defaults
+or values which cannot be overridden. For example if an application calls:
+
+ SSL_CONF_cmd(ctx, "Protocol", "-SSLv2");
+ SSL_CONF_cmd(ctx, userparam, uservalue);
+
+it will disable SSLv2 support by default but the user can override it. If 
+however the call sequence is:
+
+ SSL_CONF_cmd(ctx, userparam, uservalue);
+ SSL_CONF_cmd(ctx, "Protocol", "-SSLv2");
+
+SSLv2 is B<always> disabled and attempt to override this by the user are
+ignored.
+
+By checking the return code of SSL_CTX_cmd() it is possible to query if a
+given B<cmd> is recognised, this is useful is SSL_CTX_cmd() values are
+mixed with additional application specific operations.
+
+For example an application might call SSL_CTX_cmd() and if it returns
+-2 (unrecognised command) continue with processing of application specific
+commands.
+
+Applications can also use SSL_CTX_cmd() to process command lines though the
+utility function SSL_CTX_cmd_argv() is normally used instead. One way
+to do this is to set the prefix to an appropriate value using
+SSL_CONF_CTX_set1_prefix(), pass the current argument to B<cmd> and the
+following argument to B<value> (which may be NULL).
+
+In this case if the return value is positive then it is used to skip that
+number of arguments as they have been processed by SSL_CTX_cmd(). If -2 is
+returned then B<cmd> is not recognised and application specific arguments
+can be checked instead. If -3 is returned a required argument is missing
+and an error is indicated. If 0 is returned some other error occurred and
+this can be reported back to the user.
+
+The function SSL_CONF_cmd_value_type() can be used by applications to 
+check for the existence of a command or to perform additional syntax
+checking or translation of the command value. For example if the return
+value is B<SSL_CONF_TYPE_FILE> an application could translate a relative
+pathname to an absolute pathname.
+
+=head1 EXAMPLES
+
+Set supported signature algorithms:
+
+ SSL_CONF_cmd(ctx, "SignatureAlgorithms", "ECDSA+SHA256:RSA+SHA256:DSA+SHA256");
+
+Enable all protocols except SSLv3 and SSLv2:
+
+ SSL_CONF_cmd(ctx, "Protocol", "ALL,-SSLv3,-SSLv2");
+
+Only enable TLSv1.2:
+
+ SSL_CONF_cmd(ctx, "Protocol", "-ALL,TLSv1.2");
+
+Disable TLS session tickets:
+
+ SSL_CONF_cmd(ctx, "Options", "-SessionTicket");
+
+Set supported curves to P-256, P-384:
+
+ SSL_CONF_cmd(ctx, "Curves", "P-256:P-384");
+
+Set automatic support for any elliptic curve for key exchange:
+
+ SSL_CONF_cmd(ctx, "ECDHParameters", "Automatic");
+
+=head1 RETURN VALUES
+
+SSL_CONF_cmd() returns 1 if the value of B<cmd> is recognised and B<value> is
+B<NOT> used and 2 if both B<cmd> and B<value> are used. In other words it
+returns the number of arguments processed. This is useful when processing
+command lines.
+
+A return value of -2 means B<cmd> is not recognised.
+
+A return value of -3 means B<cmd> is recognised and the command requires a
+value but B<value> is NULL.
+
+A return code of 0 indicates that both B<cmd> and B<value> are valid but an
+error occurred attempting to perform the operation: for example due to an
+error in the syntax of B<value> in this case the error queue may provide
+additional information.
+
+SSL_CONF_finish() returns 1 for success and 0 for failure.
+
+=head1 SEE ALSO
+
+L<SSL_CONF_CTX_new(3)|SSL_CONF_CTX_new(3)>,
+L<SSL_CONF_CTX_set_flags(3)|SSL_CONF_CTX_set_flags(3)>,
+L<SSL_CONF_CTX_set1_prefix(3)|SSL_CONF_CTX_set1_prefix(3)>,
+L<SSL_CONF_CTX_set_ssl_ctx(3)|SSL_CONF_CTX_set_ssl_ctx(3)>,
+L<SSL_CONF_cmd_argv(3)|SSL_CONF_cmd_argv(3)>
+
+=head1 HISTORY
+
+SSL_CONF_cmd() was first added to OpenSSL 1.0.2
+
+=cut

doc/ssl/SSL_CONF_cmd_argv.pod

@@ -0,0 +1,42 @@
+=pod
+
+=head1 NAME
+
+SSL_CONF_cmd_argv - SSL configuration command line processing.
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ int SSL_CONF_cmd_argv(SSL_CONF_CTX *cctx, int *pargc, char ***pargv);
+
+=head1 DESCRIPTION
+
+The function SSL_CONF_cmd_argv() processes at most two command line
+arguments from B<pargv> and B<pargc>. The values of B<pargv> and B<pargc>
+are updated to reflect the number of command options processed. The B<pargc>
+argument can be set to B<NULL> is it is not used.
+
+=head1 RETURN VALUES
+
+SSL_CONF_cmd_argv() returns the number of command arguments processed: 0, 1, 2
+or a negative error code.
+
+If -2 is returned then an argument for a command is missing.
+
+If -1 is returned the command is recognised but couldn't be processed due
+to an error: for example a syntax error in the argument.
+
+=head1 SEE ALSO
+
+L<SSL_CONF_CTX_new(3)|SSL_CONF_CTX_new(3)>,
+L<SSL_CONF_CTX_set_flags(3)|SSL_CONF_CTX_set_flags(3)>,
+L<SSL_CONF_CTX_set1_prefix(3)|SSL_CONF_CTX_set1_prefix(3)>,
+L<SSL_CONF_CTX_set_ssl_ctx(3)|SSL_CONF_CTX_set_ssl_ctx(3)>,
+L<SSL_CONF_cmd(3)|SSL_CONF_cmd(3)>
+
+=head1 HISTORY
+
+These functions were first added to OpenSSL 1.0.2
+
+=cut

doc/ssl/SSL_CTX_add1_chain_cert.pod

@@ -0,0 +1,150 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set0_chain, SSL_CTX_set1_chain, SSL_CTX_add0_chain_cert,
+SSL_CTX_add1_chain_cert, SSL_CTX_get0_chain_certs, SSL_CTX_clear_chain_certs,
+SSL_set0_chain, SSL_set1_chain, SSL_add0_chain_cert, SSL_add1_chain_cert,
+SSL_get0_chain_certs, SSL_clear_chain_certs, SSL_CTX_build_cert_chain,
+SSL_build_cert_chain, SSL_CTX_select_current_cert,
+SSL_select_current_cert, SSL_CTX_set_current_cert, SSL_set_current_cert - extra
+chain certificate processing
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ int SSL_CTX_set0_chain(SSL_CTX *ctx, STACK_OF(X509) *sk);
+ int SSL_CTX_set1_chain(SSL_CTX *ctx, STACK_OF(X509) *sk);
+ int SSL_CTX_add0_chain_cert(SSL_CTX *ctx, X509 *x509);
+ int SSL_CTX_add1_chain_cert(SSL_CTX *ctx, X509 *x509);
+ int SSL_CTX_get0_chain_certs(SSL_CTX *ctx, STACK_OF(X509) **sk);
+ int SSL_CTX_clear_chain_certs(SSL_CTX *ctx);
+
+ int SSL_set0_chain(SSL *ssl, STACK_OF(X509) *sk);
+ int SSL_set1_chain(SSL *ssl, STACK_OF(X509) *sk);
+ int SSL_add0_chain_cert(SSL *ssl, X509 *x509);
+ int SSL_add1_chain_cert(SSL *ssl, X509 *x509);
+ int SSL_get0_chain_certs(SSL *ssl, STACK_OF(X509) **sk);
+ int SSL_clear_chain_certs(SSL *ssl);
+
+ int SSL_CTX_build_cert_chain(SSL_CTX *ctx, flags);
+ int SSL_build_cert_chain(SSL *ssl, flags);
+
+ int SSL_CTX_select_current_cert(SSL_CTX *ctx, X509 *x509);
+ int SSL_select_current_cert(SSL *ssl, X509 *x509);
+ int SSL_CTX_set_current_cert(SSL_CTX *ctx, long op);
+ int SSL_set_current_cert(SSL *ssl, long op);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set0_chain() and SSL_CTX_set1_chain() set the certificate chain
+associated with the current certificate of B<ctx> to B<sk>.
+
+SSL_CTX_add0_chain_cert() and SSL_CTX_add1_chain_cert() append the single
+certificate B<x509> to the chain associated with the current certificate of
+B<ctx>.
+
+SSL_CTX_get0_chain_certs() retrieves the chain associated with the current
+certificate of B<ctx>.
+
+SSL_CTX_clear_chain_certs() clears any existing chain associated with the
+current certificate of B<ctx>.  (This is implemented by calling
+SSL_CTX_set0_chain() with B<sk> set to B<NULL>).
+
+SSL_CTX_build_cert_chain() builds the certificate chain for B<ctx> normally
+this uses the chain store or the verify store if the chain store is not set.
+If the function is successful the built chain will replace any existing chain.
+The B<flags> parameter can be set to B<SSL_BUILD_CHAIN_FLAG_UNTRUSTED> to use
+existing chain certificates as untrusted CAs, B<SSL_BUILD_CHAIN_FLAG_NO_ROOT>
+to omit the root CA from the built chain, B<SSL_BUILD_CHAIN_FLAG_CHECK> to
+use all existing chain certificates only to build the chain (effectively
+sanity checking and rearranging them if necessary), the flag
+B<SSL_BUILD_CHAIN_FLAG_IGNORE_ERROR> ignores any errors during verification:
+if flag B<SSL_BUILD_CHAIN_FLAG_CLEAR_ERROR> is also set verification errors
+are cleared from the error queue.
+
+Each of these functions operates on the I<current> end entity
+(i.e. server or client) certificate. This is the last certificate loaded or
+selected on the corresponding B<ctx> structure.
+
+SSL_CTX_select_current_cert() selects B<x509> as the current end entity
+certificate, but only if B<x509> has already been loaded into B<ctx> using a
+function such as SSL_CTX_use_certificate().
+
+SSL_set0_chain(), SSL_set1_chain(), SSL_add0_chain_cert(),
+SSL_add1_chain_cert(), SSL_get0_chain_certs(), SSL_clear_chain_certs(),
+SSL_build_cert_chain(), SSL_select_current_cert() and SSL_set_current_cert()
+are similar except they apply to SSL structure B<ssl>.
+
+SSL_CTX_set_current_cert() changes the current certificate to a value based
+on the B<op> argument. Currently B<op> can be B<SSL_CERT_SET_FIRST> to use
+the first valid certificate or B<SSL_CERT_SET_NEXT> to set the next valid
+certificate after the current certificate. These two operations can be
+used to iterate over all certificates in an B<SSL_CTX> structure.
+
+SSL_set_current_cert() also supports the option B<SSL_CERT_SET_SERVER>.
+If B<ssl> is a server and has sent a certificate to a connected client
+this option sets that certificate to the current certificate and returns 1.
+If the negotiated ciphersuite is anonymous (and thus no certificate will
+be sent) 2 is returned and the current certificate is unchanged. If B<ssl>
+is not a server or a certificate has not been sent 0 is returned and
+the current certificate is unchanged.
+
+All these functions are implemented as macros. Those containing a B<1>
+increment the reference count of the supplied certificate or chain so it must
+be freed at some point after the operation. Those containing a B<0> do
+not increment reference counts and the supplied certificate or chain
+B<MUST NOT> be freed after the operation.
+
+=head1 NOTES
+
+The chains associate with an SSL_CTX structure are copied to any SSL
+structures when SSL_new() is called. SSL structures will not be affected
+by any chains subsequently changed in the parent SSL_CTX.
+
+One chain can be set for each key type supported by a server. So, for example,
+an RSA and a DSA certificate can (and often will) have different chains.
+
+The functions SSL_CTX_build_cert_chain() and SSL_build_cert_chain() can
+be used to check application configuration and to ensure any necessary
+subordinate CAs are sent in the correct order. Misconfigured applications
+sending incorrect certificate chains often cause problems with peers.
+
+For example an application can add any set of certificates using
+SSL_CTX_use_certificate_chain_file() then call SSL_CTX_build_cert_chain()
+with the option B<SSL_BUILD_CHAIN_FLAG_CHECK> to check and reorder them.
+
+Applications can issue non fatal warnings when checking chains by setting
+the flag B<SSL_BUILD_CHAIN_FLAG_IGNORE_ERRORS> and checking the return
+value.
+
+Calling SSL_CTX_build_cert_chain() or SSL_build_cert_chain() is more
+efficient than the automatic chain building as it is only performed once.
+Automatic chain building is performed on each new session.
+
+If any certificates are added using these functions no certificates added
+using SSL_CTX_add_extra_chain_cert() will be used.
+
+=head1 RETURN VALUES
+
+SSL_set_current_cert() with B<SSL_CERT_SET_SERVER> return 1 for success, 2 if
+no server certificate is used because the ciphersuites is anonymous and 0
+for failure.
+
+SSL_CTX_build_cert_chain() and SSL_build_cert_chain() return 1 for success
+and 0 for failure. If the flag B<SSL_BUILD_CHAIN_FLAG_IGNORE_ERROR> and
+a verification error occurs then 2 is returned.
+
+All other functions return 1 for success and 0 for failure.
+
+
+=head1 SEE ALSO
+
+L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>
+
+=head1 HISTORY
+
+These functions were first added to OpenSSL 1.0.2.
+
+=cut

doc/ssl/SSL_CTX_add_extra_chain_cert.pod

@@ -24,6 +24,17 @@ the library will try to complete the chain from the available CA
 certificates in the trusted CA storage, see
 L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>.
 
+The B<x509> certificate provided to SSL_CTX_add_extra_chain_cert() will be freed by the library when the B<SSL_CTX> is destroyed. An application B<should not> free the B<x509> object.
+
+=head1 RESTRICTIONS
+
+Only one set of extra chain certificates can be specified per SSL_CTX
+structure. Different chains for different certificates (for example if both
+RSA and DSA certificates are specified by the same server) or different SSL
+structures with the same parent SSL_CTX cannot be specified using this
+function. For more flexibility functions such as SSL_add1_chain_cert() should
+be used instead.
+
 =head1 RETURN VALUES
 
 SSL_CTX_add_extra_chain_cert() returns 1 on success. Check out the
@@ -35,5 +46,15 @@ L<ssl(3)|ssl(3)>,
 L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)>,
 L<SSL_CTX_set_client_cert_cb(3)|SSL_CTX_set_client_cert_cb(3)>,
 L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>
+L<SSL_CTX_set0_chain(3)|SSL_CTX_set0_chain(3)>
+L<SSL_CTX_set1_chain(3)|SSL_CTX_set1_chain(3)>
+L<SSL_CTX_add0_chain_cert(3)|SSL_CTX_add0_chain_cert(3)>
+L<SSL_CTX_add1_chain_cert(3)|SSL_CTX_add1_chain_cert(3)>
+L<SSL_set0_chain(3)|SSL_set0_chain(3)>
+L<SSL_set1_chain(3)|SSL_set1_chain(3)>
+L<SSL_add0_chain_cert(3)|SSL_add0_chain_cert(3)>
+L<SSL_add1_chain_cert(3)|SSL_add1_chain_cert(3)>
+L<SSL_CTX_build_cert_chain(3)|SSL_CTX_build_cert_chain(3)>
+L<SSL_build_cert_chain(3)|SSL_build_cert_chain(3)>
 
 =cut

doc/ssl/SSL_CTX_add_session.pod

@@ -41,7 +41,7 @@ If a server SSL_CTX is configured with the SSL_SESS_CACHE_NO_INTERNAL_STORE
 flag then the internal cache will not be populated automatically by new
 sessions negotiated by the SSL/TLS implementation, even though the internal
 cache will be searched automatically for session-resume requests (the
-latter can be surpressed by SSL_SESS_CACHE_NO_INTERNAL_LOOKUP). So the
+latter can be suppressed by SSL_SESS_CACHE_NO_INTERNAL_LOOKUP). So the
 application can use SSL_CTX_add_session() directly to have full control
 over the sessions that can be resumed if desired.
 
@@ -52,13 +52,13 @@ The following values are returned by all functions:
 
 =over 4
 
-=item 0
+=item Z<>0
 
  The operation failed. In case of the add operation, it was tried to add
  the same (identical) session twice. In case of the remove operation, the
  session was not found in the cache.
 
-=item 1
+=item Z<>1
  
  The operation succeeded.
 

doc/ssl/SSL_CTX_get0_param.pod

@@ -0,0 +1,55 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_get0_param, SSL_get0_param, SSL_CTX_set1_param, SSL_set1_param -
+get and set verification parameters
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ X509_VERIFY_PARAM *SSL_CTX_get0_param(SSL_CTX *ctx)
+ X509_VERIFY_PARAM *SSL_get0_param(SSL *ssl)
+ int SSL_CTX_set1_param(SSL_CTX *ctx, X509_VERIFY_PARAM *vpm)
+ int SSL_set1_param(SSL *ssl, X509_VERIFY_PARAM *vpm)
+
+=head1 DESCRIPTION
+
+SSL_CTX_get0_param() and SSL_get0_param() retrieve an internal pointer to
+the verification parameters for B<ctx> or B<ssl> respectively. The returned
+pointer must not be freed by the calling application.
+
+SSL_CTX_set1_param() and SSL_set1_param() set the verification parameters
+to B<vpm> for B<ctx> or B<ssl>.
+
+=head1 NOTES
+
+Typically parameters are retrieved from an B<SSL_CTX> or B<SSL> structure
+using SSL_CTX_get0_param() or SSL_get0_param() and an application modifies
+them to suit its needs: for example to add a hostname check.
+
+=head1 EXAMPLE
+
+Check hostname matches "www.foo.com" in peer certificate:
+
+ X509_VERIFY_PARAM *vpm = SSL_get0_param(ssl);
+ X509_VERIFY_PARAM_set1_host(vpm, "www.foo.com");
+
+=head1 RETURN VALUES
+
+SSL_CTX_get0_param() and SSL_get0_param() return a pointer to an
+B<X509_VERIFY_PARAM> structure.
+
+SSL_CTX_set1_param() and SSL_set1_param() return 1 for success and 0
+for failure.
+
+=head1 SEE ALSO
+
+L<X509_VERIFY_PARAM_set_flags(3)|X509_VERIFY_PARAM_set_flags(3)>
+
+=head1 HISTORY
+
+These functions were first added to OpenSSL 1.0.2.
+
+=cut

doc/ssl/SSL_CTX_load_verify_locations.pod

@@ -100,13 +100,13 @@ The following return values can occur:
 
 =over 4
 
-=item 0
+=item Z<>0
 
 The operation failed because B<CAfile> and B<CApath> are NULL or the
 processing at one of the locations specified failed. Check the error
 stack to find out the reason.
 
-=item 1
+=item Z<>1
 
 The operation succeeded.
 

doc/ssl/SSL_CTX_new.pod

@@ -51,22 +51,36 @@ SSLv3 client hello messages.
 
 =item SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
 
-A TLS/SSL connection established with these methods will understand the SSLv2,
-SSLv3, and TLSv1 protocol. A client will send out SSLv2 client hello messages
-and will indicate that it also understands SSLv3 and TLSv1. A server will
-understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the best
-choice when compatibility is a concern.
+A TLS/SSL connection established with these methods may understand the SSLv2,
+SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols.
+
+If the cipher list does not contain any SSLv2 ciphersuites (the default
+cipher list does not) or extensions are required (for example server name)
+a client will send out TLSv1 client hello messages including extensions and
+will indicate that it also understands TLSv1.1, TLSv1.2 and permits a
+fallback to SSLv3. A server will support SSLv3, TLSv1, TLSv1.1 and TLSv1.2
+protocols. This is the best choice when compatibility is a concern.
+
+If any SSLv2 ciphersuites are included in the cipher list and no extensions
+are required then SSLv2 compatible client hellos will be used by clients and
+SSLv2 will be accepted by servers. This is B<not> recommended due to the
+insecurity of SSLv2 and the limited nature of the SSLv2 client hello
+prohibiting the use of extensions.
 
 =back
 
 The list of protocols available can later be limited using the SSL_OP_NO_SSLv2,
-SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the B<SSL_CTX_set_options()> or
-B<SSL_set_options()> functions. Using these options it is possible to choose
-e.g. SSLv23_server_method() and be able to negotiate with all possible
-clients, but to only allow newer protocols like SSLv3 or TLSv1.
+SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2
+options of the SSL_CTX_set_options() or SSL_set_options() functions.
+Using these options it is possible to choose e.g. SSLv23_server_method() and
+be able to negotiate with all possible clients, but to only allow newer
+protocols like TLSv1, TLSv1.1 or TLS v1.2.
+
+Applications which never want to support SSLv2 (even is the cipher string
+is configured to use SSLv2 ciphersuites) can set SSL_OP_NO_SSLv2.
 
 SSL_CTX_new() initializes the list of ciphers, the session cache setting,
-the callbacks, the keys and certificates, and the options to its default
+the callbacks, the keys and certificates and the options to its default
 values.
 
 =head1 RETURN VALUES

doc/ssl/SSL_CTX_sess_set_cache_size.pod

@@ -15,6 +15,7 @@ SSL_CTX_sess_set_cache_size, SSL_CTX_sess_get_cache_size - manipulate session ca
 
 SSL_CTX_sess_set_cache_size() sets the size of the internal session cache
 of context B<ctx> to B<t>.
+This value is a hint and not an absolute; see the notes below.
 
 SSL_CTX_sess_get_cache_size() returns the currently valid session cache size.
 
@@ -25,8 +26,9 @@ currently 1024*20, so that up to 20000 sessions can be held. This size
 can be modified using the SSL_CTX_sess_set_cache_size() call. A special
 case is the size 0, which is used for unlimited size.
 
-When the maximum number of sessions is reached, no more new sessions are
-added to the cache. New space may be added by calling
+If adding the session makes the cache exceed its size, then unused
+sessions are dropped from the end of the cache.
+Cache space may also be reclaimed by calling
 L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)> to remove
 expired sessions.
 

doc/ssl/SSL_CTX_set1_curves.pod

@@ -0,0 +1,103 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set1_curves, SSL_CTX_set1_curves_list, SSL_set1_curves,
+SSL_set1_curves_list, SSL_get1_curves, SSL_get_shared_curve,
+SSL_CTX_set_ecdh_auto, SSL_set_ecdh_auto - EC supported curve functions
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ int SSL_CTX_set1_curves(SSL_CTX *ctx, int *clist, int clistlen);
+ int SSL_CTX_set1_curves_list(SSL_CTX *ctx, char *list);
+
+ int SSL_set1_curves(SSL *ssl, int *clist, int clistlen);
+ int SSL_set1_curves_list(SSL *ssl, char *list);
+
+ int SSL_get1_curves(SSL *ssl, int *curves);
+ int SSL_get_shared_curve(SSL *s, int n);
+
+ int SSL_CTX_set_ecdh_auto(SSL_CTX *ctx, int onoff);
+ int SSL_set_ecdh_auto(SSL *s, int onoff);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set1_curves() sets the supported curves for B<ctx> to B<clistlen>
+curves in the array B<clist>. The array consist of all NIDs of curves in
+preference order. For a TLS client the curves are used directly in the
+supported curves extension. For a TLS server the curves are used to 
+determine the set of shared curves.
+
+SSL_CTX_set1_curves_list() sets the supported curves for B<ctx> to
+string B<list>. The string is a colon separated list of curve NIDs or
+names, for example "P-521:P-384:P-256".
+
+SSL_set1_curves() and SSL_set1_curves_list() are similar except they set
+supported curves for the SSL structure B<ssl>.
+
+SSL_get1_curves() returns the set of supported curves sent by a client
+in the supported curves extension. It returns the total number of 
+supported curves. The B<curves> parameter can be B<NULL> to simply
+return the number of curves for memory allocation purposes. The
+B<curves> array is in the form of a set of curve NIDs in preference
+order. It can return zero if the client did not send a supported curves
+extension.
+
+SSL_get_shared_curve() returns shared curve B<n> for a server-side
+SSL B<ssl>. If B<n> is -1 then the total number of shared curves is
+returned, which may be zero. Other than for diagnostic purposes,
+most applications will only be interested in the first shared curve
+so B<n> is normally set to zero. If the value B<n> is out of range,
+NID_undef is returned.
+
+SSL_CTX_set_ecdh_auto() and SSL_set_ecdh_auto() set automatic curve
+selection for server B<ctx> or B<ssl> to B<onoff>. If B<onoff> is 1 then 
+the highest preference curve is automatically used for ECDH temporary
+keys used during key exchange.
+
+All these functions are implemented as macros.
+
+=head1 NOTES
+
+If an application wishes to make use of several of these functions for
+configuration purposes either on a command line or in a file it should
+consider using the SSL_CONF interface instead of manually parsing options.
+
+The functions SSL_CTX_set_ecdh_auto() and SSL_set_ecdh_auto() can be used to
+make a server always choose the most appropriate curve for a client. If set
+it will override any temporary ECDH parameters set by a server. Previous
+versions of OpenSSL could effectively only use a single ECDH curve set
+using a function such as SSL_CTX_set_ecdh_tmp(). Newer applications should
+just call:
+
+ SSL_CTX_set_ecdh_auto(ctx, 1);
+
+and they will automatically support ECDH using the most appropriate shared
+curve.
+
+=head1 RETURN VALUES
+
+SSL_CTX_set1_curves(), SSL_CTX_set1_curves_list(), SSL_set1_curves(),
+SSL_set1_curves_list(), SSL_CTX_set_ecdh_auto() and SSL_set_ecdh_auto()
+return 1 for success and 0 for failure.
+
+SSL_get1_curves() returns the number of curves, which may be zero.
+
+SSL_get_shared_curve() returns the NID of shared curve B<n> or NID_undef if there
+is no shared curve B<n>; or the total number of shared curves if B<n>
+is -1.
+
+When called on a client B<ssl>, SSL_get_shared_curve() has no meaning and
+returns -1.
+
+=head1 SEE ALSO
+
+L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>
+
+=head1 HISTORY
+
+These functions were first added to OpenSSL 1.0.2.
+
+=cut

doc/ssl/SSL_CTX_set1_verify_cert_store.pod

@@ -0,0 +1,91 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set0_verify_cert_store, SSL_CTX_set1_verify_cert_store,
+SSL_CTX_set0_chain_cert_store, SSL_CTX_set1_chain_cert_store,
+SSL_set0_verify_cert_store, SSL_set1_verify_cert_store,
+SSL_set0_chain_cert_store, SSL_set1_chain_cert_store - set certificate
+verification or chain store
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ int SSL_CTX_set0_verify_cert_store(SSL_CTX *ctx, X509_STORE *st);
+ int SSL_CTX_set1_verify_cert_store(SSL_CTX *ctx, X509_STORE *st);
+ int SSL_CTX_set0_chain_cert_store(SSL_CTX *ctx, X509_STORE *st);
+ int SSL_CTX_set1_chain_cert_store(SSL_CTX *ctx, X509_STORE *st);
+
+ int SSL_set0_verify_cert_store(SSL_CTX *ctx, X509_STORE *st);
+ int SSL_set1_verify_cert_store(SSL_CTX *ctx, X509_STORE *st);
+ int SSL_set0_chain_cert_store(SSL_CTX *ctx, X509_STORE *st);
+ int SSL_set1_chain_cert_store(SSL_CTX *ctx, X509_STORE *st);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set0_verify_cert_store() and SSL_CTX_set1_verify_cert_store()
+set the certificate store used for certificate verification to B<st>.
+
+SSL_CTX_set0_chain_cert_store() and SSL_CTX_set1_chain_cert_store()
+set the certificate store used for certificate chain building to B<st>.
+
+SSL_set0_verify_cert_store(), SSL_set1_verify_cert_store(),
+SSL_set0_chain_cert_store() and SSL_set1_chain_cert_store() are similar
+except they apply to SSL structure B<ssl>.
+
+All these functions are implemented as macros. Those containing a B<1>
+increment the reference count of the supplied store so it must
+be freed at some point after the operation. Those containing a B<0> do
+not increment reference counts and the supplied store B<MUST NOT> be freed
+after the operation.
+
+=head1 NOTES
+
+The stores pointers associated with an SSL_CTX structure are copied to any SSL
+structures when SSL_new() is called. As a result SSL structures will not be
+affected if the parent SSL_CTX store pointer is set to a new value.
+
+The verification store is used to verify the certificate chain sent by the
+peer: that is an SSL/TLS client will use the verification store to verify
+the server's certificate chain and a SSL/TLS server will use it to verify
+any client certificate chain.
+
+The chain store is used to build the certificate chain.
+
+If the mode B<SSL_MODE_NO_AUTO_CHAIN> is set or a certificate chain is
+configured already (for example using the functions such as 
+L<SSL_CTX_add1_chain_cert(3)|SSL_CTX_add1_chain_cert(3)> or
+L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>) then
+automatic chain building is disabled.
+
+If the mode B<SSL_MODE_NO_AUTO_CHAIN> is set then automatic chain building
+is disabled.
+
+If the chain or the verification store is not set then the store associated
+with the parent SSL_CTX is used instead to retain compatibility with previous
+versions of OpenSSL.
+
+=head1 RETURN VALUES
+
+All these functions return 1 for success and 0 for failure.
+
+=head1 SEE ALSO
+
+L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>
+L<SSL_CTX_set0_chain(3)|SSL_CTX_set0_chain(3)>
+L<SSL_CTX_set1_chain(3)|SSL_CTX_set1_chain(3)>
+L<SSL_CTX_add0_chain_cert(3)|SSL_CTX_add0_chain_cert(3)>
+L<SSL_CTX_add1_chain_cert(3)|SSL_CTX_add1_chain_cert(3)>
+L<SSL_set0_chain(3)|SSL_set0_chain(3)>
+L<SSL_set1_chain(3)|SSL_set1_chain(3)>
+L<SSL_add0_chain_cert(3)|SSL_add0_chain_cert(3)>
+L<SSL_add1_chain_cert(3)|SSL_add1_chain_cert(3)>
+L<SSL_CTX_build_cert_chain(3)|SSL_CTX_build_cert_chain(3)>
+L<SSL_build_cert_chain(3)|SSL_build_cert_chain(3)>
+
+=head1 HISTORY
+
+These functions were first added to OpenSSL 1.0.2.
+
+=cut

doc/ssl/SSL_CTX_set_cert_cb.pod

@@ -0,0 +1,68 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_cert_cb, SSL_set_cert_cb - handle certificate callback function
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ void SSL_CTX_set_cert_cb(SSL_CTX *c, int (*cert_cb)(SSL *ssl, void *arg), void *arg);
+ void SSL_set_cert_cb(SSL *s, int (*cert_cb)(SSL *ssl, void *arg), void *arg);
+
+ int (*cert_cb)(SSL *ssl, void *arg);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_cert_cb() and SSL_set_cert_cb() sets the B<cert_cb()> callback,
+B<arg> value is pointer which is passed to the application callback.
+
+When B<cert_cb()> is NULL, no callback function is used.
+
+cert_cb() is the application defined callback. It is called before a
+certificate will be used by a client or server. The callback can then inspect
+the passed B<ssl> structure and set or clear any appropriate certificates. If
+the callback is successful it B<MUST> return 1 even if no certificates have
+been set. A zero is returned on error which will abort the handshake with a
+fatal internal error alert. A negative return value will suspend the handshake
+and the handshake function will return immediately.
+L<SSL_get_error(3)|SSL_get_error(3)> will return SSL_ERROR_WANT_X509_LOOKUP to
+indicate, that the handshake was suspended. The next call to the handshake
+function will again lead to the call of cert_cb(). It is the job of the
+cert_cb() to store information about the state of the last call,
+if required to continue.
+
+=head1 NOTES
+
+An application will typically call SSL_use_certificate() and
+SSL_use_PrivateKey() to set the end entity certificate and private key.
+It can add intermediate and optionally the root CA certificates using
+SSL_add1_chain_cert().
+
+It might also call SSL_certs_clear() to delete any certificates associated
+with the B<SSL> object.
+
+The certificate callback functionality supercedes the (largely broken)
+functionality provided by the old client certificate callback interface.
+It is B<always> called even is a certificate is already set so the callback
+can modify or delete the existing certificate.
+
+A more advanced callback might examine the handshake parameters and set
+whatever chain is appropriate. For example a legacy client supporting only
+TLS v1.0 might receive a certificate chain signed using SHA1 whereas a
+TLS v1.2 client which advertises support for SHA256 could receive a chain
+using SHA256.
+
+Normal server sanity checks are performed on any certificates set
+by the callback. So if an EC chain is set for a curve the client does not
+support it will B<not> be used.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_use_certificate(3)|SSL_use_certificate(3)>,
+L<SSL_add1_chain_cert(3)|SSL_add1_chain_cert(3)>,
+L<SSL_get_client_CA_list(3)|SSL_get_client_CA_list(3)>,
+L<SSL_clear(3)|SSL_clear(3)>, L<SSL_free(3)|SSL_free(3)>
+
+=cut

doc/ssl/SSL_CTX_set_cert_store.pod

@@ -42,6 +42,13 @@ L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)> family of functions.
 This document must therefore be updated when documentation about the
 X509_STORE object and its handling becomes available.
 
+=head1 RESTRICTIONS
+
+The X509_STORE structure used by an SSL_CTX is used for verifying peer
+certificates and building certificate chains, it is also shared by
+every child SSL structure. Applications wanting finer control can use 
+functions such as SSL_CTX_set1_verify_cert_store() instead.
+
 =head1 RETURN VALUES
 
 SSL_CTX_set_cert_store() does not return diagnostic output.

doc/ssl/SSL_CTX_set_cipher_list.pod

@@ -41,7 +41,7 @@ RSA export ciphers with a keylength of 512 bits for the RSA key require
 a temporary 512 bit RSA key, as typically the supplied key has a length
 of 1024 bit (see
 L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>).
-RSA ciphers using EDH need a certificate and key and additional DH-parameters
+RSA ciphers using DHE need a certificate and key and additional DH-parameters
 (see L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>).
 
 A DSA cipher can only be chosen, when a DSA certificate is available.
@@ -54,6 +54,10 @@ of 512 bits and the server is not configured to use temporary RSA
 keys), the "no shared cipher" (SSL_R_NO_SHARED_CIPHER) error is generated
 and the handshake will fail.
 
+If the cipher list does not contain any SSLv2 cipher suites (this is the
+default) then SSLv2 is effectively disabled and neither clients nor servers
+will attempt to use SSLv2.
+
 =head1 RETURN VALUES
 
 SSL_CTX_set_cipher_list() and SSL_set_cipher_list() return 1 if any cipher

doc/ssl/SSL_CTX_set_client_CA_list.pod

@@ -35,7 +35,7 @@ the chosen B<ssl>, overriding the setting valid for B<ssl>'s SSL_CTX object.
 =head1 NOTES
 
 When a TLS/SSL server requests a client certificate (see
-B<SSL_CTX_set_verify_options()>), it sends a list of CAs, for which
+B<SSL_CTX_set_verify(3)>), it sends a list of CAs, for which
 it will accept certificates, to the client.
 
 This list must explicitly be set using SSL_CTX_set_client_CA_list() for
@@ -66,16 +66,16 @@ values:
 
 =over 4
 
-=item 1
-
-The operation succeeded.
-
-=item 0
+=item Z<>0
 
 A failure while manipulating the STACK_OF(X509_NAME) object occurred or
 the X509_NAME could not be extracted from B<cacert>. Check the error stack
 to find out the reason.
 
+=item Z<>1
+
+The operation succeeded.
+
 =back
 
 =head1 EXAMPLES

doc/ssl/SSL_CTX_set_client_cert_cb.pod

@@ -29,7 +29,7 @@ using the B<x509> and B<pkey> arguments and "1" must be returned. The
 certificate will be installed into B<ssl>, see the NOTES and BUGS sections.
 If no certificate should be set, "0" has to be returned and no certificate
 will be sent. A negative return value will suspend the handshake and the
-handshake function will return immediatly. L<SSL_get_error(3)|SSL_get_error(3)>
+handshake function will return immediately. L<SSL_get_error(3)|SSL_get_error(3)>
 will return SSL_ERROR_WANT_X509_LOOKUP to indicate, that the handshake was
 suspended. The next call to the handshake function will again lead to the call
 of client_cert_cb(). It is the job of the client_cert_cb() to store information

doc/ssl/SSL_CTX_set_custom_cli_ext.pod

@@ -0,0 +1,133 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_add_client_custom_ext, SSL_CTX_add_server_custom_ext - custom TLS extension handling
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ int SSL_CTX_add_client_custom_ext(SSL_CTX *ctx, unsigned int ext_type,
+			           custom_ext_add_cb add_cb,
+			           custom_ext_free_cb free_cb, void *add_arg,
+			           custom_ext_parse_cb parse_cb,
+				   void *parse_arg);
+
+ int SSL_CTX_add_server_custom_ext(SSL_CTX *ctx, unsigned int ext_type,
+			           custom_ext_add_cb add_cb,
+			           custom_ext_free_cb free_cb, void *add_arg,
+			           custom_ext_parse_cb parse_cb,
+				   void *parse_arg);
+
+ int SSL_extension_supported(unsigned int ext_type);
+
+ typedef int (*custom_ext_add_cb)(SSL *s, unsigned int ext_type,
+				  const unsigned char **out,
+				  size_t *outlen, int *al,
+				  void *add_arg);
+
+ typedef void (*custom_ext_free_cb)(SSL *s, unsigned int ext_type,
+				    const unsigned char *out,
+				    void *add_arg);
+
+ typedef int (*custom_ext_parse_cb)(SSL *s, unsigned int ext_type,
+				    const unsigned char *in,
+				    size_t inlen, int *al,
+				    void *parse_arg);
+
+
+=head1 DESCRIPTION
+
+SSL_CTX_add_client_custom_ext() adds a custom extension for a TLS client 
+with extension type B<ext_type> and callbacks B<add_cb>, B<free_cb> and
+B<parse_cb>.
+
+SSL_CTX_add_server_custom_ext() adds a custom extension for a TLS server 
+with extension type B<ext_type> and callbacks B<add_cb>, B<free_cb> and
+B<parse_cb>.
+
+In both cases the extension type must not be handled by OpenSSL internally
+or an error occurs.
+
+SSL_extension_supported() returns 1 if the extension B<ext_type> is handled
+internally by OpenSSL and 0 otherwise.
+
+=head1 EXTENSION CALLBACKS
+
+The callback B<add_cb> is called to send custom extension data to be 
+included in ClientHello for TLS clients or ServerHello for servers. The
+B<ext_type> parameter is set to the extension type which will be added and
+B<add_arg> to the value set when the extension handler was added.
+
+If the application wishes to include the extension B<ext_type> it should
+set B<*out> to the extension data, set B<*outlen> to the length of the
+extension data and return 1.
+
+If the B<add_cb> does not wish to include the extension it must return 0.
+
+If B<add_cb> returns -1 a fatal handshake error occurs using the TLS
+alert value specified in B<*al>.
+
+For clients (but not servers) if B<add_cb> is set to NULL a zero length
+extension is added for B<ext_type>.
+
+For clients every registered B<add_cb> is always called to see if the
+application wishes to add an extension to ClientHello.
+
+For servers every registered B<add_cb> is called once if and only if the
+corresponding extension was received in ClientHello to see if the application
+wishes to add the extension to ServerHello. That is, if no corresponding extension
+was received in ClientHello then B<add_cb> will not be called.
+
+If an extension is added (that is B<add_cb> returns 1) B<free_cb> is called
+(if it is set) with the value of B<out> set by the add callback. It can be
+used to free up any dynamic extension data set by B<add_cb>. Since B<out> is
+constant (to permit use of constant data in B<add_cb>) applications may need to
+cast away const to free the data.
+
+The callback B<parse_cb> receives data for TLS extensions. For TLS clients
+the extension data will come from ServerHello and for TLS servers it will
+come from ClientHello.
+
+The extension data consists of B<inlen> bytes in the buffer B<in> for the
+extension B<extension_type>.
+
+If the B<parse_cb> considers the extension data acceptable it must return
+1. If it returns 0 or a negative value a fatal handshake error occurs
+using the TLS alert value specified in B<*al>.
+
+The buffer B<in> is a temporary internal buffer which will not be valid after
+the callback returns.
+
+=head1 NOTES
+
+The B<add_arg> and B<parse_arg> parameters can be set to arbitrary values
+which will be passed to the corresponding callbacks. They can, for example,
+be used to store the extension data received in a convenient structure or
+pass the extension data to be added or freed when adding extensions.
+
+The B<ext_type> parameter corresponds to the B<extension_type> field of
+RFC5246 et al. It is B<not> a NID.
+
+If the same custom extension type is received multiple times a fatal
+B<decode_error> alert is sent and the handshake aborts. If a custom extension
+is received in ServerHello which was not sent in ClientHello a fatal
+B<unsupported_extension> alert is sent and the handshake is aborted. The
+ServerHello B<add_cb> callback is only called if the corresponding extension
+was received in ClientHello. This is compliant with the TLS specifications.
+This behaviour ensures that each callback is called at most once and that
+an application can never send unsolicited extensions.
+
+=head1 RETURN VALUES
+
+SSL_CTX_add_client_custom_ext() and SSL_CTX_add_server_custom_ext() return 1 for
+success and 0 for failure. A failure can occur if an attempt is made to
+add the same B<ext_type> more than once, if an attempt is made to use an
+extension type handled internally by OpenSSL or if an internal error occurs
+(for example a memory allocation failure).
+
+SSL_extension_supported() returns 1 if the extension B<ext_type> is handled
+internally by OpenSSL and 0 otherwise.
+
+=cut

doc/ssl/SSL_CTX_set_mode.pod

@@ -71,6 +71,16 @@ SSL_CTX->freelist_max_len, which defaults to 32.  Using this flag can
 save around 34k per idle SSL connection.
 This flag has no effect on SSL v2 connections, or on DTLS connections.
 
+=item SSL_MODE_SEND_FALLBACK_SCSV
+
+Send TLS_FALLBACK_SCSV in the ClientHello.
+To be set only by applications that reconnect with a downgraded protocol
+version; see draft-ietf-tls-downgrade-scsv-00 for details.
+
+DO NOT ENABLE THIS if your application attempts a normal handshake.
+Only use this in explicit fallback retries, following the guidance
+in draft-ietf-tls-downgrade-scsv-00.
+
 =back
 
 =head1 RETURN VALUES

doc/ssl/SSL_CTX_set_msg_callback.pod

@@ -11,8 +11,8 @@ SSL_CTX_set_msg_callback, SSL_CTX_set_msg_callback_arg, SSL_set_msg_callback, SS
  void SSL_CTX_set_msg_callback(SSL_CTX *ctx, void (*cb)(int write_p, int version, int content_type, const void *buf, size_t len, SSL *ssl, void *arg));
  void SSL_CTX_set_msg_callback_arg(SSL_CTX *ctx, void *arg);
 
- void SSL_set_msg_callback(SSL_CTX *ctx, void (*cb)(int write_p, int version, int content_type, const void *buf, size_t len, SSL *ssl, void *arg));
- void SSL_set_msg_callback_arg(SSL_CTX *ctx, void *arg);
+ void SSL_set_msg_callback(SSL *ssl, void (*cb)(int write_p, int version, int content_type, const void *buf, size_t len, SSL *ssl, void *arg));
+ void SSL_set_msg_callback_arg(SSL *ssl, void *arg);
 
 =head1 DESCRIPTION
 

doc/ssl/SSL_CTX_set_options.pod

@@ -88,9 +88,10 @@ As of OpenSSL 0.9.8q and 1.0.0c, this option has no effect.
 
 ...
 
-=item SSL_OP_MSIE_SSLV2_RSA_PADDING
+=item SSL_OP_SAFARI_ECDHE_ECDSA_BUG
 
-As of OpenSSL 0.9.7h and 0.9.8a, this option has no effect.
+Don't prefer ECDHE-ECDSA ciphers when the client appears to be Safari on OS X.
+OS X 10.8..10.8.3 has broken support for ECDHE-ECDSA ciphers.
 
 =item SSL_OP_SSLEAY_080_CLIENT_DH_BUG
 
@@ -111,6 +112,12 @@ vulnerability affecting CBC ciphers, which cannot be handled by some
 broken SSL implementations.  This option has no effect for connections
 using other ciphers.
 
+=item SSL_OP_TLSEXT_PADDING
+
+Adds a padding extension to ensure the ClientHello size is never between
+256 and 511 bytes in length. This is needed as a workaround for some
+implementations.
+
 =item SSL_OP_ALL
 
 All of the above bug workarounds.
@@ -151,15 +158,7 @@ temporary/ephemeral DH parameters are used.
 
 =item SSL_OP_EPHEMERAL_RSA
 
-Always use ephemeral (temporary) RSA key when doing RSA operations
-(see L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>).
-According to the specifications this is only done, when a RSA key
-can only be used for signature operations (namely under export ciphers
-with restricted RSA keylength). By setting this option, ephemeral
-RSA keys are always used. This option breaks compatibility with the
-SSL/TLS specifications and may lead to interoperability problems with
-clients and should therefore never be used. Ciphers with EDH (ephemeral
-Diffie-Hellman) key exchange should be used instead.
+This option is no longer implemented and is treated as no op.
 
 =item SSL_OP_CIPHER_SERVER_PREFERENCE
 
@@ -249,7 +248,7 @@ Connections and renegotiation are always permitted by OpenSSL implementations.
 
 =head2 Unpatched client and patched OpenSSL server
 
-The initial connection suceeds but client renegotiation is denied by the
+The initial connection succeeds but client renegotiation is denied by the
 server with a B<no_renegotiation> warning alert if TLS v1.0 is used or a fatal
 B<handshake_failure> alert in SSL v3.0.
 

doc/ssl/SSL_CTX_set_read_ahead.pod

@@ -0,0 +1,51 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_read_ahead, SSL_CTX_set_default_read_ahead, SSL_CTX_get_read_ahead,
+SSL_CTX_get_default_read_ahead, SSL_set_read_ahead, SSL_get_read_ahead
+- manage whether to read as many input bytes as possible
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ int SSL_get_read_ahead(const SSL *s);
+ void SSL_set_read_ahead(SSL *s, int yes);
+
+ #define SSL_CTX_get_default_read_ahead(ctx)
+ #define SSL_CTX_set_default_read_ahead(ctx,m)
+ #define SSL_CTX_get_read_ahead(ctx)
+ #define SSL_CTX_set_read_ahead(ctx,m)
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_read_ahead() and SSL_set_read_ahead() set whether we should read as
+many input bytes as possible (for non-blocking reads) or not. For example if
+B<x> bytes are currently required by OpenSSL, but B<y> bytes are available from
+the underlying BIO (where B<y> > B<x>), then OpenSSL will read all B<y> bytes
+into its buffer (providing that the buffer is large enough) if reading ahead is
+on, or B<x> bytes otherwise. The parameter B<yes> or B<m> should be 0 to ensure
+reading ahead is off, or non zero otherwise.
+
+SSL_CTX_set_default_read_ahead is a synonym for SSL_CTX_set_read_ahead, and
+SSL_CTX_get_default_read_ahead is a synonym for SSL_CTX_get_read_ahead.
+
+SSL_CTX_get_read_ahead() and SSL_get_read_ahead() indicate whether reading
+ahead has been set or not.
+
+=head1 NOTES
+
+These functions have no impact when used with DTLS. The return values for
+SSL_CTX_get_read_head() and SSL_get_read_ahead() are undefined for DTLS.
+
+=head1 RETURN VALUES
+
+SSL_get_read_ahead and SSL_CTX_get_read_ahead return 0 if reading ahead is off,
+and non zero otherwise.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>
+
+=cut

doc/ssl/SSL_CTX_set_session_id_context.pod

@@ -64,13 +64,13 @@ return the following values:
 
 =over 4
 
-=item 0
+=item Z<>0
 
 The length B<sid_ctx_len> of the session id context B<sid_ctx> exceeded
 the maximum allowed length of B<SSL_MAX_SSL_SESSION_ID_LENGTH>. The error
 is logged to the error stack.
 
-=item 1
+=item Z<>1
 
 The operation succeeded.
 

doc/ssl/SSL_CTX_set_ssl_version.pod

@@ -42,11 +42,11 @@ and SSL_set_ssl_method():
 
 =over 4
 
-=item 0
+=item Z<>0
 
 The new choice failed, check the error stack to find out the reason.
 
-=item 1
+=item Z<>1
 
 The operation succeeded.
 

doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod

@@ -0,0 +1,195 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_tlsext_ticket_key_cb - set a callback for session ticket processing
+
+=head1 SYNOPSIS
+
+ #include <openssl/tls1.h>
+
+ long SSL_CTX_set_tlsext_ticket_key_cb(SSL_CTX sslctx,
+        int (*cb)(SSL *s, unsigned char key_name[16],
+	          unsigned char iv[EVP_MAX_IV_LENGTH],
+		  EVP_CIPHER_CTX *ctx, HMAC_CTX *hctx, int enc));
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_tlsext_ticket_key_cb() sets a callback fuction I<cb> for handling 
+session tickets for the ssl context I<sslctx>. Session tickets, defined in 
+RFC5077 provide an enhanced session resumption capability where the server
+implementation is not required to maintain per session state. It only applies
+to TLS and there is no SSLv3 implementation.
+
+The callback is available when the OpenSSL library was built without 
+I<OPENSSL_NO_TLSEXT> being defined.
+
+The callback function I<cb> will be called for every client instigated TLS
+session when session ticket extension is presented in the TLS hello
+message. It is the responsibility of this function to create or retrieve the
+cryptographic parameters and to maintain their state.
+
+The OpenSSL library uses your callback function to help implement a common TLS 
+ticket construction state according to RFC5077 Section 4 such that per session
+state is unnecessary and a small set of cryptographic variables needs to be 
+maintained by the callback function implementation.
+
+In order to reuse a session, a TLS client must send the a session ticket
+extension to the server. The client can only send exactly one session ticket.
+The server, through the callback function, either agrees to reuse the session
+ticket information or it starts a full TLS handshake to create a new session
+ticket.
+
+Before the callback function is started I<ctx> and I<hctx> have been 
+initialised with EVP_CIPHER_CTX_init and HMAC_CTX_init respectively.
+
+For new sessions tickets, when the client doesn't present a session ticket, or
+an attempted retreival of the ticket failed, or a renew option was indicated,
+the callback function will be called with I<enc> equal to 1. The OpenSSL
+library expects that the function will set an arbitary I<name>, initialize
+I<iv>, and set the cipher context I<ctx> and the hash context I<hctx>.
+
+The I<name> is 16 characters long and is used as a key identifier.
+
+The I<iv> length is the length of the IV of the corresponding cipher. The
+maximum IV length is L<EVP_MAX_IV_LENGTH> bytes defined in B<evp.h>.
+
+The initialization vector I<iv> should be a random value. The cipher context 
+I<ctx> should use the initialisation vector I<iv>. The cipher context can be 
+set using L<EVP_EncryptInit_ex>. The hmac context can be set using L<HMAC_Init_ex>.
+
+When the client presents a session ticket, the callback function with be called 
+with I<enc> set to 0 indicating that the I<cb> function should retreive a set
+of parameters. In this case I<name> and I<iv> have already been parsed out of
+the session ticket. The OpenSSL library expects that the I<name> will be used
+to retrieve a cryptographic parameters and that the cryptographic context
+I<ctx> will be set with the retreived parameters and the initialization vector
+I<iv>. using a function like L<EVP_DecryptInit_ex>. The I<hctx> needs to be set
+using L<HMAC_Init_ex>.
+
+If the I<name> is still valid but a renewal of the ticket is required the
+callback function should return 2. The library will call the callback again
+with an arguement of enc equal to 1 to set the new ticket.
+
+The return value of the I<cb> function is used by OpenSSL to determine what
+further processing will occur. The following return values have meaning:
+
+=over 4
+
+=item Z<>2
+
+This indicates that the I<ctx> and I<hctx> have been set and the session can 
+continue on those parameters. Additionally it indicates that the session
+ticket is in a renewal period and should be replaced. The OpenSSL library will
+call I<cb> again with an enc argument of 1 to set the new ticket (see RFC5077
+3.3 paragraph 2).
+
+=item Z<>1
+
+This indicates that the I<ctx> and I<hctx> have been set and the session can 
+continue on those parameters.
+
+=item Z<>0
+
+This indicates that it was not possible to set/retrieve a session ticket and 
+the SSL/TLS session will continue by by negiotationing a set of cryptographic
+parameters or using the alternate SSL/TLS resumption mechanism, session ids.
+
+If called with enc equal to 0 the library will call the I<cb> again to get
+a new set of parameters.
+
+=item less than 0
+
+This indicates an error.
+
+=back
+
+=head1 NOTES
+
+Session resumption shortcuts the TLS so that the client certificate
+negiotation don't occur. It makes up for this by storing client certificate
+an all other negotiated state information encrypted within the ticket. In a
+resumed session the applications will have all this state information available
+exactly as if a full negiotation had occured.
+
+If an attacker can obtain the key used to encrypt a session ticket, they can
+obtain the master secret for any ticket using that key and decrypt any traffic
+using that session: even if the ciphersuite supports forward secrecy. As
+a result applications may wish to use multiple keys and avoid using long term
+keys stored in files.
+
+Applications can use longer keys to maintain a consistent level of security.
+For example if a ciphersuite uses 256 bit ciphers but only a 128 bit ticket key
+the overall security is only 128 bits because breaking the ticket key will
+enable an attacker to obtain the session keys.
+
+=head1 EXAMPLES
+
+Reference Implemention:
+  SSL_CTX_set_tlsext_ticket_key_cb(SSL,ssl_tlsext_ticket_key_cb);
+  ....
+
+  static int ssl_tlsext_ticket_key_cb(SSL *s, unsigned char key_name[16], unsigned char *iv, EVP_CIPHER_CTX *ctx, HMAC_CTX *hctx, int enc)
+  {
+      if (enc) { /* create new session */
+          if (RAND_bytes(iv, EVP_MAX_IV_LENGTH) ) {
+              return -1; /* insufficient random */
+          }
+  
+          key = currentkey(); /* something that you need to implement */
+          if ( !key ) {
+              /* current key doesn't exist or isn't valid */
+              key = createkey(); /* something that you need to implement.
+                                   * createkey needs to initialise, a name,
+                                   * an aes_key, a hmac_key and optionally
+                                   * an expire time. */
+              if ( !key ) { /* key couldn't be created */
+                  return 0;
+              }
+          }
+          memcpy(key_name, key->name, 16);
+  
+          EVP_EncryptInit_ex(&ctx, EVP_aes_128_cbc(), NULL, key->aes_key, iv);
+          HMAC_Init_ex(&hctx, key->hmac_key, 16, EVP_sha256(), NULL);
+  
+          return 1;
+  
+      } else { /* retrieve session */
+          key = findkey(name);
+  
+          if  (!key || key->expire < now() ) {
+              return 0;
+          }
+  
+          HMAC_Init_ex(&hctx, key->hmac_key, 16, EVP_sha256(), NULL);
+          EVP_DecryptInit_ex(&ctx, EVP_aes_128_cbc(), NULL, key->aes_key, iv );
+
+          if (key->expire < ( now() - RENEW_TIME ) ) {
+              /* return 2 - this session will get a new ticket even though the current is still valid */
+              return 2;
+          }
+          return 1;
+  
+      }
+  }
+
+
+
+=head1 RETURN VALUES
+
+returns 0 to indicate the callback function was set.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_set_session(3)|SSL_set_session(3)>,
+L<SSL_session_reused(3)|SSL_session_reused(3)>,
+L<SSL_CTX_add_session(3)|SSL_CTX_add_session(3)>,
+L<SSL_CTX_sess_number(3)|SSL_CTX_sess_number(3)>,
+L<SSL_CTX_sess_set_get_cb(3)|SSL_CTX_sess_set_get_cb(3)>,
+L<SSL_CTX_set_session_id_context(3)|SSL_CTX_set_session_id_context(3)>,
+
+=head1 HISTORY
+
+This function was introduced in OpenSSL 0.9.8h
+
+=cut

doc/ssl/SSL_CTX_set_tmp_dh_callback.pod

@@ -12,12 +12,10 @@ SSL_CTX_set_tmp_dh_callback, SSL_CTX_set_tmp_dh, SSL_set_tmp_dh_callback, SSL_se
             DH *(*tmp_dh_callback)(SSL *ssl, int is_export, int keylength));
  long SSL_CTX_set_tmp_dh(SSL_CTX *ctx, DH *dh);
 
- void SSL_set_tmp_dh_callback(SSL_CTX *ctx,
+ void SSL_set_tmp_dh_callback(SSL *ctx,
             DH *(*tmp_dh_callback)(SSL *ssl, int is_export, int keylength));
  long SSL_set_tmp_dh(SSL *ssl, DH *dh)
 
- DH *(*tmp_dh_callback)(SSL *ssl, int is_export, int keylength));
-
 =head1 DESCRIPTION
 
 SSL_CTX_set_tmp_dh_callback() sets the callback function for B<ctx> to be
@@ -50,24 +48,25 @@ even if he gets hold of the normal (certified) key, as this key was
 only used for signing.
 
 In order to perform a DH key exchange the server must use a DH group
-(DH parameters) and generate a DH key. The server will always generate a new
-DH key during the negotiation, when the DH parameters are supplied via
-callback and/or when the SSL_OP_SINGLE_DH_USE option of
-L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)> is set. It will
-immediately create a DH key, when DH parameters are supplied via
-SSL_CTX_set_tmp_dh() and SSL_OP_SINGLE_DH_USE is not set. In this case,
+(DH parameters) and generate a DH key.
+The server will always generate a new DH key during the negotiation
+if either the DH parameters are supplied via callback or the
+SSL_OP_SINGLE_DH_USE option of SSL_CTX_set_options(3) is set (or both).
+It will  immediately create a DH key if DH parameters are supplied via
+SSL_CTX_set_tmp_dh() and SSL_OP_SINGLE_DH_USE is not set.
+In this case,
 it may happen that a key is generated on initialization without later
 being needed, while on the other hand the computer time during the
 negotiation is being saved.
 
 If "strong" primes were used to generate the DH parameters, it is not strictly
 necessary to generate a new key for each handshake but it does improve forward
-secrecy. If it is not assured, that "strong" primes were used (see especially
-the section about DSA parameters below), SSL_OP_SINGLE_DH_USE must be used
-in order to prevent small subgroup attacks. Always using SSL_OP_SINGLE_DH_USE
-has an impact on the computer time needed during negotiation, but it is not
-very large, so application authors/users should consider to always enable
-this option.
+secrecy. If it is not assured that "strong" primes were used,
+SSL_OP_SINGLE_DH_USE must be used in order to prevent small subgroup
+attacks. Always using SSL_OP_SINGLE_DH_USE has an impact on the
+computer time needed during negotiation, but it is not very large, so
+application authors/users should consider always enabling this option.
+The option is required to implement perfect forward secrecy (PFS).
 
 As generating DH parameters is extremely time consuming, an application
 should not generate the parameters on the fly but supply the parameters.
@@ -75,83 +74,63 @@ DH parameters can be reused, as the actual key is newly generated during
 the negotiation. The risk in reusing DH parameters is that an attacker
 may specialize on a very often used DH group. Applications should therefore
 generate their own DH parameters during the installation process using the
-openssl L<dhparam(1)|dhparam(1)> application. In order to reduce the computer
-time needed for this generation, it is possible to use DSA parameters
-instead (see L<dhparam(1)|dhparam(1)>), but in this case SSL_OP_SINGLE_DH_USE
-is mandatory.
+openssl L<dhparam(1)|dhparam(1)> application. This application
+guarantees that "strong" primes are used.
 
-Application authors may compile in DH parameters. Files dh512.pem,
-dh1024.pem, dh2048.pem, and dh4096 in the 'apps' directory of current
+Files dh2048.pem, and dh4096.pem in the 'apps' directory of the current
 version of the OpenSSL distribution contain the 'SKIP' DH parameters,
 which use safe primes and were generated verifiably pseudo-randomly.
 These files can be converted into C code using the B<-C> option of the
-L<dhparam(1)|dhparam(1)> application.
-Authors may also generate their own set of parameters using
-L<dhparam(1)|dhparam(1)>, but a user may not be sure how the parameters were
-generated. The generation of DH parameters during installation is therefore
-recommended.
+L<dhparam(1)|dhparam(1)> application. Generation of custom DH
+parameters during installation should still be preferred to stop an
+attacker from specializing on a commonly used group. Files dh1024.pem
+and dh512.pem contain old parameters that must not be used by
+applications.
 
 An application may either directly specify the DH parameters or
-can supply the DH parameters via a callback function. The callback approach
-has the advantage, that the callback may supply DH parameters for different
-key lengths.
+can supply the DH parameters via a callback function.
 
-The B<tmp_dh_callback> is called with the B<keylength> needed and
-the B<is_export> information. The B<is_export> flag is set, when the
-ephemeral DH key exchange is performed with an export cipher.
+Previous versions of the callback used B<is_export> and B<keylength>
+parameters to control parameter generation for export and non-export
+cipher suites. Modern servers that do not support export ciphersuites
+are advised to either use SSL_CTX_set_tmp_dh() in combination with
+SSL_OP_SINGLE_DH_USE, or alternatively, use the callback but ignore
+B<keylength> and B<is_export> and simply supply at least 2048-bit
+parameters in the callback.
 
 =head1 EXAMPLES
 
-Handle DH parameters for key lengths of 512 and 1024 bits. (Error handling
+Setup DH parameters with a key length of 2048 bits. (Error handling
 partly left out.)
 
+ Command-line parameter generation:
+ $ openssl dhparam -out dh_param_2048.pem 2048
+
+ Code for setting up parameters during server initialization:
+
  ...
- /* Set up ephemeral DH stuff */
- DH *dh_512 = NULL;
- DH *dh_1024 = NULL;
+ SSL_CTX ctx = SSL_CTX_new();
+ ...
+
+ /* Set up ephemeral DH parameters. */
+ DH *dh_2048 = NULL;
  FILE *paramfile;
-
- ...
- /* "openssl dhparam -out dh_param_512.pem -2 512" */
- paramfile = fopen("dh_param_512.pem", "r");
+ paramfile = fopen("dh_param_2048.pem", "r");
  if (paramfile) {
-   dh_512 = PEM_read_DHparams(paramfile, NULL, NULL, NULL);
+   dh_2048 = PEM_read_DHparams(paramfile, NULL, NULL, NULL);
    fclose(paramfile);
+ } else {
+   /* Error. */
  }
- /* "openssl dhparam -out dh_param_1024.pem -2 1024" */
- paramfile = fopen("dh_param_1024.pem", "r");
- if (paramfile) {
-   dh_1024 = PEM_read_DHparams(paramfile, NULL, NULL, NULL);
-   fclose(paramfile);
+ if (dh_2048 == NULL) {
+  /* Error. */
  }
+ if (SSL_CTX_set_tmp_dh(ctx, dh_2048) != 1) {
+   /* Error. */
+ }
+ SSL_CTX_set_options(ctx, SSL_OP_SINGLE_DH_USE);
  ...
 
- /* "openssl dhparam -C -2 512" etc... */
- DH *get_dh512() { ... }
- DH *get_dh1024() { ... }
-
- DH *tmp_dh_callback(SSL *s, int is_export, int keylength)
- {
-    DH *dh_tmp=NULL;
-
-    switch (keylength) {
-    case 512:
-      if (!dh_512)
-        dh_512 = get_dh512();
-      dh_tmp = dh_512;
-      break;
-    case 1024:
-      if (!dh_1024) 
-        dh_1024 = get_dh1024();
-      dh_tmp = dh_1024;
-      break;
-    default:
-      /* Generating a key on the fly is very costly, so use what is there */
-      setup_dh_parameters_like_above();
-    }
-    return(dh_tmp);
- }
-
 =head1 RETURN VALUES
 
 SSL_CTX_set_tmp_dh_callback() and SSL_set_tmp_dh_callback() do not return

doc/ssl/SSL_CTX_set_tmp_rsa_callback.pod

@@ -70,25 +70,18 @@ the TLS standard, when the RSA key can be used for signing only, that is
 for export ciphers. Using ephemeral RSA key exchange for other purposes
 violates the standard and can break interoperability with clients.
 It is therefore strongly recommended to not use ephemeral RSA key
-exchange and use EDH (Ephemeral Diffie-Hellman) key exchange instead
+exchange and use DHE (Ephemeral Diffie-Hellman) key exchange instead
 in order to achieve forward secrecy (see
 L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>).
 
-On OpenSSL servers ephemeral RSA key exchange is therefore disabled by default
-and must be explicitly enabled  using the SSL_OP_EPHEMERAL_RSA option of
-L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>, violating the TLS/SSL
-standard. When ephemeral RSA key exchange is required for export ciphers,
-it will automatically be used without this option!
-
-An application may either directly specify the key or can supply the key via
-a callback function. The callback approach has the advantage, that the
-callback may generate the key only in case it is actually needed. As the
-generation of a RSA key is however costly, it will lead to a significant
-delay in the handshake procedure.  Another advantage of the callback function
-is that it can supply keys of different size (e.g. for SSL_OP_EPHEMERAL_RSA
-usage) while the explicit setting of the key is only useful for key size of
-512 bits to satisfy the export restricted ciphers and does give away key length
-if a longer key would be allowed.
+An application may either directly specify the key or can supply the key via a
+callback function. The callback approach has the advantage, that the callback
+may generate the key only in case it is actually needed. As the generation of a
+RSA key is however costly, it will lead to a significant delay in the handshake
+procedure.  Another advantage of the callback function is that it can supply
+keys of different size while the explicit setting of the key is only useful for
+key size of 512 bits to satisfy the export restricted ciphers and does give
+away key length if a longer key would be allowed.
 
 The B<tmp_rsa_callback> is called with the B<keylength> needed and
 the B<is_export> information. The B<is_export> flag is set, when the

doc/ssl/SSL_CTX_set_verify.pod

@@ -109,8 +109,8 @@ certificates would not be present, most likely a
 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY will be issued.
 The depth count is "level 0:peer certificate", "level 1: CA certificate",
 "level 2: higher level CA certificate", and so on. Setting the maximum
-depth to 2 allows the levels 0, 1, and 2. The default depth limit is 9,
-allowing for the peer certificate and additional 9 CA certificates.
+depth to 2 allows the levels 0, 1, and 2. The default depth limit is 100,
+allowing for the peer certificate and additional 100 CA certificates.
 
 The B<verify_callback> function is used to control the behaviour when the
 SSL_VERIFY_PEER flag is set. It must be supplied by the application and
@@ -169,8 +169,8 @@ that will always continue the TLS/SSL handshake regardless of verification
 failure, if wished. The callback realizes a verification depth limit with
 more informational output.
 
-All verification errors are printed, informations about the certificate chain
-are printed on request.
+All verification errors are printed; information about the certificate chain
+is printed on request.
 The example is realized for a server that does allow but not require client
 certificates.
 

doc/ssl/SSL_CTX_use_certificate.pod

@@ -109,10 +109,9 @@ this B<ssl>, the last item added into B<ctx> will be checked.
 
 =head1 NOTES
   
-The internal certificate store of OpenSSL can hold two private key/certificate
-pairs at a time: one key/certificate of type RSA and one key/certificate
-of type DSA. The certificate used depends on the cipher select, see
-also L<SSL_CTX_set_cipher_list(3)|SSL_CTX_set_cipher_list(3)>.
+The internal certificate store of OpenSSL can hold several private
+key/certificate pairs at a time. The certificate used depends on the
+cipher selected, see also L<SSL_CTX_set_cipher_list(3)|SSL_CTX_set_cipher_list(3)>.
 
 When reading certificates and private keys from file, files of type
 SSL_FILETYPE_ASN1 (also known as B<DER>, binary encoding) can only contain
@@ -122,16 +121,13 @@ Files of type SSL_FILETYPE_PEM can contain more than one item.
 
 SSL_CTX_use_certificate_chain_file() adds the first certificate found
 in the file to the certificate store. The other certificates are added
-to the store of chain certificates using
-L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>.
-There exists only one extra chain store, so that the same chain is appended
-to both types of certificates, RSA and DSA! If it is not intended to use
-both type of certificate at the same time, it is recommended to use the
-SSL_CTX_use_certificate_chain_file() instead of the
-SSL_CTX_use_certificate_file() function in order to allow the use of
-complete certificate chains even when no trusted CA storage is used or
-when the CA issuing the certificate shall not be added to the trusted
-CA storage.
+to the store of chain certificates using L<SSL_CTX_add1_chain_cert(3)|SSL_CTX_add1_chain_cert(3)>. Note: versions of OpenSSL before 1.0.2 only had a single
+certificate chain store for all certificate types, OpenSSL 1.0.2 and later
+have a separate chain store for each type. SSL_CTX_use_certificate_chain_file() 
+should be used instead of the SSL_CTX_use_certificate_file() function in order
+to allow the use of complete certificate chains even when no trusted CA
+storage is used or when the CA issuing the certificate shall not be added to
+the trusted CA storage.
 
 If additional certificates are needed to complete the chain during the
 TLS negotiation, CA certificates are additionally looked up in the

doc/ssl/SSL_CTX_use_psk_identity_hint.pod

@@ -81,7 +81,14 @@ SSL_CTX_use_psk_identity_hint() and SSL_use_psk_identity_hint() return
 
 Return values from the server callback are interpreted as follows:
 
-=item > 0
+=over 4
+
+=item Z<>0
+
+PSK identity was not found. An "unknown_psk_identity" alert message
+will be sent and the connection setup fails.
+
+=item E<gt>0
 
 PSK identity was found and the server callback has provided the PSK
 successfully in parameter B<psk>. Return value is the length of
@@ -94,9 +101,6 @@ data to B<psk> and return the length of the random data, so the
 connection will fail with decryption_error before it will be finished
 completely.
 
-=item 0
-
-PSK identity was not found. An "unknown_psk_identity" alert message
-will be sent and the connection setup fails.
+=back
 
 =cut

doc/ssl/SSL_CTX_use_serverinfo.pod

@@ -0,0 +1,46 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_use_serverinfo, SSL_CTX_use_serverinfo_file - use serverinfo extension
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ int SSL_CTX_use_serverinfo(SSL_CTX *ctx, const unsigned char *serverinfo,
+                            size_t serverinfo_length);
+
+ int SSL_CTX_use_serverinfo_file(SSL_CTX *ctx, const char *file);
+
+=head1 DESCRIPTION
+
+These functions load "serverinfo" TLS ServerHello Extensions into the SSL_CTX.
+A "serverinfo" extension is returned in response to an empty ClientHello
+Extension.
+
+SSL_CTX_use_serverinfo() loads one or more serverinfo extensions from
+a byte array into B<ctx>.  The extensions must be concatenated into a 
+sequence of bytes.  Each extension must consist of a 2-byte Extension Type, 
+a 2-byte length, and then length bytes of extension_data.
+
+SSL_CTX_use_serverinfo_file() loads one or more serverinfo extensions from
+B<file> into B<ctx>.  The extensions must be in PEM format.  Each extension
+must consist of a 2-byte Extension Type, a 2-byte length, and then length
+bytes of extension_data.  Each PEM extension name must begin with the phrase
+"BEGIN SERVERINFO FOR ".
+
+=head1 NOTES
+
+=head1 RETURN VALUES
+
+On success, the functions return 1.
+On failure, the functions return 0.  Check out the error stack to find out
+the reason.
+
+=head1 SEE ALSO
+
+=head1 HISTORY
+
+
+=cut

doc/ssl/SSL_accept.pod

@@ -21,10 +21,7 @@ B<ssl> by setting an underlying B<BIO>.
 The behaviour of SSL_accept() depends on the underlying BIO. 
 
 If the underlying BIO is B<blocking>, SSL_accept() will only return once the
-handshake has been finished or an error occurred, except for SGC (Server
-Gated Cryptography). For SGC, SSL_accept() may return with -1, but
-SSL_get_error() will yield B<SSL_ERROR_WANT_READ/WRITE> and SSL_accept()
-should be called again.
+handshake has been finished or an error occurred.
 
 If the underlying BIO is B<non-blocking>, SSL_accept() will also return
 when the underlying BIO could not satisfy the needs of SSL_accept()
@@ -44,17 +41,17 @@ The following return values can occur:
 
 =over 4
 
-=item 1
-
-The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
-established.
-
-=item 0
+=item Z<>0
 
 The TLS/SSL handshake was not successful but was shut down controlled and
 by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
 return value B<ret> to find out the reason.
 
+=item Z<>1
+
+The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
+established.
+
 =item E<lt>0
 
 The TLS/SSL handshake was not successful because a fatal error occurred either

doc/ssl/SSL_alert_type_string.pod

@@ -214,6 +214,11 @@ satisfy a request; the process might receive security parameters
 difficult to communicate changes to these parameters after that
 point. This message is always a warning.
 
+=item "UP"/"unknown PSK identity"
+
+Sent by the server to indicate that it does not recognize a PSK
+identity or an SRP identity. 
+
 =item "UK"/"unknown"
 
 This indicates that no description is available for this alert type.

doc/ssl/SSL_clear.pod

@@ -39,10 +39,16 @@ for a description of the method's properties.
 SSL_clear() resets the SSL object to allow for another connection. The
 reset operation however keeps several settings of the last sessions
 (some of these settings were made automatically during the last
-handshake). It only makes sense when opening a new session (or reusing
-an old one) with the same peer that shares these settings.
-SSL_clear() is not a short form for the sequence
-L<SSL_free(3)|SSL_free(3)>; L<SSL_new(3)|SSL_new(3)>; .
+handshake). It only makes sense for a new connection with the exact
+same peer that shares these settings, and may fail if that peer
+changes its settings between connections. Use the sequence
+L<SSL_get_session(3)|SSL_get_session(3)>;
+L<SSL_new(3)|SSL_new(3)>;
+L<SSL_set_session(3)|SSL_set_session(3)>;
+L<SSL_free(3)|SSL_free(3)>
+instead to avoid such failures
+(or simply L<SSL_free(3)|SSL_free(3)>; L<SSL_new(3)|SSL_new(3)>
+if session reuse is not desired).
 
 =head1 RETURN VALUES
 
@@ -50,12 +56,12 @@ The following return values can occur:
 
 =over 4
 
-=item 0
+=item Z<>0
 
 The SSL_clear() operation could not be performed. Check the error stack to
 find out the reason.
 
-=item 1
+=item Z<>1
 
 The SSL_clear() operation was successful.
 

doc/ssl/SSL_connect.pod

@@ -41,17 +41,17 @@ The following return values can occur:
 
 =over 4
 
-=item 1
-
-The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
-established.
-
-=item 0
+=item Z<>0
 
 The TLS/SSL handshake was not successful but was shut down controlled and
 by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
 return value B<ret> to find out the reason.
 
+=item Z<>1
+
+The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
+established.
+
 =item E<lt>0
 
 The TLS/SSL handshake was not successful, because a fatal error occurred either

doc/ssl/SSL_do_handshake.pod

@@ -23,10 +23,7 @@ L<SSL_set_accept_state(3)|SSL_set_accept_state(3)>.
 The behaviour of SSL_do_handshake() depends on the underlying BIO.
 
 If the underlying BIO is B<blocking>, SSL_do_handshake() will only return
-once the handshake has been finished or an error occurred, except for SGC
-(Server Gated Cryptography). For SGC, SSL_do_handshake() may return with -1,
-but SSL_get_error() will yield B<SSL_ERROR_WANT_READ/WRITE> and
-SSL_do_handshake() should be called again.
+once the handshake has been finished or an error occurred.
 
 If the underlying BIO is B<non-blocking>, SSL_do_handshake() will also return
 when the underlying BIO could not satisfy the needs of SSL_do_handshake()
@@ -45,17 +42,17 @@ The following return values can occur:
 
 =over 4
 
-=item 1
-
-The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
-established.
-
-=item 0
+=item Z<>0
 
 The TLS/SSL handshake was not successful but was shut down controlled and
 by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
 return value B<ret> to find out the reason.
 
+=item Z<>1
+
+The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
+established.
+
 =item E<lt>0
 
 The TLS/SSL handshake was not successful because a fatal error occurred either

doc/ssl/SSL_get_peer_cert_chain.pod

@@ -8,11 +8,11 @@ SSL_get_peer_cert_chain - get the X509 certificate chain of the peer
 
  #include <openssl/ssl.h>
 
- STACKOF(X509) *SSL_get_peer_cert_chain(const SSL *ssl);
+ STACK_OF(X509) *SSL_get_peer_cert_chain(const SSL *ssl);
 
 =head1 DESCRIPTION
 
-SSL_get_peer_cert_chain() returns a pointer to STACKOF(X509) certificates
+SSL_get_peer_cert_chain() returns a pointer to STACK_OF(X509) certificates
 forming the certificate chain of the peer. If called on the client side,
 the stack also contains the peer's certificate; if called on the server
 side, the peer's certificate must be obtained separately using
@@ -24,7 +24,7 @@ If the peer did not present a certificate, NULL is returned.
 The peer certificate chain is not necessarily available after reusing
 a session, in which case a NULL pointer is returned.
 
-The reference count of the STACKOF(X509) object is not incremented.
+The reference count of the STACK_OF(X509) object is not incremented.
 If the corresponding session is freed, the pointer must not be used
 any longer.
 
@@ -39,7 +39,7 @@ The following return values can occur:
 No certificate was presented by the peer or no connection was established
 or the certificate chain is no longer available when a session is reused.
 
-=item Pointer to a STACKOF(X509)
+=item Pointer to a STACK_OF(X509)
 
 The return value points to the certificate chain presented by the peer.
 

doc/ssl/SSL_get_version.pod

@@ -12,12 +12,12 @@ SSL_get_version - get the protocol version of a connection.
 
 =head1 DESCRIPTION
 
-SSL_get_cipher_version() returns the name of the protocol used for the
+SSL_get_version() returns the name of the protocol used for the
 connection B<ssl>.
 
 =head1 RETURN VALUES
 
-The following strings can occur:
+The following strings can be returned:
 
 =over 4
 
@@ -31,7 +31,15 @@ The connection uses the SSLv3 protocol.
 
 =item TLSv1
 
-The connection uses the TLSv1 protocol.
+The connection uses the TLSv1.0 protocol.
+
+=item TLSv1.1
+
+The connection uses the TLSv1.1 protocol.
+
+=item TLSv1.2
+
+The connection uses the TLSv1.2 protocol.
 
 =item unknown
 

doc/ssl/SSL_pending.pod

@@ -29,8 +29,9 @@ The number of bytes pending is returned.
 
 SSL_pending() takes into account only bytes from the TLS/SSL record
 that is currently being processed (if any).  If the B<SSL> object's
-I<read_ahead> flag is set, additional protocol bytes may have been
-read containing more TLS/SSL records; these are ignored by
+I<read_ahead> flag is set (see
+L<SSL_CTX_set_read_ahead(3)|SSL_CTX_set_read_ahead(3)>), additional protocol
+bytes may have been read containing more TLS/SSL records; these are ignored by
 SSL_pending().
 
 Up to OpenSSL 0.9.6, SSL_pending() does not check if the record type
@@ -38,6 +39,7 @@ of pending data is application data.
 
 =head1 SEE ALSO
 
-L<SSL_read(3)|SSL_read(3)>, L<ssl(3)|ssl(3)>
+L<SSL_read(3)|SSL_read(3)>,
+L<SSL_CTX_set_read_ahead(3)|SSL_CTX_set_read_ahead(3)>, L<ssl(3)|ssl(3)>
 
 =cut

doc/ssl/SSL_read.pod

@@ -86,7 +86,7 @@ The following return values can occur:
 The read operation was successful; the return value is the number of
 bytes actually read from the TLS/SSL connection.
 
-=item 0
+=item Z<>0
 
 The read operation was not successful. The reason may either be a clean
 shutdown due to a "close notify" alert sent by the peer (in which case

doc/ssl/SSL_session_reused.pod

@@ -27,11 +27,11 @@ The following return values can occur:
 
 =over 4
 
-=item 0
+=item Z<>0
 
 A new session was negotiated.
 
-=item 1
+=item Z<>1
 
 A session was reused.
 

doc/ssl/SSL_set_fd.pod

@@ -35,11 +35,11 @@ The following return values can occur:
 
 =over 4
 
-=item 0
+=item Z<>0
 
 The operation failed. Check the error stack to find out why.
 
-=item 1
+=item Z<>1
 
 The operation succeeded.
 

doc/ssl/SSL_set_session.pod

@@ -37,11 +37,11 @@ The following return values can occur:
 
 =over 4
 
-=item 0
+=item Z<>0
 
 The operation failed; check the error stack to find out the reason.
 
-=item 1
+=item Z<>1
 
 The operation succeeded.
 

doc/ssl/SSL_set_shutdown.pod

@@ -24,7 +24,7 @@ The shutdown state of an ssl connection is a bitmask of:
 
 =over 4
 
-=item 0
+=item Z<>0
 
 No shutdown setting, yet.
 

doc/ssl/SSL_shutdown.pod

@@ -92,19 +92,19 @@ The following return values can occur:
 
 =over 4
 
-=item 1
-
-The shutdown was successfully completed. The "close notify" alert was sent
-and the peer's "close notify" alert was received.
-
-=item 0
+=item Z<>0
 
 The shutdown is not yet finished. Call SSL_shutdown() for a second time,
 if a bidirectional shutdown shall be performed.
 The output of L<SSL_get_error(3)|SSL_get_error(3)> may be misleading, as an
 erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred.
 
-=item -1
+=item Z<>1
+
+The shutdown was successfully completed. The "close notify" alert was sent
+and the peer's "close notify" alert was received.
+
+=item E<lt>0
 
 The shutdown was not successful because a fatal error occurred either
 at the protocol level or a connection failure occurred. It can also occur if

doc/ssl/SSL_write.pod

@@ -79,7 +79,7 @@ The following return values can occur:
 The write operation was successful, the return value is the number of
 bytes actually written to the TLS/SSL connection.
 
-=item 0
+=item Z<>0
 
 The write operation was not successful. Probably the underlying connection
 was closed. Call SSL_get_error() with the return value B<ret> to find out,

doc/ssl/d2i_SSL_SESSION.pod

@@ -48,6 +48,16 @@ known limit on the size of the created ASN1 representation, so the necessary
 amount of space should be obtained by first calling i2d_SSL_SESSION() with
 B<pp=NULL>, and obtain the size needed, then allocate the memory and
 call i2d_SSL_SESSION() again.
+Note that this will advance the value contained in B<*pp> so it is necessary
+to save a copy of the original allocation.
+For example:
+ int i,j;
+ char *p, *temp;
+ i = i2d_SSL_SESSION(sess, NULL);
+ p = temp = malloc(i);
+ j = i2d_SSL_SESSION(sess, &temp);
+ assert(i == j);
+ assert(p+i == temp);
 
 =head1 RETURN VALUES
 

doc/ssl/ssl.pod

@@ -158,7 +158,7 @@ Constructor for the SSLv3 SSL_METHOD structure for combined client and server.
 
 Constructor for the TLSv1 SSL_METHOD structure for a dedicated client.
 
-=item cosnt SSL_METHOD *B<TLSv1_server_method>(void);
+=item const SSL_METHOD *B<TLSv1_server_method>(void);
 
 Constructor for the TLSv1 SSL_METHOD structure for a dedicated server.
 
@@ -229,6 +229,8 @@ protocol context defined in the B<SSL_CTX> structure.
 
 =item int (*B<SSL_CTX_get_client_cert_cb>(SSL_CTX *ctx))(SSL *ssl, X509 **x509, EVP_PKEY **pkey);
 
+=item void B<SSL_CTX_get_default_read_ahead>(SSL_CTX *ctx);
+
 =item char *B<SSL_CTX_get_ex_data>(const SSL_CTX *s, int idx);
 
 =item int B<SSL_CTX_get_ex_new_index>(long argl, char *argp, int (*new_func);(void), int (*dup_func)(void), void (*free_func)(void))
@@ -237,6 +239,8 @@ protocol context defined in the B<SSL_CTX> structure.
 
 =item int B<SSL_CTX_get_quiet_shutdown>(const SSL_CTX *ctx);
 
+=item void B<SSL_CTX_get_read_ahead>(SSL_CTX *ctx);
+
 =item int B<SSL_CTX_get_session_cache_mode>(SSL_CTX *ctx);
 
 =item long B<SSL_CTX_get_timeout>(const SSL_CTX *ctx);
@@ -325,6 +329,8 @@ protocol context defined in the B<SSL_CTX> structure.
 
 =item void B<SSL_CTX_set_quiet_shutdown>(SSL_CTX *ctx, int mode);
 
+=item void B<SSL_CTX_set_read_ahead>(SSL_CTX *ctx, int m);
+
 =item void B<SSL_CTX_set_session_cache_mode>(SSL_CTX *ctx, int mode);
 
 =item int B<SSL_CTX_set_ssl_version>(SSL_CTX *ctx, const SSL_METHOD *meth);
@@ -374,6 +380,10 @@ session instead of a context.
 
 =item int B<SSL_CTX_use_certificate_file>(SSL_CTX *ctx, char *file, int type);
 
+=item X509 *B<SSL_CTX_get0_certificate>(const SSL_CTX *ctx);
+
+=item EVP_PKEY *B<SSL_CTX_get0_privatekey>(const SSL_CTX *ctx);
+
 =item void B<SSL_CTX_set_psk_client_callback>(SSL_CTX *ctx, unsigned int (*callback)(SSL *ssl, const char *hint, char *identity, unsigned int max_identity_len, unsigned char *psk, unsigned int max_psk_len));
 
 =item int B<SSL_CTX_use_psk_identity_hint>(SSL_CTX *ctx, const char *hint);
@@ -507,7 +517,7 @@ connection defined in the B<SSL> structure.
 
 =item X509 *B<SSL_get_peer_certificate>(const SSL *ssl);
 
-=item EVP_PKEY *B<SSL_get_privatekey>(SSL *ssl);
+=item EVP_PKEY *B<SSL_get_privatekey>(const SSL *ssl);
 
 =item int B<SSL_get_quiet_shutdown>(const SSL *ssl);
 
@@ -703,6 +713,7 @@ L<SSL_CTX_set_mode(3)|SSL_CTX_set_mode(3)>,
 L<SSL_CTX_set_msg_callback(3)|SSL_CTX_set_msg_callback(3)>,
 L<SSL_CTX_set_options(3)|SSL_CTX_set_options(3)>,
 L<SSL_CTX_set_quiet_shutdown(3)|SSL_CTX_set_quiet_shutdown(3)>,
+L<SSL_CTX_set_read_ahead(3)|SSL_CTX_set_read_ahead(3)>,
 L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>,
 L<SSL_CTX_set_session_id_context(3)|SSL_CTX_set_session_id_context(3)>,
 L<SSL_CTX_set_ssl_version(3)|SSL_CTX_set_ssl_version(3)>,