ADC Home > Reference Library > Reference > Mac OS X > Mac OS X Man Pages

 

This document is a Mac OS X manual page. Manual pages are a command-line technology for providing documentation. You can view these manual pages locally using the man(1) command. These manual pages come from many different sources, and thus, have a variety of writing styles.

For more information about the manual page format, see the manual page for manpages(5).



SSLeay(3)                            User Contributed Perl Documentation                           SSLeay(3)



NAME
       Net::SSLeay - Perl extension for using OpenSSL

SYNOPSIS
         use Net::SSLeay, qw(get_https post_https sslcat make_headers make_form);

         ($page) = get_https('www.bacus.pt', 443, '/');                 # 1

         ($page, $response, %reply_headers)
                = get_https('www.bacus.pt', 443, '/',                   # 2
                       make_headers(User-Agent => 'Cryptozilla/5.0b1',
                                    Referer    => 'https://www.bacus.pt'
                       ));

         ($page, $result, %headers) =                                   # 2b
                = get_https('www.bacus.pt', 443, '/protected.html',
                     make_headers(Authorization =>
                                  'Basic ' . MIME::Base64::encode("$user:$pass",''))
                     );

         ($page, $response, %reply_headers)
                = post_https('www.bacus.pt', 443, '/foo.cgi', '',       # 3
                       make_form(OK   => '1',
                                 name => 'Sampo'
                       ));

         $reply = sslcat($host, $port, $request);                       # 4

         ($reply, $err, $server_cert) = sslcat($host, $port, $request); # 5

         $Net::SSLeay::trace = 2;  # 0=no debugging, 1=ciphers, 2=trace, 3=dump data

