COMPATIBILITY NOTE:Net::SSLeay cannot be built with pre-0.9.3 openssl. It is strongly recommended to use at least 0.9.7 (as older versions are not tested during development). Some low level API functions may be available with certain openssl versions.

This module offers some high level convenience functions for accessing web pages on SSL servers (for symmetry, the same API is offered for accessing http servers, too), an sslcat() function for writing your own clients, and finally access to the SSL api of the SSLeay/OpenSSL package so you can write servers or clients for more complicated applications.

For high level functions it is most convenient to import them into your main namespace as indicated in the synopsis.

Case 1 (in SYNOPSIS) demonstrates the typical invocation of get_https() to fetch an HTML page from secure server. The first argument provides the hostname or IP in dotted decimal notation of the remote server to contact. The second argument is the TCP port at the remote end (your own port is picked arbitrarily from high numbered ports as usual for TCP). The third argument is the URL of the page without the host name part. If in doubt consult the HTTP specifications at http://www.w3c.org.

Case 2 (in SYNOPSIS) demonstrates full fledged use of get_https(). As can be seen, get_https() parses the response and response headers and returns them as a list, which can be captured in a hash for later reference. Also a fourth argument to get_https() is used to insert some additional headers in the request. make_headers() is a function that will convert a list or hash to such headers. By default get_https() supplies Host (to make virtual hosting easy) and Accept (reportedly needed by IIS) headers.

Case 2b (in SYNOPSIS) demonstrates how to get a password protected page. Refer to the HTTP protocol specifications for further details (e.g. RFC-2617).

Case 3 (in SYNOPSIS) invokes post_https() to submit a HTML/CGI form to a secure server. The first four arguments are equal to get_https() (note that the empty string ('') is passed as header argument). The fifth argument is the contents of the form formatted according to CGI specification. Do not post UTF-8 data as content: use utf8::downgrade first. In this case the helper function make_https() is used to do the formatting, but you could pass any string. post_https() automatically adds Content-Type and Content-Length headers to the request.

Case 4 (in SYNOPSIS) shows the fundamental sslcat() function (inspired in spirit by the netcat utility :-). It's your swiss army knife that allows you to easily contact servers, send some data, and then get the response. You are responsible for formatting the data and parsing the response - sslcat() is just a transport.

Case 5 (in SYNOPSIS) is a full invocation of sslcat() which allows the return of errors as well as the server (peer) certificate.

The $trace global variable can be used to control the verbosity of the high level functions. Level 0 guarantees silence, level 1 (the default) only emits error messages.

The above mentioned functions actually return the response headers as a list, which only gets converted to hash upon assignment (this assignment looses information if the same header occurs twice, as may be the case with cookies). There are also other variants of the functions that return unprocessed headers and that return a reference to a hash.

All of the above code fragments accomplish the same thing: display all values of all headers. The API functions ending in "3" return the headers simply as a scalar string and it is up to the application to split them up. The functions ending in "4" return a reference to a hash of arrays (see perlref and perllol if you are not familiar with complex perl data structures). To access a single value of such a header hash you would do something like

print $$headers_ref{COOKIE}[0];

Variants 3 and 4 also allow you to discover the server certificate in case you would like to store or display it, e.g.

Beware that this method only allows after the fact verification of the certificate: by the time get_https3() has returned the https request has already been sent to the server, whether you decide to trust it or not. To do the verification correctly you must either employ the OpenSSL certificate verification framework or use the lower level API to first connect and verify the certificate and only then send the http data. See the implementation of ds_https3() for guidance on how to do this.

Secure web communications are encrypted using symmetric crypto keys exchanged using encryption based on the certificate of the server. Therefore in all SSL connections the server must have a certificate. This serves both to authenticate the server to the clients and to perform the key exchange.

