path: root/lib/ssl/doc/src/ssl.xml

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE erlref SYSTEM "erlref.dtd">

<erlref>
  <header>
    <copyright>
      <year>1999</year><year>2023</year>
      <holder>Ericsson AB. All Rights Reserved.</holder>
    </copyright>
    <legalnotice>
      Licensed under the Apache License, Version 2.0 (the "License");
      you may not use this file except in compliance with the License.
      You may obtain a copy of the License at
 
          http://www.apache.org/licenses/LICENSE-2.0

      Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
      See the License for the specific language governing permissions and
      limitations under the License.

    </legalnotice>
    <title>ssl</title>
    <prepared></prepared>
    <docno></docno>
    <date></date>
    <rev></rev>
    <file>ssl.xml</file>
  </header>
  <module since="">ssl</module>
  <modulesummary>Interface Functions for Secure Socket Layer</modulesummary>
  <description>
    <p>
      This module contains interface functions for the TLS/DTLS protocol.
      For detailed information about the supported standards see 
      <seeapp marker="ssl_app">ssl(6)</seeapp>.
    </p>
  </description>

  <!--
      ================================================================
      =  Data types                                                  =
      ================================================================
  -->

  <datatypes>
    <datatype_title>Types used in TLS/DTLS</datatype_title>

    
    <datatype>
      <name name="socket"/>
    </datatype>
    
    <datatype>
      <name name="sslsocket"/>
      <desc>
	<p>An opaque reference to the TLS/DTLS connection, may be used for equality matching.</p>
	</desc>
    </datatype>

    <datatype>
      <name name="tls_option"/>
    </datatype>
        
    <datatype>
      <name name="tls_client_option"/>
    </datatype>
    
    <datatype>
      <name name="tls_server_option"/>
    </datatype>
   
    
    <datatype>
      <name name="socket_option"/>
      <desc>
	<p>The default socket options are
	<c>[{mode,list},{packet, 0},{header, 0},{active, true}]</c>.</p>
	<p>For valid options, see the
	<seeerl marker="kernel:inet">inet(3)</seeerl>,
	<seeerl marker="kernel:gen_tcp">gen_tcp(3)</seeerl> and
	<seeerl marker="kernel:gen_tcp">gen_udp(3)</seeerl> 
	manual pages in Kernel. Note that stream oriented options such as packet
	are only relevant for TLS and not DTLS</p>
      </desc>
    </datatype>

    <datatype>
      <name name="active_msgs"/>
      <desc>
      <p>When a TLS/DTLS socket is in active mode (the default), data from the
      socket is delivered to the owner of the socket in the form of
      messages as described above.</p>
      <p>The <c>ssl_passive</c> message is sent only when the socket is in
      <c>{active, N}</c> mode and the counter dropped to 0. It indicates
      that the socket has transitioned to passive (<c>{active, false}</c>) mode.</p>
      </desc>
    </datatype>
      
    <datatype>
      <name name="transport_option"/>
      <desc>
	<p>Defaults to <c>{gen_tcp, tcp, tcp_closed, tcp_error,
	tcp_passive}</c> for TLS (for backward compatibility a four
	tuple will be converted to a five tuple with the last element
	"second_element"_passive) and <c>{gen_udp, udp, udp_closed,
	udp_error}</c> for DTLS (might also be changed to five tuple in
	the future). Can be used to customize the transport layer. The
	tag values should be the values used by the underlying
	transport in its active mode messages. For TLS the callback
	module must implement a reliable transport protocol, behave as
	<c>gen_tcp</c>, and have functions corresponding to
	<c>inet:setopts/2</c>, <c>inet:getopts/2</c>,
	<c>inet:peername/1</c>, <c>inet:sockname/1</c>, and
	<c>inet:port/1</c>.  The callback <c>gen_tcp</c> is treated
	specially and calls <c>inet</c> directly. For DTLS this
	feature must be considered experimental.
	</p>
      </desc>
    </datatype>
  
     <datatype>
      <name name="host"/>
     </datatype>

     <datatype>
      <name name="hostname"/>
     </datatype>

     <datatype>
      <name name="ip_address"/>
     </datatype>

     <datatype>
       <name name="protocol_version"/>
     </datatype>

     <datatype>
       <name name="tls_version"/>
     </datatype>

     <datatype>
       <name name="dtls_version"/>
     </datatype>

     <datatype>
       <name name="tls_legacy_version"/>
     </datatype>

     <datatype>
       <name name="dtls_legacy_version"/>
     </datatype>

     <datatype>
       <name name="prf_random"/>
     </datatype>
     
      <datatype>
       <name name="verify_type"/>
     </datatype>
       
     <datatype>
       <name name="ciphers"/>
     </datatype>
     
      <datatype>
       <name name="erl_cipher_suite"/>
     </datatype>
     
     <datatype>
       <name name="cipher"/>
     </datatype>
    
     <datatype>
       <name name="legacy_cipher"/>
     </datatype>
    
     <datatype>
       <name name="cipher_filters"/>
     </datatype>
 
       <datatype>
       <name name="hash"/>
     </datatype>

     <datatype>
       <name name="sha2"/>
     </datatype>

     <datatype>
       <name name="legacy_hash"/>
     </datatype>

    <datatype>
       <name name="old_cipher_suite"/>
     </datatype>
     
     <datatype>
      <name name="sign_algo"/>
     </datatype>
     
     <datatype>
       <name name="sign_scheme"/>
     </datatype>

     <datatype>
       <name name="rsassa_pss_scheme"/>
     </datatype>

     <datatype>
       <name name="sign_scheme_legacy"/>
     </datatype>

     <datatype>
       <name name="group"/>
     </datatype>
     
     <datatype>
      <name name="kex_algo"/>
     </datatype>

     <datatype>
      <name name="algo_filter"/>
     </datatype>

     <datatype>
      <name name="named_curve"/>
     </datatype>

     <datatype>
       <name name="legacy_named_curve"/>
     </datatype>
     
     <datatype>
       <name name="psk_identity"/>
     </datatype>

     <datatype>
       <name name="srp_identity"/>
     </datatype>

     <datatype>
      <name name="srp_param_type"/>
     </datatype>
     
     <datatype>
       <name name="app_level_protocol"/>
     </datatype>

     <datatype>
      <name name="protocol_extensions"/>
     </datatype>

     <datatype>
      <name name="error_alert"/>
     </datatype>

     <datatype>
      <name name="tls_alert"/>
     </datatype>

     <datatype>
      <name name="reason"/>
     </datatype>

     <datatype>
      <name name="bloom_filter_window_size"/>
     </datatype>

     <datatype>
      <name name="bloom_filter_hash_functions"/>
     </datatype>

     <datatype>
      <name name="bloom_filter_bits"/>
     </datatype>

     <datatype>
      <name name="client_session_tickets"/>
     </datatype>

     <datatype>
      <name name="server_session_tickets"/>
     </datatype>

    <datatype_title>TLS/DTLS OPTION DESCRIPTIONS - COMMON for SERVER and CLIENT</datatype_title>
    
    <datatype>
      <name name="common_option"/>
    </datatype>
    
    <datatype>
      <name since="OTP 20" name="protocol"/>
      <desc>
	<p>Choose TLS or DTLS protocol for the transport layer security.
	Defaults to <c>tls</c>. For DTLS other transports than UDP are not yet supported.</p>
      </desc>
    </datatype>
    
    <datatype>
      <name name="handshake_completion"/>
      <desc>
	<p>Defaults to <c>full</c>. If hello is specified the handshake will
	pause after the hello message and give the user a possibility make decisions
	based on hello extensions before continuing or aborting the handshake by calling
	<seemfa marker="#handshake_continue/3"> handshake_continue/3</seemfa> or
	<seemfa marker="#handshake_cancel/1"> handshake_cancel/1</seemfa></p>
      </desc>
    </datatype>
    
    <datatype>
      <name name="cert"/>
      <desc>
	<p>The DER-encoded user certificate. Note that the cert option may also
	be a list of DER-encoded certificates where the first one is the user
	certificate, and the rest of the certificates constitutes the
	certificate chain. For maximum interoperability the
	certificates in the chain should be in the correct order, the
	chain will be sent as is to the peer. If chain certificates
	are not provided, certificates from <seetype
	marker="#client_cacerts">client_cacerts()</seetype>, <seetype
	marker="#server_cacerts">server_cacerts()</seetype>, or
	<seetype marker="#client_cafile">client_cafile()</seetype>,
	<seetype marker="#server_cafile">server_cafile()</seetype> are
	used to construct the chain.  If this option is supplied, it
	overrides option <c>certfile</c>.</p>
      </desc>
    </datatype>
    
    <datatype>
      <name name="cert_pem"/>
      <desc>
	<p>Path to a file containing the user certificate on PEM format or possible several
	certificates where the first one is the user certificate and the rest of the certificates
	constitutes the certificate chain. For more details see <seetype marker="#cert">cert()</seetype>,
	</p>
      </desc>
    </datatype>
    
    <datatype>
      <name name="key"/>
      <desc>
	<p>The DER-encoded user's private key or a map referring to a crypto
	engine and its key reference that optionally can be password protected,
	see also <seemfa marker="crypto:crypto#engine_load/3"> crypto:engine_load/3
	</seemfa> and <seeguide marker="crypto:engine_load"> Crypto's Users Guide</seeguide>. If this option 
	is supplied, it overrides option <c>keyfile</c>.</p>
      </desc>
    </datatype>
    
     <datatype>
       <name name="key_pem"/>
       <desc>
	<p>Path to the file containing the user's
	private PEM-encoded key. As PEM-files can contain several
	entries, this option defaults to the same file as given by
	option <c>certfile</c>.</p>
       </desc>
     </datatype>
     
    <datatype>
      <name name="key_pem_password"/>
      <desc>
	<p>String containing the user's password or a function returning same type. Only used if the
	private keyfile is password-protected.</p>
      </desc>
    </datatype>

    <datatype>
      <name name="certs_keys"/>
      <desc>
	<p>A list of a certificate (or possible a certificate and its
	chain) and the associated key of the certificate, that may be
	used to authenticate the client or the server.  The
	certificate key pair that is considered best and matches
	negotiated parameters for the connection will be selected.
	Different signature algorithms are prioritized in the order
	<c> eddsa, ecdsa, rsa_pss_pss, rsa and dsa </c>.  If more than
	one key is supplied for the same signing algorithm (which is
	probably an unusual use case) they will prioritized by
	strength unless it is a so called <c>engine key</c> that will
	be favoured over other keys. As engine keys cannot be
	inspected, supplying more than one engine key will make no
	sense. This offers flexibility to for instance configure a
	newer certificate that is expected to be used in most cases
	and an older but acceptable certificate that will only be used
	to communicate with legacy systems. Note that there is a trade
	off between the induced overhead and the flexibility so
	alternatives should be chosen for good reasons. If the <c>certs_keys</c> option is specified it
	overrides all single certificate and key options. For examples see <seeguide marker="ssl:using_ssl"> the Users Guide</seeguide>
	</p>

	<note><p> <c>eddsa</c> certificates are only supported by TLS-1.3 that does not support  <c>dsa</c> certificates.
	 <c>rsa_pss_pss</c> (RSA certificates using Probabilistic Signature Scheme) are supported in TLS-1.2 and TLS-1.3, but some
	TLS-1.2 implementations may not support <c>rsa_pss_pss</c>.
	</p></note>
      </desc>
    </datatype>

    <datatype>
      <name name="cert_key_conf"/>
      <desc>
	<p> A certificate (or possibly a certificate and its chain) and its associated key on one of the
	possible formats. For the PEM file format there may also be a password associated with the file containg the key.
	</p>
      </desc>
    </datatype>

    <datatype>
      <name name="cipher_suites"/>
      <desc>
	<p>A list of cipher suites that should be supported</p>

	<p>The function <seemfa
	marker="#cipher_suites/2"> ssl:cipher_suites/2 </seemfa>
	can be used to find all cipher suites that
	are supported by default and all cipher suites that may be configured.</p>

	<p>If you compose your own <c>cipher_suites()</c> make
	sure they are filtered for cryptolib support
	<seemfa
	    marker="#filter_cipher_suites/2"> ssl:filter_cipher_suites/2 </seemfa>
	Additionally the functions <seemfa
	marker="#append_cipher_suites/2"> ssl:append_cipher_suites/2 </seemfa>
	, <seemfa
	marker="#prepend_cipher_suites/2"> ssl:prepend_cipher_suites/2</seemfa>,
	<seemfa marker="#suite_to_str/1">ssl:suite_to_str/1</seemfa>,
	<seemfa marker="#str_to_suite/1">ssl:str_to_suite/1</seemfa>,
	and <seemfa marker="#suite_to_openssl_str/1">ssl:suite_to_openssl_str/1</seemfa>
	also exist to help creating customized cipher suite lists.</p>

	<note><p>Note that TLS-1.3 and TLS-1.2 cipher suites are not overlapping
	sets of cipher suites so to support both these versions cipher
	suites from both versions need to be included. Also if the supplied list does
	not comply with the configured versions or cryptolib so that the list becomes empty,
	this option will fallback on its appropriate default value for the configured versions.
	</p></note>

	<p>Non-default cipher suites including anonymous cipher suites (PRE TLS-1.3) are supported for
	interop/testing purposes and may be used by adding them to your cipher suite list.
	Note that they must also be supported/enabled by the peer to actually be used.
	</p>
      </desc>
    </datatype>


      <datatype>
	<name name="signature_algs"/>
	<desc>

	  <p>Explicitly list acceptable signature algorithms for certificates and handshake messages
	  in the preferred order. The client will send its list as the client hello <c>signature_algorithm</c> extension
	  introduced in TLS-1.2, see <url href="http://www.ietf.org/rfc/rfc5246.txt">Section 7.4.1.4.1 in RFC 5246</url>.
	  Previously these algorithms where implicitly chosen and partly derived from the cipher suite. </p>

	  <p>In TLS-1.2 a somewhat more explicit negotiation is made possible using a list of
	  {<seetype marker="#hash">hash()</seetype>,  <seetype marker="#signature_algs">sign_algo()</seetype>} pairs.
	  </p>

	  <p>In TLS-1.3 these algorithm pairs are
	  replaced by so called signature schemes <seetype marker="#sign_scheme">sign_scheme()</seetype>
	  and completely decoupled from the cipher suite.
	  </p>

	  <p>Signature algorithms used for certificates may be overridden by the
	  <seetype marker="#sign_schemes">signature schemes</seetype> (algorithms) supplied by the <c>signature_algs_cert</c> option.</p>

	  <p>TLS-1.2 default is Default_TLS_12_Alg_Pairs interleaved with rsa_pss_schemes since ssl-11.0 (OTP-25)
	  pss_pss is prefered over pss_rsae that is prefered over rsa</p>

	  <p><c>Default_TLS_12_Alg_Pairs =</c></p>
	  <code>[
%% SHA2
{sha512, ecdsa},
{sha512, rsa},
{sha384, ecdsa},
{sha384, rsa},
{sha256, ecdsa},
{sha256, rsa}
]</code>