DESCRIPTION
       There is a related module called Net::SSLeay::Handle included in this distribution that you might
       want to use instead. It has its own pod documentation.

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

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

       Case 1 demonstrates typical invocation of get_https() to fetch an HTML page from secure server. The
       first argument provides host name or ip in dotted decimal notation of the remote server to contact.
       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 HTTP specifications at <http://www.w3c.org

       Case 2 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 (make virtual hosting easy) and Accept (reportedly needed by IIS) headers.

       Case 2b demonstrates how to get password protected page. Refer to HTTP protocol specifications for
       further details (e.g. RFC2617).

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

       Case 4 shows the fundamental sslcat() function (inspired in spirit by netcat utility :-). Its 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 is a full invocation of sslcat() which allows return of errors as well as the server (peer)
       certificate.

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

       Alternate versions of the API

       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.

         ($page, $response, @headers) = get_https('www.bacus.pt', 443, '/');
         for ($i = 0; $i < $#headers; $i+=2) {
             print "$headers[$i] = " . $headers[$i+1] . "\n";
         }

         ($page, $response, $headers, $server_cert)
           = get_https3('www.bacus.pt', 443, '/');
         print "$headers\n";

         ($page, $response, %headers_ref, $server_cert)
           = get_https4('www.bacus.pt', 443, '/');
         for $k (sort keys %{headers_ref}) {
             for $v (@{$headers_ref{$k}}) {
                 print "$k = $v\n";
             }
         }

       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 hash of arrays (see perlref and
       perllol manual pages if you are not familiar with complex perl data structures). To access single
       value of such header hash you would do something like

         print $headers_ref{COOKIE}[0];

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

         ($p, $resp, $hdrs, $server_cert) = get_https3('www.bacus.pt', 443, '/');
         if (!defined($server_cert) || ($server_cert == 0)) {
             warn "Subject Name: undefined, Issuer  Name: undefined";
         } else {
             warn 'Subject Name: '
                 . Net::SSLeay::X509_NAME_oneline(
                        Net::SSLeay::X509_get_subject_name($server_cert))
                     . 'Issuer  Name: '
                         . Net::SSLeay::X509_NAME_oneline(
                                Net::SSLeay::X509_get_issuer_name($server_cert));
         }

       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 tryst 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 implementation of ds_https3() for guidance on how to do this.

       Using client certificates

       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 client side certificate. The basic authentication over https is actually quite
       safe because https guarantees that the password will not travel in clear. Never-the-less, problems
       like easily guessable passwords remain. The client certificate method involves authentication of the
       client at SSL level using a certificate. For this to work, both the client and the server will 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 key applies.

         ($page, $result, %headers) =                                   # 2c
                = get_https('www.bacus.pt', 443, '/protected.html',
                     make_headers(Authorization =>
                                  'Basic ' . MIME::Base64::encode("$user:$pass",'')),
                     '', $mime_type6, $path_to_crt7, $path_to_key8);

         ($page, $response, %reply_headers)
                = post_https('www.bacus.pt', 443, '/foo.cgi',           # 3b
                     make_headers('Authorization' =>
                                  'Basic ' . MIME::Base64::encode("$user:$pass",'')),
                     make_form(OK   => '1', name => 'Sampo'),
                     $mime_type6, $path_to_crt7, $path_to_key8);

       Case 2c demonstrates getting password protected page that also requires client certificate, i.e. it
       is possible to use both authentication methods simultaneously.

       Case 3b is full blown post to secure server that requires both password authentication and client
       certificate, just like in case 2c.

       Note: Client will not send a certificate unless the server requests one.  This is typically achieved
       by setting verify mode to VERIFY_PEER on the server:

         Net::SSLeay::set_verify(ssl, Net::SSLeay::VERIFY_PEER, 0);

       See perldoc ~openssl/doc/ssl/SSL_CTX_set_verify.pod for full description.

       Working through Web proxy

       Net::SSLeay can use a web proxy to make its connections. You need to first set the proxy host and
       port using set_proxy() and then just use the normal API functions, e.g:

         Net::SSLeay::set_proxy('gateway.myorg.com', 8080);
         ($page) = get_https('www.bacus.pt', 443, '/');

       If your proxy requires authentication, you can supply username and password as well

         Net::SSLeay::set_proxy('gateway.myorg.com', 8080, 'joe', 'salainen');
         ($page, $result, %headers) =
                = get_https('www.bacus.pt', 443, '/protected.html',
                     make_headers(Authorization =>
                                  'Basic ' . MIME::Base64::encode("susie:pass",''))
                     );

       This example demonstrates case where we authenticate to the proxy as "joe" and to the final web
       server as "susie". Proxy authentication requires MIME::Base64 module to work.

       Certificate verification and Certificate Revoocation Lists (CRLs)

       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.

       You can enable Net::SSLeay CRL checking like this:

                   &Net::SSLeay::X509_STORE_CTX_set_flags
                       (&Net::SSLeay::CTX_get_cert_store($ssl),
                        &Net::SSLeay::X509_V_FLAG_CRL_CHECK);

       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 cerificate 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.

       my $bio = &Net::SSLeay::BIO_new_file($crlfilename, 'r'); my $crl =
       &Net::SSLeay::PEM_read_bio_X509_CRL($bio); if ($crl) {
           &Net::SSLeay::X509_STORE_add_crl(&Net::SSLeay::CTX_get_cert_store($ssl, $crl); } else {
           error reading CRL....  }

       Convenience routines

       To be used with Low level API

           Net::SSLeay::randomize($rn_seed_file,$additional_seed);
           Net::SSLeay::set_cert_and_key($ctx, $cert_path, $key_path);
           $cert = Net::SSLeay::dump_peer_certificate($ssl);
           Net::SSLeay::ssl_write_all($ssl, $message) or die "ssl write failure";
           $got = Net::SSLeay::ssl_read_all($ssl) or die "ssl read failure";

           $got = Net::SSLeay::ssl_read_CRLF($ssl [, $max_length]);
           $got = Net::SSLeay::ssl_read_until($ssl [, $delimit [, $max_length]]);
           Net::SSLeay::ssl_write_CRLF($ssl, $message);

       randomize() seeds the eay PRNG with /dev/urandom (see 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 cerver certificates or client certificates.

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

       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 reference. This is
       helpful to avoid unnecessary copy when writing something big, e.g:

           $data = 'A' x 1000000000;
           Net::SSLeay::ssl_write_all($ssl, \$data) or die "ssl write failed";

       ssl_read_CRLF() 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.

       ssl_write_CRLF() writes $message and appends CRLF to the SSL output stream.

       Low level API

       In addition to the high level functions outlined above, this module contains straight forward access
       to SSL part of OpenSSL C api. Only the SSL subpart of OpenSSL is implemented (if anyone wants to
       implement other parts, feel free to submit patches).

       See ssl.h header from OpenSSL C distribution for list of low lever SSLeay functions to call (to check
       if some function has been implemented see directly in SSLeay.xs). The module strips SSLeay names of
       the initial "SSL_", generally you should use Net::SSLeay:: in place. For example:

       In C:

               #include <ssl.h>

               err = SSL_set_verify (ssl, SSL_VERIFY_CLIENT_ONCE,
                                          &your_call_back_here);

       In perl:

               use Net::SSLeay;

               $err = Net::SSLeay::set_verify ($ssl,
                                               &Net::SSLeay::VERIFY_CLIENT_ONCE,
                                               \&your_call_back_here);

       If the function does not start by SSL_ you should use the full function name, e.g.:

               $err = &Net::SSLeay::ERR_get_error;

       Following new functions behave in perlish way:

               $got = Net::SSLeay::read($ssl);
                                           # Performs SSL_read, but returns $got
                                           # resized according to data received.
                                           # Returns undef on failure.

               Net::SSLeay::write($ssl, $foo) || die;
                                           # Performs SSL_write, but automatically
                                           # figures out the size of $foo

       In order to use the low level API you should start your programs with the following encantation:

               use Net::SSLeay qw(die_now die_if_ssl_error);
               Net::SSLeay::load_error_strings();
               Net::SSLeay::SSLeay_add_ssl_algorithms();   # Important!
               Net::SSLeay::randomize();

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

               Net::SSLeay:connect($ssl) or die_now("Failed SSL connect ($!)");
               Net::SSLeay::write($ssl, "foo") or die_if_ssl_error("SSL write ($!)");

       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 to your
       main name space.

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

       Sockets

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

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

       You should also use "$|=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 socket selected for reading (just keep on
       selecting and trying to read). Net::SSLeay.pm is no different from the C language OpenSSL in this
       respect.

       Callbacks

       At this moment the implementation of verify_callback is crippeled in the sense that at any given time
       there can be only one call back which is shared by all SSL contexts, sessions and connections. This
       is due to having to keep the reference to the perl call back in a static variable so that the
       callback C glue can find it. To remove this restriction would require either a more complex data
       structure (like a hash?) in XSUB to map the call backs to their owners or, cleaner, adding a context
       pointer in the SSL structure. This context would then be passed to the C callback, which in our case
       would be the glue to look up the proper Perl function from the context and call it.

       ---- inaccurate ---- The verify call back looks like this in C:

               int (*callback)(int ok,X509 *subj_cert,X509 *issuer_cert,
                               int depth,int errorcode,char *arg,STACK *cert_chain)

       The corresponding Perl function should be something like this:

               sub verify {
                   my ($ok, $subj_cert, $issuer_cert, $depth, $errorcode,
                       $arg, $chain) = @_;
                   print "Verifying certificate...\n";
                       ...
                   return $ok;
               }

       It is used like this:

               Net::SSLeay::set_verify ($ssl, Net::SSLeay::VERIFY_PEER, \&verify);

       Callbacks for decrypting private keys are implemented, but have the same limitation as the
       verify_callback implementation (one password callback shared between all contexts.)  You might use it
       something like this:

               Net::SSLeay::CTX_set_default_passwd_cb($ctx, sub { "top-secret" });
               Net::SSLeay::CTX_use_PrivateKey_file($ctx, "key.pem",
                                                    Net::SSLeay::FILETYPE_PEM)
                   or die "Error reading private key";
               Net::SSLeay::CTX_set_default_passwd_cb($ctx, undef);

       No other callbacks are implemented. You do not need to use any callback for simple (i.e. normal)
       cases where the SSLeay built-in verify mechanism satisfies your needs.

       It is desirable to reset these callbacks to undef immediately after use to prevent thread safety
       problems and crashes on exit that can occur if different threads set different callbacks.

       ---- end inaccurate ----If ---If

       If you want to use callback stuff, see examples/callback.pl! Its the only one I am able to make work
       reliably.

       X509 and RAND stuff

       This module largely lacks interface to the X509 and RAND routines, but as I was lazy and needed them,
       the following kludges are implemented:

           $x509_name = Net::SSLeay::X509_get_subject_name($x509_cert);
           $x509_name = Net::SSLeay::X509_get_issuer_name($x509_cert);
           print Net::SSLeay::X509_NAME_oneline($x509_name);
           $text = Net::SSLeay::X509_NAME_get_text_by_NID($name, $nid);

           Net::SSLeay::RAND_seed($buf);   # Perlishly figures out buf size
           Net::SSLeay::RAND_bytes($buf, $num);
           Net::SSLeay::RAND_pseudo_bytes($buf, $num);
           Net::SSLeay::RAND_add($buf, $num, $entropy);
           Net::SSLeay::RAND_poll();
           Net::SSLeay::RAND_status();
           Net::SSLeay::RAND_cleanup();
           Net::SSLeay::RAND_file_name($num);
           Net::SSLeay::RAND_load_file($file_name, $how_many_bytes);
           Net::SSLeay::RAND_write_file($file_name);
           Net::SSLeay::RAND_egd($path);
           Net::SSLeay::RAND_egd_bytes($path, $bytes);

       Actually you should consider using the following helper functions:

           print Net::SSLeay::dump_peer_certificate($ssl);
           Net::SSLeay::randomize();

       RSA interface

       Some RSA functions are available:

       $rsakey = Net::SSLeay::RSA_generate_key(); Net::SSLeay::CTX_set_tmp_rsa($ctx, $rsakey);
       Net::SSLeay::RSA_free($rsakey);

       BIO interface

       Some BIO functions are available:

         Net::SSLeay::BIO_s_mem();
         $bio = Net::SSLeay::BIO_new(BIO_s_mem())
         $bio = Net::SSLeay::BIO_new_file($filename, $mode);
         Net::SSLeay::BIO_free($bio)
         $count = Net::SSLeay::BIO_write($data);
         $data = Net::SSLeay::BIO_read($bio);
         $data = Net::SSLeay::BIO_read($bio, $maxbytes);
         $is_eof = Net::SSLeay::BIO_eof($bio);
         $count = Net::SSLeay::BIO_pending($bio);
         $count = Net::SSLeay::BIO_wpending ($bio);

       Low level API

       Some very low level API functions are available:
           $client_random = &Net::SSLeay::get_client_random($ssl);
           $server_random = &Net::SSLeay::get_server_random($ssl);
           $session = &Net::SSLeay::get_session($ssl);
           $master_key = &Net::SSLeay::SESSION_get_master_key($session);

       HTTP (without S) API

       Over the years it has become clear that it would be convenient to use the light weight flavour API of
       Net::SSLeay also for normal http (see LWP for 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.

         use Net::SSLeay, qw(get_http post_http tcpcat
                             get_httpx post_httpx tcpxcat
                             make_headers make_form);

         ($page, $result, %headers) =
                = get_http('www.bacus.pt', 443, '/protected.html',
                     make_headers(Authorization =>
                                  'Basic ' . MIME::Base64::encode("$user:$pass",''))
                     );

         ($page, $response, %reply_headers)
                = post_http('www.bacus.pt', 443, '/foo.cgi', '',
                       make_form(OK   => '1',
                                 name => 'Sampo'
                       ));

         ($reply, $err) = tcpcat($host, $port, $request);

         ($page, $result, %headers) =
                = get_httpx($usessl, 'www.bacus.pt', 443, '/protected.html',
                     make_headers(Authorization =>
                                  'Basic ' . MIME::Base64::encode("$user:$pass",''))
                     );

         ($page, $response, %reply_headers)
                = post_httpx($usessl, 'www.bacus.pt', 443, '/foo.cgi', '',
                       make_form(OK   => '1',  name => 'Sampo' ));

         ($reply, $err, $server_cert) = tcpxcat($usessl, $host, $port, $request);

       As can be seen, the "x" family of APIs takes as first argument a flag which indicated whether SSL is
       used or not.

EXAMPLES
       One very good example is to look at the implementation of sslcat() in the SSLeay.pm file.

       Following is a simple SSLeay client (with too little error checking :-(

           #!/usr/local/bin/perl
           use Socket;
           use Net::SSLeay qw(die_now die_if_ssl_error) ;
           Net::SSLeay::load_error_strings();
           Net::SSLeay::SSLeay_add_ssl_algorithms();
           Net::SSLeay::randomize();

           ($dest_serv, $port, $msg) = @ARGV;      # Read command line
           $port = getservbyname ($port, 'tcp') unless $port =~ /^\d+$/;
           $dest_ip = gethostbyname ($dest_serv);
           $dest_serv_params  = sockaddr_in($port, $dest_ip);

           socket  (S, &AF_INET, &SOCK_STREAM, 0)  or die "socket: $!";
           connect (S, $dest_serv_params)          or die "connect: $!";
           select  (S); $| = 1; select (STDOUT);   # Eliminate STDIO buffering

           # The network connection is now open, lets fire up SSL

           $ctx = Net::SSLeay::CTX_new() or die_now("Failed to create SSL_CTX $!");
           Net::SSLeay::CTX_set_options($ctx, &Net::SSLeay::OP_ALL)
                and die_if_ssl_error("ssl ctx set options");
           $ssl = Net::SSLeay::new($ctx) or die_now("Failed to create SSL $!");
           Net::SSLeay::set_fd($ssl, fileno(S));   # Must use fileno
           $res = Net::SSLeay::connect($ssl) and die_if_ssl_error("ssl connect");
           print "Cipher `" . Net::SSLeay::get_cipher($ssl) . "'\n";

           # Exchange data

           $res = Net::SSLeay::write($ssl, $msg);  # Perl knows how long $msg is
           die_if_ssl_error("ssl write");
           CORE::shutdown S, 1;  # Half close --> No more output, sends EOF to server
           $got = Net::SSLeay::read($ssl);         # Perl returns undef on failure
           die_if_ssl_error("ssl read");
           print $got;

           Net::SSLeay::free ($ssl);               # Tear down connection
           Net::SSLeay::CTX_free ($ctx);
           close S;

       Following is a simple SSLeay echo server (non forking):

           #!/usr/local/bin/perl -w
           use Socket;
           use Net::SSLeay qw(die_now die_if_ssl_error);
           Net::SSLeay::load_error_strings();
           Net::SSLeay::SSLeay_add_ssl_algorithms();
           Net::SSLeay::randomize();

           $our_ip = "\0\0\0\0"; # Bind to all interfaces
           $port = 1235;
           $sockaddr_template = 'S n a4 x8';
           $our_serv_params = pack ($sockaddr_template, &AF_INET, $port, $our_ip);

           socket (S, &AF_INET, &SOCK_STREAM, 0)  or die "socket: $!";
           bind (S, $our_serv_params)             or die "bind:   $!";
           listen (S, 5)                          or die "listen: $!";
           $ctx = Net::SSLeay::CTX_new ()         or die_now("CTX_new ($ctx): $!");
           Net::SSLeay::CTX_set_options($ctx, &Net::SSLeay::OP_ALL)
                and die_if_ssl_error("ssl ctx set options");

           # Following will ask password unless private key is not encrypted
           Net::SSLeay::CTX_use_RSAPrivateKey_file ($ctx, 'plain-rsa.pem',
                                                    &Net::SSLeay::FILETYPE_PEM);
           die_if_ssl_error("private key");
           Net::SSLeay::CTX_use_certificate_file ($ctx, 'plain-cert.pem',
                                                  &Net::SSLeay::FILETYPE_PEM);
           die_if_ssl_error("certificate");

           while (1) {
               print "Accepting connections...\n";
               ($addr = accept (NS, S))           or die "accept: $!";
               select (NS); $| = 1; select (STDOUT);  # Piping hot!

               ($af,$client_port,$client_ip) = unpack($sockaddr_template,$addr);
               @inetaddr = unpack('C4',$client_ip);
               print "$af connection from " .
                   join ('.', @inetaddr) . ":$client_port\n";

               # We now have a network connection, lets fire up SSLeay...

               $ssl = Net::SSLeay::new($ctx)      or die_now("SSL_new ($ssl): $!");
               Net::SSLeay::set_fd($ssl, fileno(NS));

               $err = Net::SSLeay::accept($ssl) and die_if_ssl_error('ssl accept');
               print "Cipher `" . Net::SSLeay::get_cipher($ssl) . "'\n";

               # Connected. Exchange some data.

               $got = Net::SSLeay::read($ssl);     # Returns undef on fail
               die_if_ssl_error("ssl read");
               print "Got `$got' (" . length ($got) . " chars)\n";

               Net::SSLeay::write ($ssl, uc ($got)) or die "write: $!";
               die_if_ssl_error("ssl write");

               Net::SSLeay::free ($ssl);           # Tear down connection
               close NS;
           }

       Yet another echo server. This one runs from /etc/inetd.conf so it avoids all the socket code
       overhead. Only caveat is opening 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.

           #!/usr/local/bin/perl
           # /etc/inetd.conf
           #    ssltst stream tcp nowait root /path/to/server.pl server.pl
           # /etc/services
           #    ssltst         1234/tcp

           use Net::SSLeay qw(die_now die_if_ssl_error);
           Net::SSLeay::load_error_strings();
           Net::SSLeay::SSLeay_add_ssl_algorithms();
           Net::SSLeay::randomize();

           chdir '/key/dir' or die "chdir: $!";
           $| = 1;  # Piping hot!
           open LOG, ">>/dev/console" or die "Can't open log file $!";
           select LOG; print "server.pl started\n";

           $ctx = Net::SSLeay::CTX_new()     or die_now "CTX_new ($ctx) ($!)";
           $ssl = Net::SSLeay::new($ctx)     or die_now "new ($ssl) ($!)";
           Net::SSLeay::set_options($ssl, &Net::SSLeay::OP_ALL)
                and die_if_ssl_error("ssl set options");

           # We get already open network connection from inetd, now we just
           # need to attach SSLeay to STDIN and STDOUT
           Net::SSLeay::set_rfd($ssl, fileno(STDIN));
           Net::SSLeay::set_wfd($ssl, fileno(STDOUT));

           Net::SSLeay::use_RSAPrivateKey_file ($ssl, 'plain-rsa.pem',
                                                &Net::SSLeay::FILETYPE_PEM);
           die_if_ssl_error("private key");
           Net::SSLeay::use_certificate_file ($ssl, 'plain-cert.pem',
                                              &Net::SSLeay::FILETYPE_PEM);
           die_if_ssl_error("certificate");

           Net::SSLeay::accept($ssl) and die_if_ssl_err("ssl accept: $!");
           print "Cipher `" . Net::SSLeay::get_cipher($ssl) . "'\n";

           $got = Net::SSLeay::read($ssl);
           die_if_ssl_error("ssl read");
           print "Got `$got' (" . length ($got) . " chars)\n";

           Net::SSLeay::write ($ssl, uc($got)) or die "write: $!";
           die_if_ssl_error("ssl write");

           Net::SSLeay::free ($ssl);         # Tear down the connection
           Net::SSLeay::CTX_free ($ctx);
           close LOG;

       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)

LIMITATIONS
       Net::SSLeay::read uses 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:

           $reply = '';
           while ($got = Net::SSLeay::read($ssl)) {
               last if print_errs('SSL_read');
               $reply .= $got;
           }

       Although there is no built-in limit in Net::SSLeay::write, the network packet size limitation applies
       here as well, thus use:

           $written = 0;

           while ($written < length($message)) {
               $written += Net::SSLeay::write($ssl, substr($message, $written));
               last if print_errs('SSL_write');
           }

       Or alternatively you can just use the following convinence functions:

           Net::SSLeay::ssl_write_all($ssl, $message) or die "ssl write failure";
           $got = Net::SSLeay::ssl_read_all($ssl) or die "ssl read failure";

KNOWN BUGS AND CAVEATS
       Autoloader emits

           Argument "xxx" isn't numeric in entersub at blib/lib/Net/SSLeay.pm'

       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 eay 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.

       Callback and certificate verification stuff is generally too little tested.

       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 I've been suggested that cryptorand daemon from
       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

          1. Entropy Gathering Daemon (EGD) at http://www.lothar.com/tech/crypto/
          2. Pseudo-random number generating daemon (PRNGD) at
               http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html

       If you are using the low level API functions to communicate with other SSL implementations, you would
       do well to call

           Net::SSLeay::CTX_set_options($ctx, &Net::SSLeay::OP_ALL)
                and die_if_ssl_error("ssl ctx set options");

       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 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 short coming, but using 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.

          $Net::SSLeay::ssl_version = 2;  # Insist on SSLv2
          $Net::SSLeay::ssl_version = 3;  # Insist on SSLv3
          $Net::SSLeay::ssl_version = 10; # Insist on TLSv1

       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 SSL handshake level), try this option before mailing me.

       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 after that
       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
       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.

DIAGNOSTICS
       "Random number generator not seeded!!!"
         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.

       "open_tcp_connection: destination host not found:`server' (port 123) ($!)"
         Name lookup for host named `server' failed.

       "open_tcp_connection: failed `server', 123 ($!)"
         The name was resolved, but establising the TCP connection failed.

       "msg 123: 1 - error:140770F8:SSL routines:SSL23_GET_SERVER_HELLO:unknown proto"
         SSLeay error string. First (123) number is PID, 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.

       "msg 123: 1 - error:02001002::lib(2) :func(1) :reason(2)"
         The same as above, but you didn't call load_error_strings() so SSLeay
         couldn't verbosely explain the error. You can still find out what it
         means with this command:

            /usr/local/ssl/bin/ssleay errstr 02001002

       Password is being asked for private key
         This is normal behaviour if your private key is encrypted. Either
         you have to supply the password or you have to use 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).

REPORTING BUGS AND SUPPORT
       Bug reports, patch submission, feature requests, subversion access to the latest source code etc can
       be obtained at http://alioth.debian.org/projects/net-ssleay

       The developer mailing list (for people interested in contributin to the source code) can be found at
       http://lists.alioth.debian.org/mailman/listinfo/net-ssleay-devel

       Commercial support for Net::SSLeay may be obtained from

          Symlabs (netssleay@symlabs.com)
          Tel: +351-214.222.630
          Fax: +351-214.222.637

VERSION
       This man page documents version 1.24, released on 18.8.2003.

       There are currently two perl modules for using OpenSSL C library: Net::SSLeay (maintaned by me) and
       SSLeay (maintained by OpenSSL team). This module is the Net::SSLeay variant.

       At the time of making this release, Eric's module was still quite sketchy and could not be used for
       real work, thus I felt motivated to make this maintenance release. This module is not planned to
       evolve to contain any further functionality, i.e. I will concentrate on just making a simple SSL
       connection over TCP socket. Presumably Eric's own module will offer full SSLeay API one day.

       This module uses OpenSSL-0.9.6c. It does not work with any earlier version and there is no guarantee
       that it will work with later versions either, though as long as C API does not change, it should.
       This module requires perl5.005, or 5.6.0 (or better?) though I believe it would build with any
       perl5.002 or newer.

AUTHOR
       Originally written by Sampo Kellomaeki <sampo@symlabs.com> Maintained by Mike McCauley and Florian
       Ragwitz since November 2005

COPYRIGHT
       Copyright (c) 1996-2003 Sampo Kellomaeki <sampo@symlabs.com> Copyright (C) 2005 Florian Ragwitz
       <rafl@debian.org> Copyright (C) 2005 Mike McCauley <mikem@open.com.au> All Rights Reserved.

       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.

SEE ALSO
         Net::SSLeay::Handle                      - File handle interface
         ./Net_SSLeay/examples                    - Example servers and a clients
         <http://symlabs.com/Net_SSLeay/index.html  - Net::SSLeay.pm home
         <http://symlabs.com/Net_SSLeay/smime.html  - Another module using OpenSSL
         <http://www.openssl.org/                - OpenSSL source, documentation, etc
         openssl-users-request@openssl.org        - General OpenSSL mailing list
         <http://home.netscape.com/newsref/std/SSL.html  - SSL Draft specification
         <http://www.w3c.org                     - HTTP specifications
         <http://www.ietf.org/rfc/rfc2617.txt    - How to send password
         <http://www.lothar.com/tech/crypto/     - Entropy Gathering Daemon (EGD)
         <http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html
                                  - pseudo-random number generating daemon (PRNGD)
         perl(1)
         perlref(1)
         perllol(1)
         perldoc ~openssl/doc/ssl/SSL_CTX_set_verify.pod



perl v5.8.8                                      2005-12-20                                        SSLeay(3)

Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.