Sometimes it is necessary to authenticate the client as well. Two options are available: HTTP basic authentication and a client side certificate. The basic authentication over HTTPS is actually quite safe because HTTPS guarantees that the password will not travel in the clear. Never-the-less, problems like easily guessable passwords remain. The client certificate method involves authentication of the client at the SSL level using a certificate. For this to work, both the client and the server have certificates (which typically are different) and private keys.

The API functions outlined above accept additional arguments that allow one to supply the client side certificate and key files. The format of these files is the same as used for server certificates and the caveat about encrypting private keys applies.

Over the years it has become clear that it would be convenient to use the light-weight flavour API of Net::SSLeay for normal HTTP as well (see LWP for the heavy-weight object-oriented approach). In fact it would be nice to be able to flip https on and off on the fly. Thus regular HTTP support was evolved.

OpenSSL supports the ability to verify peer certificates. It can also optionally check the peer certificate against a Certificate Revocation List (CRL) from the certificates issuer. A CRL is a file, created by the certificate issuer that lists all the certificates that it previously signed, but which it now revokes. CRLs are in PEM format.

After setting this flag, if OpenSSL checks a peer's certificate, then it will attempt to find a CRL for the issuer. It does this by looking for a specially named file in the search directory specified by CTX_load_verify_locations. CRL files are named with the hash of the issuer's subject name, followed by .r0, .r1 etc. For example ab1331b2.r0, ab1331b2.r1. It will read all the .r files for the issuer, and then check for a revocation of the peer certificate in all of them. (You can also force it to look in a specific named CRL file., see below). You can find out the hash of the issuer subject name in a CRL with

openssl crl -in crl.pem -hash -noout

If the peer certificate does not pass the revocation list, or if no CRL is found, then the handshaking fails with an error.

You can also force OpenSSL to look for CRLs in one or more arbitrarily named files.

NOTE: Openssl's int SSL_library_init(void) function (which is also aliased as SSLeay_add_ssl_algorithms, OpenSSL_add_ssl_algorithms and add_ssl_algorithms) is not re-entrant and multiple calls can cause a crash in threaded application. Net::SSLeay implements flags preventing repeated calls to this function, therefore even multiple initialization via Net::SSLeay::SSLeay_add_ssl_algorithms() should work without trouble.

Do not use callbacks across threads (the module blocks cross-thread callback operations and throws a warning). Allways do the callback setup, callback use and callback destruction within the same thread.

It should be fine to use any other module based on Net::SSLeay (like IO::Socket::SSL) in multi-threaded applications. It is generally recommended to do any global initialization of such a module in the main thread before calling threads->new(..) or threads->create(..) but it might differ module by module.

To be play safe you can load and init Net::SSLeay explicitly in the main thread:

BEWARE: This might be a big trouble! This is not guaranteed be thread-safe!

There are many other (XS) modules linked directly to openssl library (like Crypt::SSLeay).

As it is expected that also "another" module will call SSLeay_add_ssl_algorithms at some point we have again a trouble with multiple openssl initialization by Net::SSLeay and "another" module.

As you can expect Net::SSLeay is not able to avoid multiple initialization of openssl library called by "another" module, thus you have to handle this on your own (in some cases it might not be possible at all to avoid this).

Net::SSLeay::initialize initializes the SSL library at most once. You can override the Net::SSLeay::initialize function if you desire some other type of initialization behaviour by get_https and friends. You can call Net::SSLeay::initialize from your own code if you desire this conventional library initialization.

seeds the openssl PRNG with /dev/urandom (see the top of SSLeay.pm for how to change or configure this) and optionally with user provided data. It is very important to properly seed your random numbers, so do not forget to call this. The high level API functions automatically call randomize() so it is not needed with them. See also caveats.

set_cert_and_key

takes two file names as arguments and sets the certificate and private key to those. This can be used to set either server certificates or client certificates.

dump_peer_certificate

allows you to get a plaintext description of the certificate the peer (usually the server) presented to us.

ssl_read_all

see ssl_write_all (below)

ssl_write_all