<p>Support for {md5, rsa} was removed from the the TLS-1.2 default in ssl-8.0 (OTP-22) and support for SHA1 {sha, _}  and SHA224 {sha224, _} was removed in ssl-11.0 (OTP-26) </p>

 <p><c> rsa_pss_schemes =</c></p>
 <code>
[rsa_pss_pss_sha512,
rsa_pss_pss_sha384,
rsa_pss_pss_sha256,
rsa_pss_rsae_sha512,
rsa_pss_rsae_sha384,
rsa_pss_rsae_sha256]
 </code>

 <p><c> TLS_13_Legacy_Schemes =</c></p>
 <code> [
 %% Legacy algorithms only applicable to certificate signatures
rsa_pkcs1_sha512, %% Corresponds to {sha512, rsa}
rsa_pkcs1_sha384, %% Corresponds to {sha384, rsa}
rsa_pkcs1_sha256, %% Corresponds to {sha256, rsa}
]
</code>

 <p><c> Default_TLS_13_Schemes =</c></p>
 <code> [
 %% EDDSA
eddsa_ed25519,
eddsa_ed448

%% ECDSA
ecdsa_secp521r1_sha512,
ecdsa_secp384r1_sha384,
ecdsa_secp256r1_sha256] ++

%% RSASSA-PSS
rsa_pss_schemes()
 </code>

 <p>EDDSA was made highest priority in ssl-10.8 (OTP-25) </p>

<p>TLS-1.3 default is</p>
<code>Default_TLS_13_Schemes</code>

<p>If both TLS-1.3 and TLS-1.2 are supported the default will be</p>
<code>Default_TLS_13_Schemes ++ TLS_13_Legacy_Schemes ++ Default_TLS_12_Alg_Pairs (not represented in TLS_13_Legacy_Schemes) </code>

<p>so appropriate algorithms can be chosen for the negotiated
version.
</p>

<note> <p> TLS-1.2 algorithms will not be negotiated for TLS-1.3, but TLS-1.3 RSASSA-PSS  <seetype marker="#rsassa_pss_scheme">rsassa_pss_scheme()</seetype>
	 signature schemes may be negotiated also for TLS-1.2 from 24.1 (fully working from 24.1.3).
	 However if TLS-1.3 is negotiated when both TLS-1.3 and TLS-1.2 is supported using defaults, the corresponding TLS-1.2 algorithms
         to the TLS-1.3 legacy signature schemes will be considered as the legacy schemes and applied only to certificate signatures.
	 </p>
	</note>

      </desc>
      </datatype>

    <datatype>
      <name name="sign_schemes"/>

      <desc>
	<p>Explicitly list acceptable signature schemes (algorithms)
	in the preferred order. Overrides the algorithms supplied in <seetype
	marker="#signature_algs"><c>signature_algs</c></seetype> option for
	certificates.</p>

	<p>
	  In addition to the <c>signature_algorithms</c> extension from TLS
	  1.2, <url
	  href="http://www.ietf.org/rfc/rfc8446.txt#section-4.2.3">TLS
	  1.3 (RFC 5246 Section 4.2.3)</url> adds the
	  <c>signature_algorithms_cert</c> extension which enables having
	  special requirements on the signatures used in the
	  certificates that differs from the requirements on digital
	  signatures as a whole.  If this is not required this
	  extension is not need.
	</p>

	<p>
	  The client will send a <c>signature_algorithms_cert</c> extension
	  (in the client hello message), if TLS version 1.2
	  (back-ported to TLS 1.2 in 24.1) or later is used, and
	  the signature_algs_cert option is explicitly specified. By
	  default, only the <seetype
	  marker="#signature_algs">signature_algs</seetype> extension
	  is sent. </p>

	  <note> <p> Note that supported signature schemes for TLS-1.2
	  are <seetype
	  marker="#sign_scheme_legacy">sign_scheme_legacy()</seetype>
	  and <seetype
	  marker="#rsassa_pss_scheme">rsassa_pss_scheme()</seetype>
	  </p></note>
      </desc>
    </datatype>

     <datatype>
       <name name="supported_groups"/>
       <desc>
	 <p>TLS 1.3 introduces the "supported_groups" extension that is used for negotiating
	 the Diffie-Hellman parameters in a TLS 1.3 handshake. Both client and server
	 can specify a list of parameters that they are willing to use.
	 </p>
	 <p> If it is not specified it will use a default list ([x25519, x448, secp256r1, secp384r1]) that
	 is filtered based on the installed crypto library version.
	 </p>
      </desc>
     </datatype>

    <datatype>
      <name name="secure_renegotiation"/>
      <desc><p>Specifies if to reject renegotiation attempt that does
      not live up to <url
      href="http://www.ietf.org/rfc/rfc5746.txt">RFC 5746</url>.  By
      default <c>secure_renegotiate</c> is set to <c>true</c>, that
      is, secure renegotiation is enforced. If set to <c>false</c>
      secure renegotiation will still be used if possible, but it
      falls back to insecure renegotiation if the peer does not
      support <url href="http://www.ietf.org/rfc/rfc5746.txt">RFC
      5746</url>.</p>
      </desc>
    </datatype>
    
    <datatype>
      <name name="allowed_cert_chain_length"/>
      <desc><p>Maximum number of non-self-issued
      intermediate certificates that can follow the peer certificate 
      in a valid certification path. So, if depth is 0 the PEER must 
      be signed by the trusted ROOT-CA directly; if 1 the path can 
      be PEER, CA, ROOT-CA; if 2 the path can be PEER, CA, CA, 
      ROOT-CA, and so on. The default value is 10.</p>
      </desc>
    </datatype>
    
    <datatype>
      <name name="custom_verify"/>
      <desc>
	<p>The verification fun is to be defined as follows:</p>

	<code>
fun(OtpCert :: #'OTPCertificate'{},
    Event, InitialUserState :: term()) ->
	{valid, UserState :: term()} |
	{fail, Reason :: term()} | {unknown, UserState :: term()}.

fun(OtpCert :: #'OTPCertificate'{}, DerCert :: public_key:der_encoded(),
    Event, InitialUserState :: term()) ->
	{valid, UserState :: term()} |
	{fail, Reason :: term()} | {unknown, UserState :: term()}.

