Add -prexit command to s_client and patch some BIO

functions so it doesn't crash. Document s_client.

apps/s_client.c

@@ -176,6 +176,7 @@ int MAIN(int argc, char **argv)
 	int write_tty,read_tty,write_ssl,read_ssl,tty_on,ssl_pending;
 	SSL_CTX *ctx=NULL;
 	int ret=1,in_init=1,i,nbio_test=0;
+	int prexit = 0;
 	SSL_METHOD *meth=NULL;
 	BIO *sbio;
 #ifdef WINDOWS
@@ -245,6 +246,8 @@ int MAIN(int argc, char **argv)
 			if (--argc < 1) goto bad;
 			cert_file= *(++argv);
 			}
+		else if	(strcmp(*argv,"-prexit") == 0)
+			prexit=1;
 		else if	(strcmp(*argv,"-crlf") == 0)
 			crlf=1;
 		else if	(strcmp(*argv,"-quiet") == 0)
@@ -735,6 +738,7 @@ shut:
 	SHUTDOWN(SSL_get_fd(con));
 	ret=0;
 end:
+	if(prexit) print_stuff(bio_c_out,con,1);
 	if (con != NULL) SSL_free(con);
 	if (con2 != NULL) SSL_free(con2);
 	if (ctx != NULL) SSL_CTX_free(ctx);

crypto/bio/bio.h

@@ -283,9 +283,6 @@ typedef struct bio_f_buffer_ctx_struct
 #define BIO_CONN_S_NBIO			8
 /*#define BIO_CONN_get_param_hostname	BIO_ctrl */
 
-#define BIO_number_read(b)	((b)->num_read)
-#define BIO_number_written(b)	((b)->num_write)
-
 #define BIO_C_SET_CONNECT			100
 #define BIO_C_DO_STATE_MACHINE			101
 #define BIO_C_SET_NBIO				102
@@ -485,6 +482,8 @@ int BIO_set_ex_data(BIO *bio,int idx,char *data);
 char *BIO_get_ex_data(BIO *bio,int idx);
 int BIO_get_ex_new_index(long argl, char *argp, int (*new_func)(),
 	int (*dup_func)(), void (*free_func)());
+unsigned long BIO_number_read(BIO *bio);
+unsigned long BIO_number_written(BIO *bio);
 
 #  if defined(WIN16) && defined(_WINDLL)
 BIO_METHOD *BIO_s_file_internal(void);

crypto/bio/bio_lib.c

@@ -494,3 +494,14 @@ char *BIO_get_ex_data(BIO *bio, int idx)
 	return(CRYPTO_get_ex_data(&(bio->ex_data),idx));
 	}
 
+unsigned long BIO_number_read(BIO *bio)
+{
+	if(bio) return bio->num_read;
+	return 0;
+}
+
+unsigned long BIO_number_written(BIO *bio)
+{
+	if(bio) return bio->num_write;
+	return 0;
+}

doc/man/pkcs12.pod

@@ -8,35 +8,35 @@ pkcs12 - PKCS#12 file utility
 =head1 SYNOPSIS
 
 B<openssl> B<pkcs12>
-B<-export>
-B<-chain>
-B<-inkey file>
-B<-certfile f>
-B<-name name>
-B<-caname name>
-B<-in  infile>
-B<-out outfile>
-B<-noout>
-B<-nomacver>
-B<-nocerts>
-B<-clcerts>
-B<-cacerts>
-B<-nokeys>
-B<-info>
-B<-des>
-B<-des3>
-B<-idea>
-B<-nodes>
-B<-noiter>
-B<-maciter>
-B<-twopass>
-B<-descert>
-B<-certpbe>
-B<-keypbe>
-B<-keyex>
-B<-keysig>
-B<-password pass>
-B<-envpass pass>
+[B<-export>]
+[B<-chain>]
+[B<-inkey filename>]
+[B<-certfile filename>]
+[B<-name name>]
+[B<-caname name>]
+[B<-in filename>]
+[B<-out filename>]
+[B<-noout>]
+[B<-nomacver>]
+[B<-nocerts>]
+[B<-clcerts>]
+[B<-cacerts>]
+[B<-nokeys>]
+[B<-info>]
+[B<-des>]
+[B<-des3>]
+[B<-idea>]
+[B<-nodes>]
+[B<-noiter>]
+[B<-maciter>]
+[B<-twopass>]
+[B<-descert>]
+[B<-certpbe>]
+[B<-keypbe>]
+[B<-keyex>]
+[B<-keysig>]
+[B<-password password>]
+[B<-envpass var>]
 
 =head1 DESCRIPTION
 