ssl_read_all() and ssl_write_all() provide true blocking semantics for these operations (see limitation, below, for explanation). These are much preferred to the low level API equivalents (which implement BSD blocking semantics). The message argument to ssl_write_all() can be a reference. This is helpful to avoid unnecessary copying when writing something big, e.g:

uses ssl_read_all() to read in a line terminated with a carriage return followed by a linefeed (CRLF). The CRLF is included in the returned scalar.

ssl_read_until

uses ssl_read_all() to read from the SSL input stream until it encounters a programmer specified delimiter. If the delimiter is undefined, $/ is used. If $/ is undefined, \n is used. One can optionally set a maximum length of bytes to read from the SSL input stream.

I can not emphasize the need to check for error enough. Use these functions even in the most simple programs, they will reduce debugging time greatly. Do not ask questions on the mailing list without having first sprinkled these in your code.

die_now

die_if_ssl_error

die_now() and die_if_ssl_error() are used to conveniently print the SSLeay error stack when something goes wrong:

You can also use Net::SSLeay::print_errs() to dump the error stack without exiting the program. As can be seen, your code becomes much more readable if you import the error reporting functions into your main name space.

Perl uses file handles for all I/O. While SSLeay has a quite flexible BIO mechanism and perl has an evolved PerlIO mechanism, this module still sticks to using file descriptors. Thus to attach SSLeay to a socket you should use fileno() to extract the underlying file descriptor:

Net::SSLeay::set_fd($ssl, fileno(S)); # Must use fileno

You should also set $| to 1 to eliminate STDIO buffering so you do not get confused if you use perl I/O functions to manipulate your socket handle.

If you need to select(2) on the socket, go right ahead, but be warned that OpenSSL does some internal buffering so SSL_read does not always return data even if the socket selected for reading (just keep on selecting and trying to read). Net::SSLeay is no different from the C language OpenSSL in this respect.

In addition to the high level functions outlined above, this module contains straight-forward access to CRYPTO and SSL parts of OpenSSL C API.

See the *.h headers from OpenSSL C distribution for a list of low level SSLeay functions to call (check SSLeay.xs to see if some function has been implemented). The module strips the initial "SSL_" off of the SSLeay names. Generally you should use Net::SSLeay:: in its place.

Note that some functions are prefixed with "P_" - these are very close to the original API however contain some kind of a wrapper making its interface more perl friendly.

Causes a run through the session cache of $ctx to remove sessions expired at time $tm.

Net::SSLeay::CTX_flush_sessions($ctx, $tm);
# $ctx - value corresponding to openssl's SSL_CTX structure
# $tm - specifies the time which should be used for the expiration test (seconds since 1.1.1970)
#
# returns: no return value

my $rv = Net::SSLeay::CTX_sess_misses($ctx);
# $ctx - value corresponding to openssl's SSL_CTX structure
#
# returns: number of sessions proposed by clients that were not found in the internal session cache in server mode

Returns the number of sessions proposed by clients and either found in the internal or external session cache in server mode, but that were invalid due to timeout. These sessions are not included in the SSL_CTX_sess_hits count.

Sets a new default TLS/SSL method for SSL objects newly created from this $ctx. SSL objects already created with Net::SSLeay::new($ctx) are not affected, except when Net::SSLeay:clear($ssl) is being called.

Loads a certificate chain from $file into $ctx. The certificates must be in PEM format and must be sorted starting with the subject's certificate (actual client or server certificate), followed by intermediate CA certificates if applicable, and ending at the highest level (root) CA.

NOTE: Please note that the function described in this chapter have "SSL_" part stripped from their original openssl names.

new

Creates a new SSL structure which is needed to hold the data for a TLS/SSL connection. The new structure inherits the settings of the underlying context $ctx: connection method (SSLv2/v3/TLSv1), options, verification settings, timeout settings.

Will wait for a SSL/TLS handshake to take place. If the connection is in client mode, the handshake will be started. The handshake routines may have to be explicitly set in advance using either SSL_set_connect_state or SSL_set_accept_state(3).