Types:
      Event = {bad_cert, Reason :: atom() |
              {revoked, atom()}} |
	      {extension, #'Extension'{}} |
              valid |
              valid_peer
	</code>

	<p>The verification fun is called during the X509-path
	validation when an error or an extension unknown to the SSL
	application is encountered. It is also called when a
	certificate is considered valid by the path validation to
	allow access to each certificate in the path to the user
	application. It differentiates between the peer certificate
	and the CA certificates by using <c>valid_peer</c> or
	<c>valid</c> as <c>Event</c> argument to the verification fun.
        See the <seeguide marker="public_key:public_key_records">public_key
	User's Guide</seeguide> for definition of
	<c>#'OTPCertificate'{}</c> and <c>#'Extension'{}</c>.</p>

	<list type="bulleted">
	  <item><p>If the verify callback fun returns <c>{fail,
	  Reason}</c>, the verification process is immediately
	  stopped, an alert is sent to the peer, and the TLS/DTLS
	  handshake terminates.</p></item>
	  <item><p>If the verify callback fun returns <c>{valid, UserState}</c>,
	  the verification process continues.</p></item> 
	  <item><p>If the verify callback fun always returns
	  <c>{valid, UserState}</c>, the TLS/DTLS handshake does not
	  terminate regarding verification failures and the connection is
	  established.</p></item>
	  <item><p>If called with an extension unknown to the user application,
	  return value <c>{unknown, UserState}</c> is to be used.</p>

	  <p>Note that if the fun returns <c>unknown</c> for an extension marked
	  as critical, validation will fail.</p>
	  </item>
	</list>

	<p>Default option <c>verify_fun</c> in <c>verify_peer mode</c>:</p>

      <code>
{fun(_,{bad_cert, _} = Reason, _) ->
	 {fail, Reason};
    (_,{extension, _}, UserState) ->
	 {unknown, UserState};
    (_, valid, UserState) ->
	 {valid, UserState};
    (_, valid_peer, UserState) ->
         {valid, UserState}
 end, []}
      </code>

      <p>Default option <c>verify_fun</c> in mode <c>verify_none</c>:</p>

       <code>
{fun(_,{bad_cert, _}, UserState) ->
	 {valid, UserState};
    (_,{extension, #'Extension'{critical = true}}, UserState) ->
	 {valid, UserState};
    (_,{extension, _}, UserState) ->
	 {unknown, UserState};
    (_, valid, UserState) ->
	 {valid, UserState};
    (_, valid_peer, UserState) ->
         {valid, UserState}
 end, []}
      </code>

      <p>The possible path validation errors are given on form
      <c>{bad_cert, Reason}</c> where <c>Reason</c> is:</p>

      <taglist>
	<tag><c>unknown_ca</c></tag>
	<item><p>No trusted CA was found in the trusted store. The
	trusted CA is normally a so called ROOT CA, which is a
	self-signed certificate. Trust can be claimed for an
	intermediate CA (trusted anchor does not have to be
	self-signed according to X-509) by using option
	<c>partial_chain</c>.</p>
	</item>

	<tag><c>selfsigned_peer</c></tag>
	<item><p>The chain consisted only of one self-signed certificate.</p></item>

	<tag><c>PKIX X-509-path validation error</c></tag>
	<item><p>For possible reasons, see <seemfa
marker="public_key:public_key#pkix_path_validation/3">public_key:pkix_path_validation/3</seemfa>
	</p></item>
      </taglist>
      </desc>
    </datatype>
    
    <datatype>
      <name name="crl_check"/>
      <desc>
	<p>Perform CRL (Certificate Revocation List) verification
	<seemfa marker="public_key:public_key#pkix_crls_validate/3">
	(public_key:pkix_crls_validate/3)</seemfa> on all the
	certificates during the path validation <seemfa
	marker="public_key:public_key#pkix_path_validation/3">(public_key:pkix_path_validation/3)
	</seemfa>
	of the certificate chain. Defaults to <c>false</c>.</p>
	
	<taglist>
	  <tag><c>peer</c></tag>
	  <item>check is only performed on the peer certificate.</item>

	  <tag><c>best_effort</c></tag>
	  <item>if certificate revocation status cannot be determined
	  it will be accepted as valid.</item>
	</taglist>
	
	<p>The CA certificates specified for the connection will be used to 
	construct the certificate chain validating the CRLs.</p>
 	
	<p>The CRLs will be fetched from a local or external cache. See
	<seeerl marker="ssl:ssl_crl_cache_api">ssl_crl_cache_api(3)</seeerl>.</p>
      </desc>
    </datatype>

    <datatype>
      <name name="crl_cache_opts"/>
      <desc>
    	<p>Specify how to perform lookup and caching of certificate revocation lists.
    	<c>Module</c> defaults to <seeerl marker="ssl:ssl_crl_cache">ssl_crl_cache</seeerl>
    	with <c> DbHandle </c> being <c>internal</c> and an
    	empty argument list.</p>
	
    	<p>There are two implementations available:</p>
	
    	<taglist>
    	  <tag><c>ssl_crl_cache</c></tag>
    	  <item>
    	    <p>This module maintains a cache of CRLs.  CRLs can be
    	    added to the cache using the function <seemfa
    	    marker="ssl:ssl_crl_cache#insert/1">ssl_crl_cache:insert/1</seemfa>,
    	    and optionally automatically fetched through HTTP if the
    	    following argument is specified:</p>
	    
    	    <taglist>
    	      <tag><c>{http, timeout()}</c></tag>
    	      <item><p>
    		Enables fetching of CRLs specified as http URIs in<seeguide
    		marker="public_key:public_key_records">X509 certificate extensions</seeguide>.
    		Requires the OTP inets application.</p>
    	      </item>
    	    </taglist>
    	  </item>
	  
    	  <tag><c>ssl_crl_hash_dir</c></tag>
    	  <item>
    	    <p>This module makes use of a directory where CRLs are
    	    stored in files named by the hash of the issuer name.</p>

    	    <p>The file names consist of eight hexadecimal digits
    	    followed by <c>.rN</c>, where <c>N</c> is an integer,
    	    e.g. <c>1a2b3c4d.r0</c>.  For the first version of the
    	    CRL, <c>N</c> starts at zero, and for each new version,
    	    <c>N</c> is incremented by one.  The OpenSSL utility
    	    <c>c_rehash</c> creates symlinks according to this
    	    pattern.</p>

    	    <p>For a given hash value, this module finds all
    	    consecutive <c>.r*</c> files starting from zero, and those
    	    files taken together make up the revocation list.  CRL
    	    files whose <c>nextUpdate</c> fields are in the past, or
    	    that are issued by a different CA that happens to have the
    	    same name hash, are excluded.</p>
	    
    	    <p>The following argument is required:</p>

    	    <taglist>
    	      <tag><c>{dir, string()}</c></tag>
    	      <item><p>Specifies the directory in which the CRLs can be found.</p></item>
    	    </taglist>
    	  </item>
	  </taglist>
	</desc>
    </datatype>

    <datatype>
      <name name="root_fun"/>
      <desc>
	<code>
fun(Chain::[public_key:der_encoded()]) ->
	{trusted_ca, DerCert::public_key:der_encoded()} | unknown_ca.
	</code>
	<p>Claim an intermediate CA in the chain as trusted. TLS then
	performs <seemfa
	marker="public_key:public_key#pkix_path_validation/3">public_key:pkix_path_validation/3</seemfa>
	with the selected CA as trusted anchor and the rest of the chain.</p>
      </desc>
    </datatype>


    <datatype>
      <name name="protocol_versions"/>
      <desc><p>TLS protocol versions supported by started clients and servers.
      This option overrides the application environment option
      <c>protocol_version</c> and  <c>dtls_protocol_version</c>. If the environment option is not set, it defaults
      to all versions, supported by the SSL application.
      See also <seeapp marker="ssl:ssl_app">ssl(6).</seeapp></p>
      </desc>
    </datatype>


      <datatype>
      <name name="custom_user_lookup"/>
      <desc><p>The lookup fun is to defined as follows:</p>

	<code>
fun(psk, PSKIdentity :: binary(), UserState :: term()) ->
	{ok, SharedSecret :: binary()} | error;
fun(srp, Username :: binary(), UserState :: term()) ->
	{ok, {SRPParams :: srp_param_type(), Salt :: binary(),
	      DerivedKey :: binary()}} | error.
	</code>

	<p>For Pre-Shared Key (PSK) cipher suites, the lookup fun is
	called by the client and server to determine the shared
	secret. When called by the client, <c>PSKIdentity</c> is set to the
	hint presented by the server or to undefined. When called by the
	server, <c>PSKIdentity</c> is the identity presented by the client.</p>

	<p>For Secure Remote Password (SRP), the fun is only used by the server to
	obtain parameters that it uses to generate its session keys.
	<c>DerivedKey</c> is to be derived according to
	<url href="http://tools.ietf.org/html/rfc2945#section/3"> RFC 2945</url> and
	<url href="http://tools.ietf.org/html/rfc5054#section-2.4"> RFC 5054</url>:
	<c>crypto:sha([Salt, crypto:sha([Username, &lt;&lt;$:&gt;&gt;, Password])])</c>
	</p>
      </desc>
    </datatype>

    <datatype>
      <name name="session_id"/>
      <desc>
	<p>Identifies a TLS session.</p>
      </desc>
    </datatype>
    
    <datatype>    
      <name name="log_alert"/> 
      <desc><p>If set to <c>false</c>, TLS/DTLS Alert reports are not displayed.
      Deprecated in OTP 22, use {log_level, <seetype marker="#logging_level">logging_level()</seetype>} instead.</p> 
      </desc> 
    </datatype> 

    <datatype>    
      <name name="logging_level"/> 
      <desc><p>Specifies the log level for a TLS/DTLS
      connection. Alerts are logged on <c>notice</c> level, which is
      the default level. The level <c>debug</c> triggers verbose
      logging of TLS/DTLS protocol messages.  See also <seeapp marker="ssl_app">ssl(6)</seeapp>
    </p>
      </desc> 
    </datatype> 
    
    <datatype>    
    <name name="hibernate_after"/> 
    <desc><p>When an integer-value is specified, <c>TLS/DTLS-connection</c> 
    goes into hibernation after the specified number of milliseconds 
    of inactivity, thus reducing its memory footprint. When
    <c>undefined</c> is specified (this is the default), the process 
    never goes into hibernation.</p> 
    </desc> 
    </datatype> 

    <datatype>
      <name name="handshake_size"/>
      <desc>
    	<p>Integer (24 bits unsigned). Used to limit the size of
    	valid TLS handshake packets to avoid DoS attacks.
    	Defaults to 256*1024.</p>
      </desc>
    </datatype>
    
    <datatype>
      <name name="padding_check"/>
      <desc><p>Affects TLS-1.0 connections only.
      If set to <c>false</c>, it disables the block cipher padding check
      to be able to interoperate with legacy software.</p>
      <warning><p>Using <c>{padding_check, boolean()}</c> makes TLS
	vulnerable to the Poodle attack.</p></warning>
      </desc>
    </datatype>

    <datatype>
      <name name="beast_mitigation"/>
      <desc><p>Affects TLS-1.0 connections only. Used to change the BEAST
       mitigation strategy to interoperate with legacy software.
       Defaults to <c>one_n_minus_one</c>.</p>

      <p><c>one_n_minus_one</c> - Perform 1/n-1 BEAST mitigation.</p>

      <p><c>zero_n</c> - Perform 0/n BEAST mitigation.</p>

      <p><c>disabled</c> - Disable BEAST mitigation.</p>

      <warning><p>Using <c>{beast_mitigation, disabled}</c> makes TLS-1.0
        vulnerable to the BEAST attack.</p></warning>
      </desc>
    </datatype>
    
    <datatype>
      <name name="ssl_imp"/>
        <desc><p>Deprecated since OTP-17, has no effect.</p></desc>
    </datatype>

    <datatype>
      <name name="session_tickets"/>
      <desc><p>Configures the session ticket functionality in TLS 1.3 client and server. </p>
      </desc>
    </datatype>

    <datatype>
      <name name="key_update_at"/>
      <desc><p>Configures the maximum amount of bytes that can be sent on a TLS 1.3 connection
      before an automatic key update is performed.</p>
      <p>There are cryptographic limits on the amount of plaintext which can be safely
      encrypted under a given set of keys. The current default ensures that data integrity
      will not be breached with probability greater than 1/2^57. For more information see
      <url href="http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf">Limits on Authenticated
      Encryption Use in TLS</url>.</p>
      <warning><p>The default value of this option shall provide the above mentioned security
      guarantees and it shall be reasonable for most applications (~353 TB).</p>
      </warning>
      </desc>
    </datatype>

    <datatype>
      <name name="middlebox_comp_mode"/>
      <desc><p>Configures the middlebox compatibility mode on a TLS 1.3 connection.</p>
      <p>A significant number of middleboxes misbehave when a TLS 1.3 connection is
      negotiated. Implementations can increase the chance of making connections
      through those middleboxes by making the TLS 1.3 handshake more like a
      TLS 1.2 handshake.</p>
      <p>The middlebox compatibility mode is enabled (<c>true</c>) by default.</p>
      </desc>
    </datatype>

    <datatype>
      <name name="spawn_opts"/>
      <desc><p>Configures spawn options of TLS sender and receiver processes.</p>
      <p>Setting up garbage collection options can be helpful for trade-offs between
      CPU usage and Memory usage. 
      See <seemfa marker="erts:erlang#spawn_opt/2"><c>erlang:spawn_opt/2</c></seemfa>.</p>
      <p>For dist connections, default sender option is <c>[...{priority, max}]</c>, this priority
      option cannot be changed. For all connections, <c>...link</c> is added to receiver and cannot
      be changed.</p>
      </desc>
    </datatype>

    <datatype>
      <name name="keep_secrets"/>
      <desc><p>Configures a TLS 1.3 connection for keylogging</p>
      <p>In order to retrieve keylog information on a TLS 1.3 connection, it must be configured
      in advance to keep the client_random and various handshake secrets.</p>
      <p>The keep_secrets functionality is disabled (<c>false</c>) by default.</p>
      <p>Added in OTP 23.2</p>
      </desc>
    </datatype>

    <datatype_title>TLS/DTLS OPTION DESCRIPTIONS - CLIENT</datatype_title>
    
    <datatype>
      <name name="client_option"/>
    </datatype>
   
     <datatype>
      <name name="client_verify_type"/>
      <desc>
	<p>Defaults to <c>verify_none</c> as additional options are needed to be able to perform the certificate verification.
	A warning will be emitted unless <c>verify_none</c> is explicitly configured. Usually the applications will want to configure
	<c>verify_peer</c> together with an appropriate <c>cacert</c> or <c>cacertfile</c> option. For example an <c>HTTPS</c> client would normally
	use the option <c>{cacerts, public_key:cacerts_get()}</c> (available since OTP-25) to access the CA certificates
	provided by the OS. Using verify_none means that all x509-certificate path validation errors will be ignored.
        See also option <seetype marker="#custom_verify">verify_fun</seetype>.</p>
     </desc>
    </datatype>

    <datatype>
      <name name="client_reuse_session"/>
      <desc>
	<p>Reuses a specific session. The session should be referred by its session id if it is
	earlier saved with the option <c>{reuse_sessions, save}</c> since OTP-21.3 or
	explicitly specified by its session id and associated data since OTP-22.3.
	See also
	<seeguide marker="ssl:using_ssl#session-reuse-pre-tls-1.3">
	SSL's Users Guide, Session Reuse pre TLS 1.3.</seeguide>
      </p>
      </desc>
    </datatype>

    <datatype>
      <name name="client_reuse_sessions"/>
      <desc>
	<p>When <c>save</c> is specified a new connection will be negotiated
      and saved for later reuse. The session ID can be fetched with 
      <seemfa marker="#connection_information/2">connection_information/2</seemfa>
      and used with the client option <seetype marker="#client_reuse_session">reuse_session</seetype>
      The boolean value true specifies that if possible, automated session reuse will
      be performed. If a new session is created, and is unique in regard 
      to previous stored sessions, it will be saved for possible later reuse. Since OTP-21.3.</p>
      </desc>
    </datatype>

    <datatype>
      <name name="client_certificate_authorities"/>
      <desc>
	<p>If set to true, sends the certificate authorities extension in TLS-1.3 client hello.
	The default is false. Note that setting it to true may result in a big overhead if you
	have many trusted CA certificates. 
	Since OTP-24.3.</p>
      </desc>
    </datatype>

    <datatype>
      <name name="client_cacerts"/>
      <desc>
	<p>The DER-encoded trusted certificates. If this option
      is supplied it overrides option <c>cacertfile</c>.</p>
      </desc>
    </datatype>
    
    <datatype>
      <name name="client_cafile"/>
      <desc>
	<p>Path to a file containing PEM-encoded CA certificates. The CA
        certificates are used during server authentication and when building the
        client certificate chain.</p>
        <note><p>When PEM caching is enabled, files provided with
        this option will be checked for updates at fixed time intervals specified by the
        <seeapp marker="ssl:ssl_app#configuration">ssl_pem_cache_clean</seeapp> environment parameter.</p>
        </note>
        <note><p>Alternatively, CA certificates can be provided as a DER-encoded
        binary with <seetype marker="#client_cacerts">client_cacerts</seetype>
        option.</p></note>
      </desc>
    </datatype>
    
    <datatype>
      <name name="client_alpn"/>
      <desc>
	<p>The list of protocols supported by the client to be sent to the
	server to be used for an Application-Layer Protocol Negotiation (ALPN).
	If the server supports ALPN then it will choose a protocol from this
	list; otherwise it will fail the connection with a "no_application_protocol"
	alert. A server that does not support ALPN will ignore this value.</p>
	
	<p>The list of protocols must not contain an empty binary.</p>
	
	<p>The negotiated protocol can be retrieved using the <c>negotiated_protocol/1</c> function.</p>
      </desc>
    </datatype>
    
   <datatype>
      <name name="client_preferred_next_protocols"/>
      <desc>
	<p>Indicates that the client is to try to perform Next Protocol
	Negotiation.</p>
	
	<p>If precedence is server, the negotiated protocol is the
	first protocol to be shown on the server advertised list, which is
	also on the client preference list.</p>
	
	<p>If precedence is client, the negotiated protocol is the
	first protocol to be shown on the client preference list, which is
	also on the server advertised list.</p>
	
	<p>If the client does not support any of the server advertised
	protocols or the server does not advertise any protocols, the
	client falls back to the first protocol in its list or to the
	default protocol (if a default is supplied). If the
	server does not support Next Protocol Negotiation, the
	connection terminates if no default protocol is supplied.</p>
      </desc>
   </datatype>
   
   <datatype>
      <name name="max_fragment_length"/>
      <desc>
	<p>Specifies the maximum fragment length the client
	is prepared to accept from the server.
	See <url href="http://www.ietf.org/rfc/rfc6066.txt">RFC 6066</url></p>
      </desc>
   </datatype>

   <datatype>
      <name name="client_psk_identity"/>
      <desc>
	<p>Specifies the identity the client presents to the server.
	The matching secret is found by calling <c>user_lookup_fun</c></p>
      </desc>
      </datatype>

      <datatype>
	<name name="client_srp_identity"/>
	<desc>
	  <p>Specifies the username and password to use to authenticate
	  to the server.</p>
	</desc>
      </datatype>

      <datatype>
      <name name="sni"/>
      <desc>
	<p>Specify the hostname to be used in TLS Server Name Indication extension.
	If not specified it will default to the <c>Host</c> argument of <seemfa marker="#connect/3">connect/[3,4]</seemfa>
	unless it is of type inet:ipaddress().</p>
	<p>
	  The <c>HostName</c> will also be used in the hostname verification of the peer certificate using
	  <seemfa marker="public_key:public_key#pkix_verify_hostname/2">public_key:pkix_verify_hostname/2</seemfa>.
	</p>
	<p> The special value <c>disable</c> prevents the Server Name Indication extension from being sent and
	disables the hostname verification check
	<seemfa marker="public_key:public_key#pkix_verify_hostname/2">public_key:pkix_verify_hostname/2</seemfa> </p>
      </desc>
      </datatype>
         
      <datatype>
	<name name="customize_hostname_check"/>
	<desc>
	  <p> Customizes the hostname verification of the peer certificate, as different protocols that use
	  TLS such as HTTP or LDAP may want to do it differently. For example the get standard HTTPS handling
	  provide the already implememnted fun from the public_key application for HTTPS.
	  <c>{customize_hostname_check,  [{match_fun, public_key:pkix_verify_hostname_match_fun(https)}]}</c>
	  For futher description of customize options see
	  <seemfa marker="public_key:public_key#pkix_verify_hostname/3">public_key:pkix_verify_hostname/3</seemfa> </p>
	</desc>
      </datatype>
      
      <datatype>
	<name name="fallback"/>
	<desc>
	  <p> Send special cipher suite TLS_FALLBACK_SCSV to avoid undesired TLS version downgrade.
	  Defaults to false</p>
	  <warning><p>Note this option is not needed in normal TLS usage and should not be used
	  to implement new clients. But legacy clients that retries connections in the following manner</p>
	  
	  <p><c> ssl:connect(Host, Port, [...{versions, ['tlsv2', 'tlsv1.1', 'tlsv1']}])</c></p>
	  <p><c>  ssl:connect(Host, Port, [...{versions, [tlsv1.1', 'tlsv1']}, {fallback, true}])</c></p>
	  <p><c>  ssl:connect(Host, Port, [...{versions, ['tlsv1']}, {fallback, true}]) </c></p>
	  
	  <p>may use it to avoid undesired TLS version downgrade. Note that TLS_FALLBACK_SCSV must also
	  be supported by the server for the prevention to work.
	  </p></warning>
	</desc>
      </datatype>


      <datatype>
	<name name="client_session_tickets"/>
	<desc>
	  <p>Configures the session ticket functionality. Allowed values are <c>disabled</c>,
	  <c>manual</c> and <c>auto</c>. If it is set to <c>manual</c> the client will send
	  the ticket information to user process in a 3-tuple:</p>
	  <p><c>{ssl, session_ticket, {SNI, TicketData}}</c></p>
	  <p>where <c>SNI</c> is the ServerNameIndication and <c>TicketData</c> is the extended
	  ticket data that can be used in subsequent session resumptions.</p>
	  <p>If it is set to <c>auto</c>, the client automatically handles received tickets and tries
	  to use them when making new TLS connections (session resumption with pre-shared keys).</p>
	  <note><p>This option is supported by TLS 1.3 and above. See also
	  <seeguide marker="ssl:using_ssl#session-tickets-and-session-resumption-in-tls-1.3">
	  SSL's Users Guide, Session Tickets and Session Resumption in TLS 1.3</seeguide>
	  </p></note>
	</desc>
      </datatype>

      <datatype>
	<name name="use_ticket"/>
	<desc>
	  <p>Configures the session tickets to be used for session resumption. It is a mandatory
	  option in <c>manual</c> mode (<c>session_tickets = manual</c>).</p>
	  <note><p>Session tickets are only sent to user if option <em>session_tickets</em> is set
	  to <c>manual</c></p>
	  <p>This option is supported by TLS 1.3 and above. See also
	  <seeguide marker="ssl:using_ssl#session-tickets-and-session-resumption-in-tls-1.3">
	  SSL's Users Guide, Session Tickets and Session Resumption in TLS 1.3</seeguide>
	  </p></note>
	</desc>
      </datatype>

      <datatype>
	<name name="client_early_data"/>
	<desc>
	  <p>Configures the early data to be sent by the client.</p>
	  <p>In order to be able to verify
          that the server has the intention to process the early data, the following 3-tuple is
	  sent to the user process:</p>
	  <p><c>{ssl, SslSocket, {early_data, Result}}</c></p>
	  <p>where <c>Result</c> is either <c>accepted</c> or <c>rejected</c>.</p>
	  <warning>
	  <p>It is the responsibility of the user to handle a rejected Early Data and
	  to resend when it is appropriate.</p></warning>
	</desc>
      </datatype>

      <datatype>
        <name name="use_srtp"/>
        <desc>
          <p>Configures the <c>use_srtp</c> DTLS hello extension.</p>
          <p>In order to negotiate the use of SRTP data protection, clients
          include an extension of type "use_srtp" in the DTLS extended client
          hello.  This extension MUST only be used when the data being
          transported is RTP or RTCP.</p>
          <p>The value is a map with a mandatory <c>protection_profiles</c> and
          an optional <c>mki</c> parameters.</p>
          <p><c>protection_profiles</c> configures the list of the client's acceptable
          SRTP Protection Profiles. Each profile is a 2-byte binary. Example:
          <c>#{protection_profiles =&gt; [&lt;&lt;0,2&gt;&gt;, &lt;&lt;0,5&gt;&gt;]}</c></p>
          <p><c>mki</c> configures the SRTP Master Key Identifier chosen by the client.</p>
          <p>The srtp_mki field contains the value of the SRTP MKI which is associated
          with the SRTP master keys derived from this handshake.  Each SRTP
          session MUST have exactly one master key that is used to protect
          packets at any given time.  The client MUST choose the MKI value so
          that it is distinct from the last MKI value that was used, and it
          SHOULD make these values unique for the duration of the TLS session.</p>
          <note><p>This extension MUST only be used with DTLS, and not with TLS.</p></note>
          <note><p>OTP does not handle SRTP, so an external implementations of SRTP
          encoder/decoder and a packet demultiplexer are needed to make use
          of the <c>use_srtp</c> extension. See also
          <seetype marker="#transport_option">cb_info</seetype> option.</p></note>
        </desc>
      </datatype>

    <!--   <datatype> -->
  <!-- 	<name name="ocsp_stapling"/> -->
  <!-- 	<desc><p>If true, OCSP stapling will be enabled, an extension of type "status_request" will be -->
  <!-- included in the client hello to indicate the desire to receive certificate status information. -->
  <!-- If false (the default), OCSP stapling will be disabled.</p> -->
  <!-- 	</desc> -->
  <!--     </datatype> -->

  <!--     <datatype> -->
  <!-- 	<name name="ocsp_responder_certs"/> -->
  <!-- 	<desc><p>This option is a list of DER encoded certificates of OCSP responders which the client -->
  <!-- trusts. This option is an empty list by default which means that the responders are implicitly -->
  <!-- known to the server.</p> -->
  <!-- 	</desc> -->
  <!--     </datatype> -->

  <!--     <datatype> -->
  <!-- 	<name name="ocsp_nonce"/> -->
  <!-- 	<desc><p>If true (the default), the nonce will be included as one of the request extensions in the -->
  <!-- request. If false, nonce will not present in the request extensions.</p> -->
  <!-- 	</desc> -->
  <!--     </datatype> -->

      <datatype_title>TLS/DTLS OPTION DESCRIPTIONS - SERVER</datatype_title>

      <datatype>
	<name name="server_option"/>
      </datatype>
     
      <datatype>
	<name name="server_cacerts"/>
	<desc><p>The DER-encoded trusted certificates. If this option
      is supplied it overrides option <c>cacertfile</c>.</p>
	</desc>
      </datatype>

  <datatype>
    <name since="OTP 25.2" name="server_certificate_authorities"/>
      <desc>
	<p>Determines if a TLS-1.3 server should include the authorities
	extension in its certificate request message that will be sent if the
	option <c>verify</c> is set to <c>verify_peer</c>. Defaults to <c>true</c>.</p>

	<p>A reason to exclude the extension would be if the server wants to communicate with clients
	incapable of sending complete certificate chains that adhere to the
	extension, but the server still has the capability to recreate a chain that it can verify.</p>

      </desc>

  </datatype>
            
      <datatype>
	<name name="server_cafile"/>
	<desc><p>Path to a file containing PEM-encoded CA
	certificates. The CA certificates are used to build the server
	certificate chain and for client authentication. The CAs are
	also used in the list of acceptable client CAs passed to the
	client when a certificate is requested. Can be omitted if
	there is no need to verify the client and if there are no
	intermediate CAs for the server certificate.</p>
        <note><p>When PEM caching is enabled, files provided with
        this option will be checked for updates at fixed time intervals specified by the
        <seeapp marker="ssl:ssl_app#configuration">ssl_pem_cache_clean</seeapp> environment parameter.</p>
        </note>
        <note><p>Alternatively, CA certificates can be provided as a DER-encoded
        binary with <seetype marker="#server_cacerts">server_cacerts</seetype> option.</p></note>
	</desc>
      </datatype>

      <datatype>
	<name name="dh_der"/>
	<desc><p>The DER-encoded Diffie-Hellman parameters. If
	specified, it overrides option <c>dhfile</c>.</p>
	<warning><p>The <c>dh_der</c> option is not supported by TLS 1.3. Use the
	<c>supported_groups</c> option instead.</p></warning>
	</desc>
      </datatype>
    
      <datatype>
	<name name="dh_file"/>
	<desc><p>Path to a file containing PEM-encoded Diffie Hellman
	parameters to be used by the server if a cipher suite using
	Diffie Hellman key exchange is negotiated. If not specified,
	default parameters are used.</p>
	<warning><p>The <c>dh_file</c> option is not supported by TLS 1.3. Use the
	<c>supported_groups</c> option instead.</p></warning>
	</desc>
      </datatype>

    <datatype>
	<name name="server_verify_type"/>
	<desc><p> Client certificates are an optional part of the TLS protocol.
	A server only does x509-certificate path validation in mode
	<c>verify_peer</c>. By default the server is in <c>verify_none</c> mode
	an hence will not send an certificate request to the client.
	When using <c>verify_peer</c> you may also want to specify the options
	<seetype marker="#fail_if_no_peer_cert">fail_if_no_peer_cert</seetype> and
  <seetype marker="#server_certificate_authorities">certificate_authorities</seetype>.</p>
      </desc>
      </datatype>

      <datatype>
	<name name="fail_if_no_peer_cert"/>
	<desc><p>Used together with <c>{verify, verify_peer}</c> by an
	TLS/DTLS server.  If set to <c>true</c>, the server fails if
	the client does not have a certificate to send, that is, sends
	an empty certificate. If set to <c>false</c>, it fails only if
	the client sends an invalid certificate (an empty certificate
	is considered valid). Defaults to false.</p>
	</desc>
      </datatype>
      
      <datatype>
	<name name="server_reuse_sessions"/>
	<desc><p>The boolean value true specifies that the server will
	agree to reuse sessions. Setting it to false will result in an empty
	session table, that is no sessions will be reused. 
	See also option <seetype marker="#server_reuse_session">reuse_session</seetype>.
      </p>
	</desc>
      </datatype>
      
      <datatype>
	<name name="server_reuse_session"/>
	<desc><p>Enables the TLS/DTLS server to have a local policy
	for deciding if a session is to be reused or not.  Meaningful
	only if <c>reuse_sessions</c> is set to <c>true</c>.
	<c>SuggestedSessionId</c> is a <c>binary()</c>,
	<c>PeerCert</c> is a DER-encoded certificate,
	<c>Compression</c> is an enumeration integer, and
	<c>CipherSuite</c> is of type <c>ciphersuite()</c>.</p>
	</desc>
      </datatype>

      <datatype>
	<name name="server_alpn"/>
	<desc>  
	  <p>Indicates the server will try to perform
	  Application-Layer Protocol Negotiation (ALPN).</p>
	  
	  <p>The list of protocols is in order of preference. The
	  protocol negotiated will be the first in the list that
	  matches one of the protocols advertised by the client. If no
	  protocol matches, the server will fail the connection with a
	  "no_application_protocol" alert.</p>
	  
	  <p>The negotiated protocol can be retrieved using the
	  <c>negotiated_protocol/1</c> function.</p>
	</desc>
      </datatype>
      
      <datatype>
	<name name="server_next_protocol"/>
	<desc><p>List of protocols to send to the client if the client
	indicates that it supports the Next Protocol extension. The
	client can select a protocol that is not on this list. The
	list of protocols must not contain an empty binary. If the
	server negotiates a Next Protocol, it can be accessed using
	the <c>negotiated_next_protocol/1</c> method.</p>
	</desc>
      </datatype>

      <datatype>
	<name name="server_psk_identity"/>
	<desc>
	  <p>Specifies the server identity hint, which the server presents to
	  the client.</p>
	</desc>
      </datatype>

      <datatype>
	<name name="honor_cipher_order"/>
	<desc>
	  <p>If set to <c>true</c>, use the server preference for cipher
	  selection. If set to <c>false</c> (the default), use the client
	  preference.</p>
	</desc>
      </datatype>

      <datatype>
	<name name="sni_hosts"/>
	<desc><p>If the server receives a SNI (Server Name Indication) from the client
	matching a host listed in the <c>sni_hosts</c> option, the specific options for
	that host will override previously specified options.
	
	The option <c>sni_fun</c>, and <c>sni_hosts</c> are mutually exclusive.</p>
	</desc>
      </datatype>

      <datatype>
	<name name="sni_fun"/>
	<desc>
	  <p>If the server receives a SNI (Server Name Indication)
	  from the client, the given function will be called to
	  retrieve <seetype marker="#server_option">[server_option()] </seetype> for the indicated server.
	  These options will be merged into predefined
	  <seetype marker="#server_option">[server_option()] </seetype> list.
	  
	  The function should be defined as:
          fun(ServerName :: string()) -> <seetype marker="#server_option">[server_option()] </seetype>
	  and can be specified as a fun or as named <c>fun module:function/1</c>
	  
	  The option <c>sni_fun</c>, and <c>sni_hosts</c> are mutually exclusive.</p>
	</desc>
      </datatype>

      <datatype>
	<name name="client_renegotiation"/>
	<desc><p>In protocols that support client-initiated
	renegotiation, the cost of resources of such an operation is
	higher for the server than the client. This can act as a
	vector for denial of service attacks. The SSL application
	already takes measures to counter-act such attempts, but
	client-initiated renegotiation can be strictly disabled by
	setting this option to <c>false</c>. The default value is
	<c>true</c>.  Note that disabling renegotiation can result in
	long-lived connections becoming unusable due to limits on the
	number of messages the underlying cipher suite can
	encipher.</p>
	</desc>
      </datatype>
      
      <datatype>
	<name name="honor_cipher_order"/>
	<desc><p>If true, use the server's preference for cipher
	selection. If false (the default), use the client's
	preference.</p>
	</desc>
      </datatype>

      <datatype>
	<name name="honor_ecc_order"/>
	<desc><p>If true, use the server's preference for ECC curve
	selection. If false (the default), use the client's
	preference.</p>
	</desc>
      </datatype>

      <datatype>
	<name name="server_session_tickets"/>
	<desc>
          <p>Configures the session ticket functionality. Allowed values are <c>disabled</c>,
          <c>stateful</c>, <c>stateless</c>, <c>stateful_with_cert</c>, <c>stateless_with_cert</c>.</p>
          <p>If it is not set to <c>disabled</c>,
          session resumption with pre-shared keys is enabled and the server will
          send stateful or stateless session tickets to the client after successful connections.</p>
          
          <note><p>
          Pre-shared key session ticket resumption does not include any certificate exchange, 
          hence the function <seemfa marker="ssl:ssl#peercert/1">ssl:peercert/1</seemfa> will not 
          be able to return the peer certificate as it is only communicated in the initial handshake.
          The server options <c>stateful_with_cert</c> or <c>stateless_with_cert</c> may be used 
          to make a server associate the client certificate from the original handshake 
          with the tickets it issues.
          </p></note>

	  <p>A stateful session ticket is a database reference to internal state information.
	  A stateless session ticket is a self-encrypted binary that contains both cryptographic keying
	  material and state data.
	  </p>
          
          <warning><p>
          If it is set to <c>stateful_with_cert</c> the client certificate
          is stored with the internal state information, increasing memory consumption.
          If it is set to <c>stateless_with_cert</c> the client certificate is
          encoded in the self-encrypted binary that is sent to the client,
          increasing the payload size.
          </p></warning>

	  <note><p>This option is supported by TLS 1.3 and above. See also
	  <seeguide marker="ssl:using_ssl#session-tickets-and-session-resumption-in-tls-1.3">
	  SSL's Users Guide, Session Tickets and Session Resumption in TLS 1.3</seeguide>
	  </p></note>
	</desc>
      </datatype>

      <datatype>
        <name name="stateless_tickets_seed"/>
        <desc>
          <p>Configures the seed used for the encryption of stateless session tickets.
          Allowed values are any randomly generated <c>binary()</c>. If this option is not
          configured, an encryption seed will be randomly generated.</p>

          <warning><p>Reusing the ticket encryption seed between multiple server
          instances enables stateless session tickets to work across multiple server
          instances, but it breaks anti-replay protection across instances.</p>

          <p>Inaccurate time synchronization between server instances can also
          affect session ticket freshness checks, potentially causing false negatives as
          well as false positives.</p></warning>

          <note><p>This option is supported by TLS 1.3 and above and only with stateless
          session tickets.</p></note>
        </desc>
      </datatype>

      <datatype>
	<name name="anti_replay"/>
	<desc>
	  <p>Configures the server's built-in anti replay feature based on Bloom filters.</p>

	  <p>Allowed values are the pre-defined <c>'10k'</c>, <c>'100k'</c> or a custom 3-tuple that
	  defines the properties of the bloom filters: <c>{WindowSize, HashFunctions, Bits}</c>.
	  <c>WindowSize</c> is the number of seconds after the current Bloom filter is rotated
	  and also the window size used for freshness checks of ClientHello. <c>HashFunctions</c> is the number
	  hash functions and <c>Bits</c> is the number of bits in the bit vector.
	  <c>'10k'</c> and <c>'100k'</c> are simple defaults with the following properties:</p>
	  <list type="bulleted">
	    <item><p><c>'10k'</c>: Bloom filters can hold 10000 elements with 3% probability of
	    false positives. <c>WindowSize</c>: 10, <c>HashFunctions</c>: 5, <c>Bits:</c>
	    72985 (8.91 KiB).</p></item>
	    <item><p><c>'100k'</c>: Bloom filters can hold 100000 elements with 3% probability of
	    false positives. <c>WindowSize</c>: 10, <c>HashFunctions</c>: 5, <c>Bits</c>:
	    729845 (89.09 KiB).</p></item>
	  </list>

	  <note><p>This option is supported by TLS 1.3 and above and only with stateless session tickets.
	  Ticket lifetime, the number of tickets sent by the server and the maximum number of tickets
	  stored by the server in stateful mode are configured by
	  <seeapp marker="ssl:ssl_app#configuration">application variables</seeapp>. See also
	  <seeguide marker="ssl:using_ssl#anti-replay-protection-in-tls-1.3">
	  SSL's Users Guide, Anti-Replay Protection in TLS 1.3</seeguide>
	  </p></note>
	</desc>
      </datatype>

      <datatype>
	<name name="cookie"/>
	<desc><p>If <c>true</c> (default), the server sends a cookie extension in its
	HelloRetryRequest messages.</p>
	<note><p>The cookie extension has two main purposes. It allows the server to
	force the client to demonstrate reachability at their apparent network
	address (thus providing a measure of DoS protection).  This is primarily
	useful for non-connection-oriented transports. It also allows to offload the
	server's state to the client.
	The cookie extension is enabled by default as it is a mandatory extension
	in RFC8446.</p></note>
	</desc>
      </datatype>

      <datatype>
        <name name="server_early_data"/>
	<desc>
          <p>Configures if the server accepts (<c>enabled</c>) or rejects (<c>rejects</c>) early
	  data sent by a client. The default value is <c>disabled</c>.
          </p>
	  <warning><p>This option is a placeholder, early data is not yet implemented on the server side.
          </p></warning>
        </desc>
      </datatype>

      <datatype>
        <name name="use_srtp"/>
        <desc>
          <p>Configures the <c>use_srtp</c> DTLS hello extension.</p>
          <p>Servers that receive an extended hello containing a "use_srtp"
          extension can agree to use SRTP by including an extension of type
          "use_srtp", with the chosen protection profile in the extended server
          hello. This extension MUST only be used when the data being
          transported is RTP or RTCP.</p>
          <p>The value is a map with a mandatory <c>protection_profiles</c> and
          an optional <c>mki</c> parameters.</p>
	  <list type="bulleted">
            <item><p><c>protection_profiles</c> configures the list of the server's chosen
            SRTP Protection Profile as a list of a single 2-byte binary. Example:
            <c>#{protection_profiles =&gt; [&lt;&lt;0,5&gt;&gt;]}</c></p></item>
            <item><p><c>mki</c> configures the server's SRTP Master Key Identifier.</p>
            <p>Upon receipt of a "use_srtp" extension containing a "srtp_mki" field,
            the server MUST either (assuming it accepts the extension at all):</p>
	    <list type="bulleted">
	      <item><p>include a matching "srtp_mki" value in its "use_srtp" extension
              to indicate that it will make use of the MKI, or</p></item>
              <item><p>return an empty "srtp_mki" value to indicate that it cannot
              make use of the MKI (default).</p></item>
	    </list>
            </item>
          </list>
          <note><p>This extension MUST only be used with DTLS, and not with TLS.</p></note>
          <note><p>OTP does not handle SRTP, so an external implementations of SRTP
          encoder/decoder and a packet demultiplexer are needed to make use
          of the <c>use_srtp</c> extension. See also
          <seetype marker="#transport_option">cb_info</seetype> option.</p></note>
        </desc>
      </datatype>

      <datatype>
        <name name="connection_info"/>
      </datatype>

      <datatype>
        <name name="common_info"/>
      </datatype>

      <datatype>
        <name name="curve_info"/>
      </datatype>

      <datatype>
        <name name="ssl_options_info"/>
      </datatype>

      <datatype>
        <name name="security_info"/>
      </datatype>

      <datatype>
        <name name="connection_info_items"/>
      </datatype>

      <datatype>
        <name name="connection_info_item"/>
      </datatype>

      <datatype>
        <name name="tls_options_name"/>
      </datatype>

    </datatypes>

<!--
    ================================================================
    =  Function definitions                                        =
    ================================================================
-->

  <funcs>

    <func>
      <name name="append_cipher_suites" arity="2" since="OTP 20.3"/>
      <fsummary></fsummary>
      <desc><p>Make <c>Deferred</c> suites become the least preferred
      suites, that is put them at the end of the cipher suite list
      <c>Suites</c> after removing them from <c>Suites</c> if
      present. <c>Deferred</c> may be a list of cipher suites or a
      list of filters in which case the filters are use on  <c>Suites</c> to
      extract the Deferred cipher list.</p> 
      </desc>
    </func>
      
   <func>
      <name name="cipher_suites" arity="2" since="OTP 20.3"/>
      <fsummary>Returns a list of cipher suites.</fsummary>
      <desc><p>Lists all possible cipher suites corresponding to
      <c>Description</c> that are available. The 
      <c>exclusive</c> and <c>exclusive_anonymous</c> option will exclusively list cipher suites
      first supported in <c>Version</c> whereas the other options
      are inclusive from the lowest possible version to 
      <c>Version</c>. The <c>all</c> options includes all suites
      except the anonymous and no anonymous suites are supported by default.
    </p>

    <note><p>TLS-1.3 has no overlapping cipher suites with previous
    TLS versions, that is the result of
    <c>cipher_suites(all, 'tlsv1.3').</c> contains a separate set of
    suites that can be used with TLS-1.3 an other set that can be used
    if a lower version is negotiated. PRE TLS-1.3 so called <c>PSK</c> and <c>SRP</c> suites
    need extra configuration to work see <seetype marker="#custom_user_lookup">user lookup function</seetype>.
    No anonymous suites are supported by TLS-1.3.</p>

    <p>Also note that the cipher suites returned
    by this function are the cipher suites that the OTP ssl
    application can support provided that they are supported by the
    cryptolib linked with the OTP crypto application. Use <seemfa
    marker="#filter_cipher_suites/2"> ssl:filter_cipher_suites(Suites,
    []).</seemfa> to filter the list for the current cryptolib. Note
    that cipher suites may be filtered out because they are too old or
    too new depending on the cryptolib</p></note>

    </desc>
    </func>

    <func>
      <name name="cipher_suites" arity="3" since="OTP 22.0"/>
      <fsummary>Returns a list of RFC or OpenSSL names</fsummary>
      <desc><p>Same as <seemfa marker="#cipher_suites/2">cipher_suites/2</seemfa>
      but lists RFC or OpenSSL string names instead of <seetype marker="#erl_cipher_suite">erl_cipher_suite()</seetype>
    </p>
    </desc>
    </func>
    
    <func>
      <name name="eccs" arity="0" since="OTP 19.2"/>
      <name name="eccs" arity="1" since="OTP 19.2"/>
      <fsummary>Returns a list of supported ECCs.</fsummary>
      <desc><p>Returns a list of supported ECCs. <c>eccs()</c>
      is equivalent to calling <c>eccs(Protocol)</c> with all
      supported protocols and then deduplicating the output.</p>
      </desc>
    </func>
    
    <func>
      <name name="clear_pem_cache" arity="0" since="OTP 17.5"/>
      <fsummary>Clears the pem cache</fsummary>
      <desc>
        <p>PEM files, used by ssl API-functions, are cached for
          performance reasons. The cache is automatically checked at
          regular intervals to see if any cache entries should be invalidated.</p>
        <p>This function provides a way to unconditionally clear the entire
          cache, thereby forcing a reload of previously cached PEM files.</p>
      </desc>
    </func>
   
    <func>
      <name name="connect" arity="2" since="OTP R14B"/>
      <name name="connect" arity="3" clause_i="1" since=""/>
      <fsummary>Upgrades a <c>gen_tcp</c>, or
	equivalent, connected socket to a TLS socket.</fsummary>
      <desc><p>Upgrades a <c>gen_tcp</c>, or equivalent,
	  connected socket to a TLS socket, that is, performs the
	  client-side TLS handshake.</p>
	  
	  <note><p>If the option <c>verify</c> is set to
	  <c>verify_peer</c> the option <c>server_name_indication</c>
	  shall also be specified, if it is not no Server Name
	  Indication extension will be sent, and <seemfa
	  marker="public_key:public_key#pkix_verify_hostname/2">public_key:pkix_verify_hostname/2</seemfa>
	  will be called with the IP-address of the connection as
	  <c>ReferenceID</c>, which is probably not what you want.</p>
	  </note>

	  <p> If the option <c>{handshake, hello}</c> is used the
	  handshake is paused after receiving the server hello message
	  and the success response is <c>{ok, SslSocket, Ext}</c>
	  instead of <c>{ok, SslSocket}</c>. Thereafter the handshake
	  is continued or canceled by calling <seemfa
	  marker="#handshake_continue/3">
	  <c>handshake_continue/3</c></seemfa> or <seemfa
	  marker="#handshake_cancel/1"><c>handshake_cancel/1</c></seemfa>.
	  </p>
	  
	  <p> If the option <c>active</c> is set to <c>once</c>, <c>true</c> or an integer value,
	  the process owning the sslsocket will receive messages of type 
	  <seetype marker="#active_msgs"> active_msgs() </seetype>
	  </p>
    </desc>
    </func>

    <func>
      <name since="" name="connect" arity="3" clause_i="2"/>
      <name since="" name="connect" arity="4"/>
      <fsummary>Opens a TLS/DTLS connection to <c>Host</c>, <c>Port</c>.</fsummary>
      <desc><p>Opens a TLS/DTLS connection to <c>Host</c>, <c>Port</c>.</p>
      
      <p> When the option <c>verify</c> is set to <c>verify_peer</c> the check 
      <seemfa marker="public_key:public_key#pkix_verify_hostname/2">public_key:pkix_verify_hostname/2</seemfa> 
      will be performed in addition to the usual x509-path validation checks. If the check fails the error {bad_cert, hostname_check_failed} will
      be propagated to the path validation fun <seetype marker="#custom_verify">verify_fun</seetype>, where it is possible to do customized
      checks by using the full possibilities of the <seemfa marker="public_key:public_key#pkix_verify_hostname/3">public_key:pkix_verify_hostname/3</seemfa> API.
      
      When the option <c>server_name_indication</c> is provided, its value (the DNS name) will be used as <c>ReferenceID</c>
      to <seemfa marker="public_key:public_key#pkix_verify_hostname/2">public_key:pkix_verify_hostname/2</seemfa>.
      When no <c>server_name_indication</c> option is given, the <c>Host</c> argument will be used as
      Server Name Indication extension. The <c>Host</c> argument will also be used for the
      <seemfa marker="public_key:public_key#pkix_verify_hostname/2">public_key:pkix_verify_hostname/2</seemfa> check and if the <c>Host</c>
      argument is an <c>inet:ip_address()</c> the <c>ReferenceID</c> used for the check will be <c>{ip, Host}</c> otherwise
      <c>dns_id</c> will be assumed with a fallback to <c>ip</c> if that fails. </p>
      <note><p>According to good practices certificates should not use IP-addresses as "server names". It would
      be very surprising if this happened outside a closed network. </p></note>


      <p> If the option <c>{handshake, hello}</c> is used the
	  handshake is paused after receiving the server hello message
	  and the success response is <c>{ok, SslSocket, Ext}</c>
	  instead of <c>{ok, SslSocket}</c>. Thereafter the handshake is continued or
	  canceled by calling <seemfa marker="#handshake_continue/3">
	  <c>handshake_continue/3</c></seemfa> or <seemfa
	  marker="#handshake_cancel/1"><c>handshake_cancel/1</c></seemfa>.
	  </p>

	  <p> If the option <c>active</c> is set to <c>once</c>, <c>true</c> or an integer value,
	  the process owning the sslsocket will receive messages of type 
	  <seetype marker="#active_msgs"> active_msgs() </seetype>
	  </p>
      </desc>
    </func>

    <func>
      <name since="" name="close" arity="1" />
      <fsummary>Closes a TLS/DTLS connection.</fsummary>
      <desc><p>Closes a TLS/DTLS connection.</p>
      </desc>
    </func>

    <func>
      <name since="OTP 18.1" name="close" arity="2"/>
      <fsummary>Closes a TLS connection.</fsummary>
      <desc><p>Closes or downgrades a TLS connection. In the latter case the transport
      connection will be handed over to the <c>NewController</c> process after receiving
      the TLS close alert from the peer. The returned transport socket will have
      the following options set: <c>[{active, false}, {packet, 0}, {mode, binary}]</c>.</p>
      <p>In case of downgrade, the close function might return some binary data
      that should be treated by the user as the first bytes received on the downgraded
      connection.</p>
      </desc>
    </func>
    
    <func>
      <name since="" name="controlling_process" arity="2" />
	<fsummary>Assigns a new controlling process to the
	TLS/DTLS socket.</fsummary>
	<desc><p>Assigns a new controlling process to the SSL socket. A
	controlling process is the owner of an SSL socket, and receives
	all messages from the socket.</p>
      </desc>
    </func>

    <func>
      <name since="OTP 18.0" name="connection_information" arity="1"/>
      <fsummary>Returns all the connection information.
      </fsummary>
      <desc><p>Returns the most relevant information about the connection, ssl options that
      are undefined will be filtered out. Note that values that affect the security of the
      connection will only be returned if explicitly requested by connection_information/2.</p>
      <note><p>The legacy <c>Item = cipher_suite</c> was removed in OTP-23.
      Previously it returned the cipher suite on its (undocumented)
      legacy format. It is replaced by <c>selected_cipher_suite</c>.</p></note>
      </desc>
    </func>

    <func>
      <name since="OTP 18.0" name="connection_information" arity="2"/>
      <fsummary>Returns the requested connection information.
      </fsummary>
      <desc><p>Returns the requested information items about the connection,
      if they are defined.</p>
      <p>Note that client_random, server_random, master_secret and keylog are values
      that affect the security of connection. Meaningful atoms, not specified
      above, are the ssl option names.</p>

      <p>In order to retrieve keylog and other secret information from a TLS 1.3
      connection, <seetype marker="#keep_secrets">keep_secrets</seetype> must be
      configured in advance and set to <c>true</c>.</p>

      <note><p>If only undefined options are requested the
      resulting list can be empty.</p></note>
      </desc>
    </func>

      <func>
      <name since="OTP 20.3" name="filter_cipher_suites" arity="2" />
      <fsummary></fsummary>
      <desc><p>Removes cipher suites if any of the filter functions
      returns false for any part of the cipher suite. If no filter function is supplied for some
      part the default behaviour regards it as if there was a filter function that returned true.
      
      For examples see <seeguide marker="ssl:using_ssl#customizing-cipher-suites"> Customizing cipher suites </seeguide> 
      
      Additionally, this function also filters the cipher suites to
      exclude cipher suites not supported by the cryptolib used by the
      OTP crypto application. That is calling
      ssl:filter_cipher_suites(Suites, []) will be equivalent to only
      applying the filters for cryptolib support.
    </p>
    </desc>
    </func>
    
    <func>
      <name since="" name="format_error" arity="1" />
      <fsummary>Returns an error string.</fsummary>
      <desc>
        <p>Presents the error returned by an SSL function as a printable string.</p>
      </desc>
    </func>
   
    <func>
      <name since="" name="getopts" arity="2" />
      <fsummary>Gets the values of the specified options.</fsummary>
      <desc>
	<p>Gets the values of the specified socket options.
	</p>
      </desc>
    </func>

    <func>
      <name since="OTP 19.0" name="getstat" arity="1" />
      <name since="OTP 19.0" name="getstat" arity="2" />
      <fsummary>Get one or more statistic options for a socket</fsummary>
      <desc>
        <p>Gets one or more statistic options for the underlying TCP socket.</p>
        <p>See inet:getstat/2 for statistic options description.</p>
      </desc>
    </func>

    <func>
      <name since="OTP 21.0" name="handshake" arity="1" />
      <name since="OTP 21.0" name="handshake" arity="2" clause_i="1" />
      <fsummary>Performs server-side TLS handshake.</fsummary>
      <desc>
        <p>Performs the TLS/DTLS server-side handshake.</p>
	<p>Returns a new TLS/DTLS socket if the handshake is successful.</p>

	<p> If the option <c>active</c> is set to <c>once</c>, <c>true</c> or an integer value,
	the process owning the sslsocket will receive messages of type 
	<seetype marker="#active_msgs"> active_msgs() </seetype>
	</p>	

	<warning><p>Not setting the timeout makes the server more vulnerable to
	DoS attacks.
	</p></warning>
	
      </desc>
    </func>

    <func>
      <name since="OTP 21.0" name="handshake" arity="2" clause_i="2" />
      <name since="OTP 21.0" name="handshake" arity="3" />
      <fsummary>Performs server-side TLS/DTLS handshake.</fsummary>
      <desc>
        <p>If <c>Socket</c> is a ordinary <c>socket()</c>: upgrades a <c>gen_tcp</c>,
	or equivalent, socket to an SSL socket, that is, performs
        the TLS server-side handshake and returns a TLS socket.</p>

	<warning><p>The ordinary <c>Socket</c> shall be in passive mode ({active,
	false}) before calling this function, and before the client tries
	to connect with TLS, or else the behavior of this function
	is undefined. The best way to ensure this is to create the ordinary listen socket
	in passive mode.
	</p></warning>

	<p>If <c>Socket</c> is an 
	<seetype marker="#sslsocket"> sslsocket() </seetype>: provides extra TLS/DTLS
	options to those specified in
	<seemfa marker="#listen/2">listen/2</seemfa> and then performs
	the TLS/DTLS handshake. Returns a new TLS/DTLS socket if the handshake is successful.</p>

	<warning><p>Not setting the timeout makes the server more vulnerable to
	DoS attacks.
	</p></warning>
	
	<p>
	  If option <c>{handshake, hello}</c> is specified the handshake is
	  paused after receiving the client hello message and the
	  success response is <c>{ok, SslSocket, Ext}</c>  instead of <c>{ok,
	  SslSocket}</c>. Thereafter the handshake is continued or
	  canceled by calling <seemfa marker="#handshake_continue/3">
	  <c>handshake_continue/3</c></seemfa> or <seemfa
	  marker="#handshake_cancel/1"><c>handshake_cancel/1</c></seemfa>.
	</p>
	
	<p> If the option <c>active</c> is set to <c>once</c>, <c>true</c> or an integer value,
	the process owning the sslsocket will receive messages of type 
	<seetype marker="#active_msgs"> active_msgs() </seetype>
	</p>
	
      </desc>
    </func>

    <func>
      <name since="OTP 21.0" name="handshake_cancel" arity="1" />
      <fsummary>Cancel handshake with a fatal alert</fsummary>
      <desc>
        <p>Cancel the handshake with a fatal <c>USER_CANCELED</c> alert.</p>
      </desc>
    </func>

    <func>
      <name since="OTP 21.0" name="handshake_continue" arity="2" />
      <name since="OTP 21.0" name="handshake_continue" arity="3" />
      <fsummary>Continue the TLS handshake.</fsummary>
      <desc>
        <p>Continue the TLS handshake, possibly with new, additional or changed options.</p>
      </desc>
    </func>
    
    <func>
      <name since="" name="listen" arity="2" />
      <fsummary>Creates an SSL listen socket.</fsummary>
      <desc>
	<p>Creates an SSL listen socket.</p>
      </desc>
    </func>

    <func>
      <name since="OTP 18.0" name="negotiated_protocol" arity="1" />
      <fsummary>Returns the protocol negotiated through ALPN or NPN extensions.</fsummary>
      <desc>
        <p>
          Returns the protocol negotiated through ALPN or NPN extensions.
        </p>
      </desc>
    </func>
    
    <func>
      <name since="" name="peercert" arity="1" />
      <fsummary>Returns the peer certificate.</fsummary>
      <desc>
        <p>The peer certificate is returned as a DER-encoded binary.
	  The certificate can be decoded with
	  <seemfa marker="public_key:public_key#pkix_decode_cert/2">public_key:pkix_decode_cert/2</seemfa>

	  Suggested further reading about certificates 
	  is <seeguide marker="public_key:public_key_records">public_key
	  User's Guide</seeguide> and <seeguide marker="ssl:standards_compliance">ssl
	  User's Guide</seeguide>
	</p>
      </desc>
    </func>

    <func>
      <name since="" name="peername" arity="1" />
      <fsummary>Returns the peer address and port.</fsummary>
      <desc>
        <p>Returns the address and port number of the peer.</p>
      </desc>
    </func>
    
      <func>
      <name since="OTP 20.3" name="prepend_cipher_suites" arity="2" />
      <fsummary></fsummary>
      <desc><p>Make <c>Preferred</c> suites become the most preferred
      suites that is put them at the head of the cipher suite list
      <c>Suites</c> after removing them from <c>Suites</c> if
      present. <c>Preferred</c> may be a list of cipher suites or a
      list of filters in which case the filters are use on <c>Suites</c> to
      extract the preferred cipher list. </p>
      </desc>
    </func>

    <func>
      <name since="OTP R15B01" name="prf" arity="5" />
      <fsummary>Uses a session Pseudo-Random Function to generate key material.</fsummary>
      <desc>
        <p>Uses the Pseudo-Random Function (PRF) of a TLS session to generate
	  extra key material. It either takes user-generated values for
	  <c>Secret</c> and <c>Seed</c> or atoms directing it to use a specific
	  value from the session security parameters.</p>
      </desc>
    </func>
    
    <func>
      <name since="" name="recv" arity="2" />
      <name since="" name="recv" arity="3" />
      <fsummary>Receives data on a socket.</fsummary>
      <type_desc variable="HttpPacket">See the description of
        <c>HttpPacket</c> in
        <seemfa marker="erts:erlang#decode_packet/3"><c>erlang:decode_packet/3</c></seemfa>
	in ERTS.
      </type_desc>
      <desc>
        <p>Receives a packet from a socket in passive
          mode. A closed socket is indicated by return value
          <c>{error, closed}</c>.</p>
        <p>Argument <c>Length</c> is meaningful only when
          the socket is in mode <c>raw</c> and denotes the number of
          bytes to read. If <c>Length</c> = 0, all available bytes are
          returned. If <c>Length</c> &gt; 0, exactly <c>Length</c>
          bytes are returned, or an error; possibly discarding less
          than <c>Length</c> bytes of data when the socket gets closed
          from the other side.</p>
        <p>Optional argument <c>Timeout</c> specifies a time-out in
          milliseconds. The default value is <c>infinity</c>.</p>
      </desc>
    </func>
    
    <func>
      <name since="OTP R14B" name="renegotiate" arity="1" />
      <fsummary>Initiates a new handshake.</fsummary>
      <desc><p>Initiates a new handshake. A notable return value is
      <c>{error, renegotiation_rejected}</c> indicating that the peer
      refused to go through with the renegotiation, but the connection
      is still active using the previously negotiated session.</p>
      <p>TLS-1.3 has removed the renegotiate feature of earlier TLS versions
      and instead adds a new feature called key update that replaces the most
      important part of renegotiate, that is the refreshing of session keys.
      This is triggered automatically after reaching a plaintext limit and
      can be configured by option <seetype marker="ssl:ssl#key_update_at">key_update_at</seetype>.
      </p>
      </desc>
    </func>

    <func>
      <name since="OTP 22.3" name="update_keys" arity="2" />
      <fsummary>Initiates a key update.</fsummary>
      <desc><p>There are cryptographic limits on the amount of plaintext which can be safely
      encrypted under a given set of keys. If the amount of data surpasses those limits, a key
      update is triggered and a new set of keys are installed.
      See also the option <seetype marker="ssl:ssl#key_update_at">key_update_at</seetype>.</p>
      <p>This function can be used to explicitly start a key update on a TLS 1.3 connection.
      There are two types of the key update: if <em>Type</em> is set to <em>write</em>, only the writing
      key is updated; if <em>Type</em> is set to <em>read_write</em>, both the reading and writing keys
      are updated.</p>
      </desc>
    </func>

    <func>
      <name since="" name="send" arity="2" />
      <fsummary>Writes data to a socket.</fsummary>
      <desc>
        <p>Writes <c>Data</c> to <c>SslSocket</c>.</p>
        <p>A notable return value is <c>{error, closed}</c> indicating that
          the socket is closed.</p>
      </desc>
    </func>

    <func>
      <name since="" name="setopts" arity="2" />
      <fsummary>Sets socket options.</fsummary>
      <desc>
        <p>Sets options according to <c>Options</c> for socket
          <c>SslSocket</c>.</p>
      </desc>
    </func>

    <func>
      <name since="OTP R14B" name="shutdown" arity="2" />
      <fsummary>Immediately closes a socket.</fsummary>
      <desc>
        <p>Immediately closes a socket in one or two directions.</p>
        <p><c>How == write</c> means closing the socket for writing,
          reading from it is still possible.</p>
        <p>To be able to handle that the peer has done a shutdown on
          the write side, option <c>{exit_on_close, false}</c>
          is useful.</p>
      </desc>
    </func>

    <func>
      <name since="OTP @OTP-18572@" name="signature_algs" arity="2" />
      <fsummary>Returns a list of signature algorithms/schemes </fsummary>
      <desc>
        <p>Lists all possible signature algorithms corresponding to
        <c>Description</c> that are available. The
        <c>exclusive</c> option will exclusively list
        algorithms/schemes for that protocol version, whereas the
        <c>default</c> and <c>all</c> options lists the combined list to support the
        range of protocols from (D)TLS-1.2, the first version to support
        configuration of the signature algorithms, to <c>Version</c>.</p>

      <p> Example: <c>

      1&gt; ssl:signature_algs(default, 'tlsv1.3').
      [eddsa_ed25519,eddsa_ed448,ecdsa_secp521r1_sha512,
      ecdsa_secp384r1_sha384,ecdsa_secp256r1_sha256,
      rsa_pss_pss_sha512,rsa_pss_pss_sha384,rsa_pss_pss_sha256,
      rsa_pss_rsae_sha512,rsa_pss_rsae_sha384,rsa_pss_rsae_sha256,
      rsa_pkcs1_sha512,rsa_pkcs1_sha384,rsa_pkcs1_sha256,
      {sha512,ecdsa},
      {sha384,ecdsa},
      {sha256,ecdsa}]

      2&gt;ssl:signature_algs(all, 'tlsv1.3').
      [eddsa_ed25519,eddsa_ed448,ecdsa_secp521r1_sha512,
      ecdsa_secp384r1_sha384,ecdsa_secp256r1_sha256,
      rsa_pss_pss_sha512,rsa_pss_pss_sha384,rsa_pss_pss_sha256,
      rsa_pss_rsae_sha512,rsa_pss_rsae_sha384,rsa_pss_rsae_sha256,
      rsa_pkcs1_sha512,rsa_pkcs1_sha384,rsa_pkcs1_sha256,
      {sha512,ecdsa},
      {sha384,ecdsa},
      {sha256,ecdsa},
      {sha224,ecdsa},
      {sha224,rsa},
      {sha,rsa},
      {sha,dsa}]

      3&gt; ssl:signature_algs(exclusive, 'tlsv1.3').
      [eddsa_ed25519,eddsa_ed448,ecdsa_secp521r1_sha512,
      ecdsa_secp384r1_sha384,ecdsa_secp256r1_sha256,
      rsa_pss_pss_sha512,rsa_pss_pss_sha384,rsa_pss_pss_sha256,
      rsa_pss_rsae_sha512,rsa_pss_rsae_sha384,rsa_pss_rsae_sha256]
      </c></p>
      
	<note><p>Some TLS-1-3 scheme names overlap with TLS-1.2
	algorithm-tuple-pair-names and then TLS-1.3 names will be
	used, for example <c>rsa_pkcs1_sha256</c> instead of
	<c>{sha256, rsa}</c> these are legacy algorithms in TLS-1.3
	that apply only to certificate signatures in this version of
	the protocol.</p></note>
      </desc>
    </func>
    
    <func>
      <name since="" name="sockname" arity="1" />
      <fsummary>Returns the local address and port.</fsummary>
      <desc>
        <p>Returns the local address and port number of socket
          <c>SslSocket</c>.</p>
      </desc>
    </func>
    
    <func>
      <name since="OTP R14B" name="start" arity="0" />
      <name since="OTP R14B" name="start" arity="1" />
      <fsummary>Starts the SSL application.</fsummary>
      <desc>
        <p>Starts the SSL application. Default type
          is <c>temporary</c>.</p>
      </desc>
    </func>

    <func>
      <name since="OTP R14B" name="stop" arity="0" />
      <fsummary>Stops the SSL application.</fsummary>
      <desc>
        <p>Stops the SSL application.</p>
      </desc>
    </func>
  
    <func>
      <name since="OTP 22.0" name="str_to_suite" arity="1" />
      <fsummary>Converts an RFC or OpenSSL name string to an erlang cipher suite format</fsummary>
      <desc>
        <p>Converts an RFC or OpenSSL name string to an
	<seetype marker="#erl_cipher_suite">erl_cipher_suite()</seetype>
	Returns an error if the cipher suite is not supported or the name is not a valid cipher suite name.</p>
      </desc>
    </func>

    <func>
      <name since="OTP 22.0" name="suite_to_openssl_str" arity="1" />
      <fsummary>Converts erlang cipher suite format to an OpenSSL name string.
      </fsummary>
      <desc>
        <p>Converts <seetype marker="#erl_cipher_suite">erl_cipher_suite()</seetype>
	to OpenSSL name string. </p>
	
	<p>PRE TLS-1.3 these names differ for RFC names</p>
	
      </desc>
    </func>
    
    <func>
      <name since="OTP 21.0" name="suite_to_str" arity="1" clause_i="1" />
      <fsummary>Converts an erlang cipher suite to an RFC name string.</fsummary>
      <desc>
        <p>Converts <seetype marker="#erl_cipher_suite">erl_cipher_suite()</seetype>
	to RFC name string.</p>
      </desc>
    </func>

    <func>
      <name since="" name="transport_accept" arity="1" />
      <name since="" name="transport_accept" arity="2" />
      <fsummary>Accepts an incoming connection and
      prepares for <c>handshake</c> </fsummary>
      <desc>
        <p>Accepts an incoming connection request on a listen socket.
	<c>ListenSocket</c> must be a socket returned from
	<seemfa marker="#listen/2"> listen/2</seemfa>.
	The socket returned is to be passed to
	<seemfa marker="#handshake/2"> handshake/[2,3]</seemfa>
	to complete handshaking, that is,
	establishing the TLS/DTLS connection.</p>
        <warning>
          <p>Most API functions require that the TLS/DTLS 
          connection is established to work as expected.
	  </p>
        </warning>
        <p>The accepted socket inherits the options set for
	<c>ListenSocket</c> in
	<seemfa marker="#listen/2"> listen/2</seemfa>.</p>
	<p>The default
	value for <c>Timeout</c> is <c>infinity</c>. If
	<c>Timeout</c> is specified and no connection is accepted
	within the given time, <c>{error, timeout}</c> is
	returned.</p>
      </desc>
    </func>
    
    <func>
      <name since="OTP R14B" name="versions" arity="0" />
      <fsummary>Lists information, mainly concerning TLS/DTLS versions,
	in runtime for debugging and testing purposes.</fsummary>
      <desc>
	<p>Lists information, mainly concerning TLS/DTLS versions,
	in runtime for debugging and testing purposes.
	</p>
	<taglist>
	  <tag><c>app_vsn</c></tag>
	  <item>The application version of the SSL application.</item>

	  <tag><c>supported</c></tag>
	  <item>TLS versions supported with current application environment
	  and crypto library configuration.
	  Overridden by a version option on
	  
	  <seemfa marker="#connect/2"> connect/[2,3,4]</seemfa>,
	  <seemfa marker="#listen/2"> listen/2</seemfa>, and <seemfa
	  marker="#handshake/2">handshake/[2,3]</seemfa>.
	  
	  For the negotiated TLS version, see <seemfa
	  marker="#connection_information/1">connection_information/1
	  </seemfa>.</item>
	  
	  <tag><c>supported_dtls</c></tag>
	  <item>DTLS versions supported with current application environment
	  and crypto library configuration.
	  Overridden by a version option on

	  <seemfa marker="#connect/2"> connect/[2,3,4]</seemfa>,
	  <seemfa marker="#listen/2"> listen/2</seemfa>, and <seemfa
	  marker="#handshake/2">handshake/[2,3]</seemfa>.
	  
	  For the negotiated DTLS version, see <seemfa
	  marker="#connection_information/1">connection_information/1
	  </seemfa>.</item>

	  <tag><c>available</c></tag>
	  <item>All TLS versions supported with the
	  linked crypto library.
	 </item>

	  <tag><c>available_dtls</c></tag>
	  <item>All DTLS versions supported with the
	  linked crypto library.</item>
	  
	  <tag><c>implemented</c></tag>
	  <item>All TLS versions supported by the SSL
	  application if linked with a crypto library with the
	  necessary support.</item>

	  <tag><c>implemented_dtls</c></tag>
	  <item>All DTLS versions supported by the SSL
	  application if linked with a crypto library with the
	  necessary support.</item>
	  
	</taglist>
      </desc>
    </func>
   
  </funcs> 

  <section>
    <title>SEE ALSO</title>
    <p><seeerl marker="kernel:inet">inet(3)</seeerl> and
      <seeerl marker="kernel:gen_tcp">gen_tcp(3)</seeerl>
      <seeerl marker="kernel:gen_udp">gen_udp(3)</seeerl>
    </p>
  </section>

</erlref>