doc/man/pkcs8.pod

@@ -165,7 +165,7 @@ They only offer 56 bits of protection since they both use DES.
 
 These algorithms are not mentioned in the original PKCS#5 v1.5 specification
 but they use the same key derivation algorithm and are supported by some
-software. They are mentioned in PKCS#5 v1.5. They use either 64 bit RC2 or
+software. They are mentioned in PKCS#5 v2.0. They use either 64 bit RC2 or
 56 bit DES.
 
 =item B<PBE-SHA1-RC4-128 PBE-SHA1-RC4-40 PBE-SHA1-3DES PBE-SHA1-2DES PBE-SHA1-RC2-128 PBE-SHA1-RC2-40>

doc/man/s_client.pod

@@ -0,0 +1,209 @@
+
+=pod
+
+=head1 NAME
+
+s_client - SSL/TLS client program
+
+=head1 SYNOPSIS
+
+B<openssl> B<s_client>
+[B<-connect> host:port>]
+[B<-verify depth]
+[B<-cert filename>]
+[B<-key filename>]
+[B<-CApath directory>]
+[B<-CAfile filename>]
+[B<-reconnect>]
+[B<-pause>]
+[B<-showcerts>]
+[B<-debug>]
+[B<-nbio_test>]
+[B<-state>]
+[B<-nbio>]
+[B<-crlf>]
+[B<-quiet>]
+[B<-ssl2>]
+[B<-ssl3>]
+[B<-tls1>]
+[B<-no_ssl2>]
+[B<-no_ssl3>]
+[B<-no_tls1>]
+[B<-bugs>]
+[B<-cipher cipherlist>]
+
+=head1 DESCRIPTION
+
+The B<s_client> command implements a generic SSL/TLS client which connects
+to a remote host using SSL/TLS. It is a I<very> useful diagnostic tool for
+SSL servers.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<-connect host:port>
+
+This specifies the host and optional port to connect to. If not specified
+then an attempt is made to connect to the local host on port 4433.
+
+=item B<-cert certname>
+
+The certificate to use, if one is requested by the server. The default is
+not to use a certificate.
+
+=item B<-key keyfile>
+
+The private key to use. If not specified then the certificate file will
+be used.
+
+=item B<-verify depth>
+
+The verify depth to use. This specifies the maximum length of the
+server certificate chain and turns on server certificate verification.
+Currently the verify operation continues after errors so all the problems
+with a certificate chain can be seen. As a side effect the connection
+will never fail due to a server certificate verify failure.
+
+=item B<-CApath directory>
+
+The directory to use for server certificate verification. This directory
+must be in "hash format", see B<verify> for more information. These are
+also used when building the client certificate chain.
+
+=item B<-CAfile file>
+
+A file containing trusted certificates to use during server authentication
+and to use when attempting to build the client certificate chain.
+
+=item B<-reconnect>
+
+reconnects to the same server 5 times using the same session ID, this can
+be used as a test that session caching is working.
+
+=item B<-pause>
+
+pauses 1 second between each read and write call.
+
+=item B<-showcerts>
+
+display the whole server certificate chain: normally only the server
+certificate itself is displayed.
+
+=item B<-prexit>
+
+print session information when the program exits. This will always attempt
+to print out information even if the connection fails. Normally information
+will only be printed out once if the connection succeeds. This option is useful
+because the cipher in use may be renegotiated or the connection may fail
+because a client certificate is required or is requested only after an
+attempt is made to access a certain URL. Note: the output produced by this
+option is not always accurate because a connection might never have been
+established.
+
+=item B<-state>
+
+prints out the SSL session states.
+
+=item B<-debug>
+
+print extensive debugging information including a hex dump of all traffic.
+
+=item B<-nbio_test>
+
+tests non blocking I/O
+
+=item B<-nbio>
+
+turns on non blocking I/O
+
+=item B<-crlf>
+
+this option translated a line feed from the terminal into CR+LF as required
+by some servers.
+
+=item B<-quiet>
+
+inhibit printing of session and certificate information.
+
+=item B<-ssl2>, B<-ssl3>, B<-tls1>, B<-no_ssl2>, B<-no_ssl3>, B<-no_tls1>
+
+these options disable the use of certain SSL or TLS protocols. By default
+the initial handshake uses a method which should be compatible with all
+servers and permit them to use SSL v3, SSL v2 or TLS as appropriate.
+
+Unfortunately there are a lot of ancient and broken servers in use which
+cannot handle this technique and will fail to connect. Some servers only
+work if TLS is turned off with the B<-no_tls> option others will only
+support SSL v2 and may need the B<-ssl2> option.
+
+=item B<-bugs>
+
+there are several known bug in SSL and TLS implementations. Adding this
+option enables various workarounds.
+
+=item B<-cipher cipherlist>
+
+this allows the cipher list sent by the client to be modified. See the
+B<ciphers> command for more information.
+
+=head1 CONNECTED COMMANDS
+
+If a connection is established with an SSL server then any data received
+from the server is displayed and any key presses will be sent to the
+server. If the line begins with an B<R> then the session will be
+renegotiated. If the line begins with a B<Q> the connection will be closed
+down.
+
+=head1 NOTES
+
+B<s_client> can be used to debug SSL servers. To connect to an SSL HTTP
+server the command:
+
+ openssl s_client -connect servername:443
+
+would typically be used (https uses port 443). If the connection succeeds
+then an HTTP command can be given such as "GET /" to retrieve a web page.
+
+If the handshake fails then there are several possible causes, if it is
+nothing obvious like no client certificate then the B<-bugs>, B<-ssl2>,
+B<-ssl3>, B<-tls1>, B<-no_ssl2>, B<-no_ssl3>, B<-no_tls1> can be tried
+in case it is a buggy server. In particular you should play with these
+options B<before> submitting a bug report to an OpenSSL mailing list.
+
+A frequent problem when attempting to get client certificates working
+is that a web client complains it has no certificates or gives an empty
+list to choose from. This is normally because the server is not sending
+the clients certificate authority in its "acceptable CA list" when it
+requests a certificate. By using B<s_client> the CA list can be viewed
+and checked. However some servers only request client authentication
+after a specific URL is requested. To obtain the list in this case it
+is necessary to use the B<-prexit> command and send an HTTP request
+for an appropriate page.
+
+If a certificate is specified on the command line using the B<-cert>
+option it will not be used unless the server specifically requests
+a client certificate. Therefor merely including a client certificate
+on the command line is no guarantee that the certificate works.
+
+If there are problems verifying a server certificate then the
+B<-showcerts> option can be used to show the whole chain.
+
+=head1 BUGS
+
+Because this program has a lot of options and also because some of
+the techniques used are rather old the C source of s_client is rather
+hard to read and not a model of how things should be done. A typical
+SSL client program would be much simpler.
+
+The B<-verify> option should really exit if the server verification
+fails.
+
+The B<-prexit> option is a bit of a hack. We should really report
+information whenever a session is renegotiated.
+
+=head1 SEE ALSO
+
+sess_id(1), s_server(1), ciphers(1)
+
+=cut