Net::SSLeay::RAND_add($buf, $num, $entropy);
# $buf - buffer with data to be mixed into the PRNG state
# $num - number of bytes in $buf
# $entropy - estimate of how much randomness is contained in $buf (in bytes)
#
# returns: no return value

my $rv = Net::SSLeay::RAND_egd_bytes($path, $bytes);
# $path - path to a socket of entropy gathering daemon EGD
# $bytes - number of bytes we want from EGD
#
# returns: the number of bytes read from the daemon on success, and -1 on failure

Converts the text string s into an ASN1_OBJECT structure. If $no_name is 0 then long names (e.g. 'commonName') and short names (e.g. 'CN') will be interpreted as well as numerical forms (e.g. '2.5.4.3'). If $no_name is 1 only the numerical form is acceptable.

BEWARE: If the value stored in ASN1_INTEGER is greater than max. integer that can be stored in 'long' type (usually 32bit but may vary according to platform) then this function will return -1. For getting large ASN1_INTEGER values consider using "P_ASN1_INTEGER_get_dec" or "P_ASN1_INTEGER_get_hex".

BEWARE: It is platform dependent how this function will handle dates after 2038. Although perl's integer is large enough the internal implementation of this function is dependent on the size of time_t structure (32bit time_t has problem with 2038).

Sort of a checksum of issuer name and serial number of X509 certificate $x. The result is not a full hash (e.g. sha-1), it is kind-of-a-hash truncated to the size of 'unsigned long' (32 bits). The resulting value might differ across different openssl versions for the same X509 certificate.

Sort of a checksum of issuer name of X509 certificate $x. The result is not a full hash (e.g. sha-1), it is kind-of-a-hash truncated to the size of 'unsigned long' (32 bits). The resulting value might differ across different openssl versions for the same X509 certificate.

Sort of a checksum of subject name of X509 certificate $x. The result is not a full hash (e.g. sha-1), it is kind-of-a-hash truncated to the size of 'unsigned long' (32 bits). The resulting value might differ across different openssl versions for the same X509 certificate.

Retrieves the X509_NAME_ENTRY from $name corresponding to index $loc. Acceptable values for $loc run from 0 to Net::SSLeay::X509_NAME_entry_count($name)- 1. The value returned is an internal pointer which must not be freed.

Retrieves the text from the first entry in name which matches $nid, if no such entry exists -1 is returned.

openssl note: this is a legacy function which has various limitations which makes it of minimal use in practice. It can only find the first matching entry and will copy the contents of the field verbatim: this can be highly confusing if the target is a muticharacter string type like a BMPString or a UTF8String.

Add a directory of certs to a stack. All certs in $dir that are not already in the $stackCAs will be added.

my $rv = Net::SSLeay::add_dir_cert_subjects_to_stack($stackCAs, $dir);
# $stackCAs - value corresponding to openssl's STACK_OF(X509_NAME) structure
# $dir - (string) the directory to append from. All files in this directory will be examined as potential certs. Any that are acceptable to SSL_add_dir_cert_subjects_to_stack() that are not already in the stack will be included.
#
# returns: 1 on success, 0 on failure

Returns the depth of the error. This is a non-negative integer representing where in the certificate chain the error occurred. If it is zero it occurred in the end entity certificate, one if it is the certificate which signed the end entity certificate and so on.

COMPATIBILITY: not available in Net-SSLeay-1.42 and before; requires at least openssl-0.9.7

Sets up digest context $ctx to use a digest $type from ENGINE $impl, $ctx must be initialized before calling this function, type will typically be supplied by a function such as "EVP_get_digestbyname". If $impl is 0 then the default implementation of digest $type is used.

my $rv = Net::SSLeay::BIO_write($b, $buffer);
# $b - value corresponding to openssl's BIO structure
# $buffer - data
#
# returns: amount of data successfully written
# or that no data was successfully read or written if the result is 0 or -1
# or -2 when the operation is not implemented in the specific BIO type

