Opcje wyszukiwania podręcznika man:
Lista stron man zaczynających się od znaku:
A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Y   Z   ALPHA   NUM   OTHER   ALL
Net::SSLeay(3pm)      User Contributed Perl Documentation     Net::SSLeay(3pm)

       Net::SSLeay - Perl extension for using OpenSSL

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

         ($page) = get_https('', 443, '/');                 # 1

         ($page, $response, %reply_headers)
                = get_https('', 443, '/',                   # 2
                       make_headers(User-Agent => 'Cryptozilla/5.0b1',
                                    Referer    => ''

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

         ($page, $response, %reply_headers)
                = post_https('', 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

       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

       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

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

       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. RFC-2617).

       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

       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('', 443, '/');
         for ($i = 0; $i < $#headers; $i+=2) {
             print "$headers[$i] = " . $headers[$i+1] . "\n";

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

         ($page, $response, %headers_ref, $server_cert)
           = get_https4('', 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 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('', 443, '/');
         if (!defined($server_cert) || ($server_cert == 0)) {
             warn "Subject Name: undefined, Issuer  Name: undefined";
         } else {
             warn 'Subject Name: '
                 . Net::SSLeay::X509_NAME_oneline(
                     . 'Issuer  Name: '
                         . Net::SSLeay::X509_NAME_oneline(

       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

       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('', 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('', 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

       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('', 8080);
         ($page) = get_https('', 443, '/');

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

         Net::SSLeay::set_proxy('', 8080, 'joe', 'salainen');
         ($page, $result, %headers) =
                = get_https('', 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:


       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::CTX_get_cert_store($ssl, $crl);
           } else {
               error reading CRL....

       Convenience routines

       To be used with Low level API

           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
       "" 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

       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,

       In Perl:

               use Net::SSLeay;

               $err = Net::SSLeay::set_verify ($ssl,

       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 incantation:

               use Net::SSLeay qw(die_now die_if_ssl_error);
               Net::SSLeay::SSLeay_add_ssl_algorithms();    # Important!
               Net::SSLeay::ENGINE_load_builtin_engines();  # If you want built-in engines
               Net::SSLeay::ENGINE_register_all_complete(); # If you want built-in engines

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


       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 set $| to 1 to eliminate STDIO buffering so you do not
       get confused if you use perl I/O functions to manipulate your socket

       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" is no different from the C language
       OpenSSL in this respect.


       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

               Net::SSLeay::CTX_set_default_passwd_cb($ctx, sub { "top-secret" });
               Net::SSLeay::CTX_use_PrivateKey_file($ctx, "key.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 you want to use callback stuff, see examples/! 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);

           ($type1, $subject1, $type2, $subject2, ...) =

           subjectAltName types as per x509v3.h GEN_*, for example
           GEN_DNS or GEN_IPADD which can be imported.

           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_load_file($file_name, $how_many_bytes);
           Net::SSLeay::RAND_egd_bytes($path, $bytes);

       Actually you should consider using the following helper functions:

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

       RSA interface

       Some RSA functions are available:

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

       BIO interface

       Some BIO functions are available:

           $bio = Net::SSLeay::BIO_new(BIO_s_mem())
           $bio = Net::SSLeay::BIO_new_file($filename, $mode);
           $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);
           Net::SSLeay::SESSION_set_master_key($session, $master_secret);
           $keyblocksize = Net::SSLeay::get_keyblock_size($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('', 443, '/protected.html',
                     make_headers(Authorization =>
                                  'Basic ' . MIME::Base64::encode("$user:$pass",''))

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

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

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

         ($page, $response, %reply_headers)
                = post_httpx($usessl, '', 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.

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

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

           use Socket;
           use Net::SSLeay qw(die_now die_if_ssl_error) ;

           ($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);

           $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',
           die_if_ssl_error("private key");
           Net::SSLeay::CTX_use_certificate_file ($ctx, 'plain-cert.pem',

           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.

           # /etc/inetd.conf
           #    ssltst stream tcp nowait root /path/to/
           # /etc/services
           #    ssltst         1234/tcp

           use Net::SSLeay qw(die_now die_if_ssl_error);

           chdir '/key/dir' or die "chdir: $!";
           $| = 1;  # Piping hot!
           open LOG, ">>/dev/console" or die "Can't open log file $!";
           select LOG; print " 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',
           die_if_ssl_error("private key");
           Net::SSLeay::use_certificate_file ($ssl, 'plain-cert.pem',

           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

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

       "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";

       Autoloader emits

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

       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

       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

       2.  Pseudo-random number generating daemon (PRNGD) at

       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

       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,

       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.

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

       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
           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 for the FAQ that explains how to do
           this (or just study examples/ which is used during "make
           test" to do just that).

       Bug reports, patch submission, feature requests, subversion access to
       the latest source code etc can be obtained at

       The developer mailing list (for people interested in contributin to the
       source code) can be found at

       Commercial support for Net::SSLeay may be obtained from

          Symlabs (
          Tel: +351-214.222.630
          Fax: +351-214.222.637

       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 Perl 5.005 or newer, though I believe it would build with Perl
       5.002 or newer.

       Please report any bugs or feature requests to " at", or through the web interface at
       <>.  I
       will be notified, and then you'll automatically be notified of progress
       on your bug as I make changes.

       You can find documentation for this module with the "perldoc" command.

           perldoc Net::SSLeay

       You can also look for information at:

       o   AnnoCPAN: Annotated CPAN documentation


       o   CPAN Ratings


       o   RT: CPAN's request tracker


       o   Search CPAN


       Maintained by Mike McCauley and Florian Ragwitz since November 2005

       Originally written by Sampo Kellomaeki <>

       Copyright (c) 1996-2003 Sampo Kellomaeki <>

       Copyright (C) 2005-2006 Florian Ragwitz <>

       Copyright (C) 2005 Mike McCauley <>

       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

       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

       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.

         Net::SSLeay::Handle                      - File handle interface
         ./Net_SSLeay/examples                    - Example servers and a clients
         <>  - home
         <>  - Another module using OpenSSL
         <>                - OpenSSL source, documentation, etc        - General OpenSSL mailing list
         <>  - SSL Draft specification
         <>                     - HTTP specifications
         <>    - How to send password
         <>     - Entropy Gathering Daemon (EGD)
                                  - pseudo-random number generating daemon (PRNGD)
         perldoc ~openssl/doc/ssl/SSL_CTX_set_verify.pod

perl v5.10.0                      2008-07-26                  Net::SSLeay(3pm)

Time taken: 0.00083 seconds

Created with the man page lookup class by Andrew Collington,