The default is to use "any" but disable SSLv2. This has the effect of sending a SSLv2 hello, indicating the support for SSLv3 and TLSv1, but not actually negotiating an (insecure) SSLv2 connection.

Specifying a specific version is almost always wrong to use for a server speaking to a wide variety of clients (e.g. web browsers), and often wrong for a client. If you only want to allow a specific protocol version, use the "sslv2", "sslv3", "tlsv1", "tlsv1_1" or "tlsv1_2" arguments instead.

For new services it is usually a good idea to enforce a "TLSv1" method from the beginning.

"TLSv1_1" and "TLSv1_2" require Net::SSLeay >= 1.55 and OpenSSL >= 1.0.1. Check the Net::SSLeay and OpenSSL documentations for more details.

This requires Net::SSLeay >= 1.55 and OpenSSL >= 1.0.1. Check the Net::SSLeay and OpenSSL documentations for more details.

This requires Net::SSLeay >= 1.55 and OpenSSL >= 1.0.1. Check the Net::SSLeay and OpenSSL documentations for more details.

This is the "master switch" for all verify-related parameters and functions.

If it is disabled, then no peer certificate verification will be done - the connection will be encrypted, but the peer certificate won't be verified against any known CAs, or whether it is still valid or not. No peername verification or custom verification will be done either.

If enabled, then the peer certificate (required in client mode, optional in server mode, see "verify_require_client_cert") will be checked against its CA certificate chain - that means there must be a signing chain from the peer certificate to any of the CA certificates you trust locally, as specified by the "ca_file" and/or "ca_path" and/or "ca_cert" parameters (or the system default CA repository, if all of those parameters are missing - see also the AnyEvent manpage for the description of PERL_ANYEVENT_CA_FILE).

Other basic checks, such as checking the validity period, will also be done, as well as optional peername/hostname/common name verification "verify_peername".

An optional "verify_cb" callback can also be set, which will be invoked with the verification results, and which can override the decision.

This can be implemented by specifying a callback that has to verify that the actual $peername matches the given certificate in $cert.

Since this can be rather hard to implement, AnyEvent::TLS offers a variety of predefined "schemes" (lifted from IO::Socket::SSL) that are named like the protocols that use them:

This callback will only be called when verification is enabled ("verify => 1").

$tls is the "AnyEvent::TLS" object associated with the session, while $ref is whatever the user associated with the session (usually an AnyEvent::Handle object when used by AnyEvent::Handle).

$depth is the current verification depth - "$depth = 0" means the certificate to verify is the peer certificate, higher levels are its CA certificate and so on. In most cases, you can just return $preverify_ok if the $depth is non-zero:

   verify_cb => sub {
      my ($tls, $ref, $cn, $depth, $preverify_ok, $x509_store_ctx, $cert) = @_;

      return $preverify_ok
         if $depth;

      # more verification
   },
    

$preverify_ok is true iff the basic verification of the certificates was successful (a valid CA chain must exist, the certificate has passed basic validity checks, peername verification succeeded).

$x509_store_ctx is the Net::SSLeay::X509_CTX> object.

$cert is the "Net::SSLeay::X509" object representing the peer certificate, or zero if there was an error. You can call "AnyEvent::TLS::certname $cert" to get a nice user-readable string to identify the certificate.

The callback must return either 0 to indicate failure, or 1 to indicate success.

   -----BEGIN CERTIFICATE-----
   ... (CA certificate in base64 encoding) ...
   -----END CERTIFICATE-----
    

You have to enable verify mode ("verify => 1") for this parameter to have any effect.

The certificates specified via "ca_file" take precedence over the ones found in "ca_path".

You have to enable verify mode ("verify => 1") for this parameter to have any effect.

certificate verification will fail if this is enabled but no revocation list was found.

This requires OpenSSL >= 0.9.7b. Check the OpenSSL documentation for more details.

The local certificate is used to authenticate against the peer - servers mandatorily need a certificate and key, clients can use a certificate and key optionally to authenticate, e.g. for log-in purposes.

The key in the file should look similar this:

   -----BEGIN RSA PRIVATE KEY-----
   ...header data
   ... (key data in base64 encoding) ...
   -----END RSA PRIVATE KEY-----
    

The idea behind being able to specify a string is to avoid blocking in I/O. Unfortunately, Net::SSLeay fails to implement any interface to the needed OpenSSL functionality, this is currently implemented by writing to a temporary file.

The local certificate (and key) are used to authenticate against the peer - servers mandatorily need a certificate and key, clients can use certificate and key optionally to authenticate, e.g. for log-in purposes.

The certificate in the file should look like this:

   -----BEGIN CERTIFICATE-----
   ... (certificate in base64 encoding) ...
   -----END CERTIFICATE-----
    

If the certificate file or string contain both the certificate and private key, then there is no need to specify a separate "key_file" or "key".

Additional signing certifiates to send to the peer (in SSLv3 and newer) can be specified by appending them to the certificate proper: the order must be from issuer certificate over any intermediate CA certificates to the root CA.

So the recommended ordering for a combined key/cert/chain file, specified via "cert_file" or "cert" looks like this:

  certificate private key
  client/server certificate
  ca 1, signing client/server certficate
  ca 2, signing ca 1
  ...
    

The idea behind being able to specify a string is to avoid blocking in I/O. Unfortunately, Net::SSLeay fails to implement any interface to the needed OpenSSL functionality, this is currently implemented by writing to a temporary file.

Instead of providing a password directly (which is not so recommended), you can also provide a password-query callback. The callback will be called whenever a password is required to decode a local certificate, and is supposed to return the password.

Diffie-Hellman key exchange generates temporary encryption keys that are not transferred over the connection, which means that even if the certificate key(s) are made public at a later time and a full dump of the connection exists, the key still cannot be deduced.

These ciphers are only available with SSLv3 and later (which is the default with AnyEvent::TLS), and are only used in server/accept mode. Anonymous DH protocols are usually disabled by default, and usually not even compiled into the underlying library, as they provide no direct protection against man-in-the-middle attacks. The same is true for the common practise of self-signed certificates that you have to accept first, of course.

AnyEvent::TLS supports supports a number of precomputed DH parameters, since computing them is expensive. They are:

   # from RFC 7919 - recommended
   ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192

   # from "Assigned Number for SKIP Protocols"
   skip512, skip1024, skip2048, skip4096

   # from schmorp
   schmorp1024, schmorp1539, schmorp2048, schmorp4096, schmorp8192
    

It is said that 2048 bit DH parameters are safe till 2030, and DH parameters shorter than 900 bits are totally insecure.

To disable DH protocols completely, specify "undef" as "dh" parameter.

All the DH parameters supplied with AnyEvent::TLS should be safe with "dh_single_use" switched off, but YMMV.

When enabled and supported by the server, a session ticket will be provided to the client, which allows fast resuming of connections.