This function is used in a server to support Server side Server Name Indication (SNI).

Net::SSLeay::CTX_set_tlsext_servername_callback($ctx, $code)
# $ctx - SSL context
# $code - reference to a subroutine that will be called when a new connection is being initiated
#
# returns: no return value
On the client side:
use set_tlsext_host_name($ssl, $servername) before initiating the SSL connection.

On the server side: Set up an additional SSL_CTX() for each different certificate;

Add a servername callback to each SSL_CTX() using CTX_set_tlsext_servername_callback();

The callback function is required to retrieve the client-supplied servername with get_servername(ssl). Figure out the right SSL_CTX to go with that host name, then switch the SSL object to that SSL_CTX with set_SSL_CTX().

Adds the compression method cm with the identifier id to the list of available compression methods. This list is globally maintained for all SSL operations within this application. It cannot be set for specific SSL_CTX or SSL objects.

The constants names are derived from openssl constants, however constants starting with SSL_ prefix have name with SSL_ part stripped - e.g. openssl's constant SSL_OP_ALL is available as Net::SSleay::OP_ALL

Yet another echo server. This one runs from /etc/inetd.conf so it avoids all the socket code overhead. Only caveat is opening an rsa key file - it had better be without any encryption or else it will not know where to ask for the password. Note how STDIN and STDOUT are wired to SSL.

There are also a number of example/test programs in the examples directory:

sslecho.pl - A simple server, not unlike the one above
minicli.pl - Implements a client using low level SSLeay routines
sslcat.pl - Demonstrates using high level sslcat utility function
get_page.pl - Is a utility for getting html pages from secure servers
callback.pl - Demonstrates certificate verification and callback usage
stdio_bulk.pl - Does SSL over Unix pipes
ssl-inetd-serv.pl - SSL server that can be invoked from inetd.conf
httpd-proxy-snif.pl - Utility that allows you to see how a browser
sends https request to given server and what reply
it gets back (very educative :-)
makecert.pl - Creates a self signed cert (does not use this module)

Net::SSLeay::read() uses an internal buffer of 32KB, thus no single read will return more. In practice one read returns much less, usually as much as fits in one network packet. To work around this, you should use a loop like this:

warning if die_if_ssl_error is made autoloadable. If you figure out why, drop me a line.

Callback set using SSL_set_verify() does not appear to work. This may well be an openssl problem (e.g. see ssl/ssl_lib.c line 1029). Try using SSL_CTX_set_verify() instead and do not be surprised if even this stops working in future versions.

Random numbers are not initialized randomly enough, especially if you do not have /dev/random and/or /dev/urandom (such as in Solaris platforms - but it's been suggested that cryptorand daemon from the SUNski package solves this). In this case you should investigate third party software that can emulate these devices, e.g. by way of a named pipe to some program.

Another gotcha with random number initialization is randomness depletion. This phenomenon, which has been extensively discussed in OpenSSL, Apache-SSL, and Apache-mod_ssl forums, can cause your script to block if you use /dev/random or to operate insecurely if you use /dev/urandom. What happens is that when too much randomness is drawn from the operating system's randomness pool then randomness can temporarily be unavailable. /dev/random solves this problem by waiting until enough randomness can be gathered - and this can take a long time since blocking reduces activity in the machine and less activity provides less random events: a vicious circle. /dev/urandom solves this dilemma more pragmatically by simply returning predictable "random" numbers. Some /dev/urandom emulation software however actually seems to implement /dev/random semantics. Caveat emptor.

I've been pointed to two such daemons by Mik Firestone <mik@@speed.stdio._com> who has used them on Solaris 8:

to cope with some well know bugs in some other SSL implementations. The high level API functions always set all known compatibility options.

Sometimes sslcat() (and the high level HTTPS functions that build on it) is too fast in signaling the EOF to legacy HTTPS servers. This causes the server to return empty page. To work around this problem you can set the global variable

$Net::SSLeay::slowly = 1; # Add sleep so broken servers can keep up

HTTP/1.1 is not supported. Specifically this module does not know to issue or serve multiple http requests per connection. This is a serious shortcoming, but using the SSL session cache on your server helps to alleviate the CPU load somewhat.

As of version 1.09 many newer OpenSSL auxiliary functions were added (from REM_AUTOMATICALLY_GENERATED_1_09 onwards in SSLeay.xs). Unfortunately I have not had any opportunity to test these. Some of them are trivial enough that I believe they "just work", but others have rather complex interfaces with function pointers and all. In these cases you should proceed wit great caution.

This module defaults to using OpenSSL automatic protocol negotiation code for automatically detecting the version of the SSL protocol that the other end talks. With most web servers this works just fine, but once in a while I get complaints from people that the module does not work with some web servers. Usually this can be solved by explicitly setting the protocol version, e.g.

Although the autonegotiation is nice to have, the SSL standards do not formally specify any such mechanism. Most of the world has accepted the SSLeay/OpenSSL way of doing it as the de facto standard. But for the few that think differently, you have to explicitly speak the correct version. This is not really a bug, but rather a deficiency in the standards. If a site refuses to respond or sends back some nonsensical error codes (at the SSL handshake level), try this option before mailing me.

On some systems, OpenSSL may be compiled without support for SSLv2. If this is the case, Net::SSLeay will warn if ssl_version has been set to 2.

The high level API returns the certificate of the peer, thus allowing one to check what certificate was supplied. However, you will only be able to check the certificate after the fact, i.e. you already sent your form data by the time you find out that you did not trust them, oops.

So, while being able to know the certificate after the fact is surely useful, the security minded would still choose to do the connection and certificate verification first and only then exchange data with the site. Currently none of the high level API functions do this, thus you would have to program it using the low level API. A good place to start is to see how the Net::SSLeay::http_cat() function is implemented.

The high level API functions use a global file handle SSLCAT_S internally. This really should not be a problem because there is no way to interleave the high level API functions, unless you use threads (but threads are not very well supported in perl anyway (as of version 5.6.1). However, you may run into problems if you call undocumented internal functions in an interleaved fashion. The best solution is to "require Net::SSLeay" in one thread after all the threads have been created.

(W) This warning indicates that randomize() was not able to read /dev/random or /dev/urandom, possibly because your system does not have them or they are differently named. You can still use SSL, but the encryption will not be as strong.

SSLeay error string. The first number (123) is the PID, the second number (1) indicates the position of the error message in SSLeay error stack. You often see a pile of these messages as errors cascade.

This is normal behaviour if your private key is encrypted. Either you have to supply the password or you have to use an unencrypted private key. Scan OpenSSL.org for the FAQ that explains how to do this (or just study examples/makecert.pl which is used during make test to do just that).

The BEAST attack relies on a weakness in the way CBC mode is used in SSL/TLS. In OpenSSL versions 0.9.6d and later, the protocol-level mitigation is enabled by default, thus making it not vulnerable to the BEAST attack.

Solutions:

Compile with OpenSSL versions 0.9.6d or later, which enables SSL_OP_ALL by default

Ensure SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not enabled (its not enabled by default)

Dont support SSLv2, SSLv3

Actively control the ciphers your server supports with set_cipher_list:

This report is not really bug or a vulnerability, since the server will not accept session resumption requests. However, you can prevent this noise in the report by disabling the session cache altogether: Net::SSLeay::CTX_set_session_cache_mode($ssl_ctx, 0);

Distribution and use of this module is under the same terms as the OpenSSL package itself (i.e. free, but mandatory attribution; NO WARRANTY). Please consult LICENSE file in the root of the OpenSSL distribution.

While the source distribution of this perl module does not contain Eric's or OpenSSL's code, if you use this module you will use OpenSSL library. Please give Eric and OpenSSL team credit (as required by their licenses).

And remember, you, and nobody else but you, are responsible for auditing this module and OpenSSL library for security problems, backdoors, and general suitability for your application.