Fix SSL_peek and SSL_pending.

     result of the server certificate verification.)

     [Lutz Jaenicke]

  *) Disable ssl2_peek and ssl3_peek (i.e., both implementations

     of SSL_peek) because they both are completely broken.

     For fixing this, the internal read functions now have an additional

     'peek' parameter, but the actual peek functionality has not

     yet been implemented.

  *) Fix ssl3_pending: If the record in s->s3->rrec is not of type

     SSL3_RT_APPLICATION_DATA, return 0.

     [Bodo Moeller]

  *) Fix SSL_peek:

     Both ssl2_peek and ssl3_peek, which were totally broken in earlier

     releases, have been re-implemented by renaming the previous

     implementations of ssl2_read and ssl3_read to ssl2_read_internal

     and ssl3_read_internal, respectively, and adding 'peek' parameters

     to them.  The new ssl[23]_{read,peek} functions are calls to

     ssl[23]_read_internal with the 'peek' flag set appropriately.

     A 'peek' parameter has also been added to ssl3_read_bytes, which

     does the actual work for ssl3_read_internal.

     [Bodo Moeller]

  *) Increase BN_CTX_NUM (the number of BIGNUMs in a BN_CTX) to 16.

SSL_get_error() returns a result code (suitable for the C "switch"

statement) for a preceding call to SSL_connect(), SSL_accept(),

SSL_read(), or SSL_write() on B<ssl>.  The value returned by that

TLS/SSL I/O function must be passed to SSL_get_error() in parameter

SSL_read(), SSL_peek(), or SSL_write() on B<ssl>.  The value returned by

that TLS/SSL I/O function must be passed to SSL_get_error() in parameter

B<ret>.

In addition to B<ssl> and B<ret>, SSL_get_error() inspects the

=item SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE

The operation did not complete; the same TLS/SSL I/O function should be

called again later.  There will be protocol progress if, by then, the

underlying B<BIO> has data available for reading (if the result code is

B<SSL_ERROR_WANT_READ>) or allows writing data (B<SSL_ERROR_WANT_WRITE>). 

For socket B<BIO>s (e.g. when SSL_set_fd() was used) this means that

select() or poll() on the underlying socket can be used to find out

when the TLS/SSL I/O function should be retried.

called again later.  If, by then, the underlying B<BIO> has data

available for reading (if the result code is B<SSL_ERROR_WANT_READ>)

or allows writing data (B<SSL_ERROR_WANT_WRITE>), then some TLS/SSL

protocol progress will take place, i.e. at least part of an TLS/SSL

record will be read or written.  Note that the retry may again lead to

a B<SSL_ERROR_WANT_READ> or B<SSL_ERROR_WANT_WRITE> condition.

There is no fixed upper limit for the number of iterations that

may be necessary until progress becomes visible at application

protocol level.

For socket B<BIO>s (e.g. when SSL_set_fd() was used), select() or

poll() on the underlying socket can be used to find out when the

TLS/SSL I/O function should be retried.

Caveat: Any TLS/SSL I/O function can lead to either of

B<SSL_ERROR_WANT_READ> and B<SSL_ERROR_WANT_WRITE>, i.e. SSL_read()

may want to write data and SSL_write() may want to read data.

B<SSL_ERROR_WANT_READ> and B<SSL_ERROR_WANT_WRITE>.  In particular,

SSL_read() or SSL_peek() may want to write data and SSL_write() may want

to read data.  This is mainly because TLS/SSL handshakes may occur at any

time during the protocol (initiated by either the client or the server);

SSL_read(), SSL_peek(), and SSL_write() will handle any pending handshakes.

=item SSL_ERROR_WANT_X509_LOOKUP

read containing more TLS/SSL records; these are ignored by

SSL_pending().

SSL_pending() does not check if the record type of pending data is

application data.

Up to OpenSSL 0.9.6, SSL_pending() does not check if the record type

of pending data is application data.

=head1 SEE ALSO

			n=len;

		memcpy(buf,s->s2->ract_data,(unsigned int)n);

		if (!peek)

			{

			s->s2->ract_data_length-=n;

			s->s2->ract_data+=n;

			if (s->s2->ract_data_length == 0)

				s->rstate=SSL_ST_READ_HEADER;

			}

		return(n);

		}

	/* s->s2->ract_data_length == 0

	 * 

	 * Fill the buffer, then goto ssl2_read_again.

	 */

	if (s->rstate == SSL_ST_READ_HEADER)

		{

		if (s->first_packet)

		INC32(s->s2->read_sequence); /* expect next number */

		/* s->s2->ract_data is now available for processing */

#if 1

		/* How should we react when a packet containing 0

		 * bytes is received?  (Note that SSLeay/OpenSSL itself

		 * never sends such packets; see ssl2_write.)

		 * Returning 0 would be interpreted by the caller as

		 * indicating EOF, so it's not a good idea.

		 * Instead, we just continue reading.  Note that using

		 * select() for blocking sockets *never* guarantees

		/* Possibly the packet that we just read had 0 actual data bytes.

		 * (SSLeay/OpenSSL itself never sends such packets; see ssl2_write.)

		 * In this case, returning 0 would be interpreted by the caller

		 * as indicating EOF, so it's not a good idea.  Instead, we just

		 * continue reading; thus ssl2_read_internal may have to process

		 * multiple packets before it can return.

		 *

		 * [Note that using select() for blocking sockets *never* guarantees

		 * that the next SSL_read will not block -- the available

		 * data may contain incomplete packets, and except for SSL 2

		 * renegotiation can confuse things even more. */

		 * data may contain incomplete packets, and except for SSL 2,

		 * renegotiation can confuse things even more.] */

		goto ssl2_read_again; /* This should really be

		                       * "return ssl2_read(s,buf,len)",

		                       * denial-of-service attacks if a

		                       * C compiler is used that does not

		                       * recognize end-recursion. */

#else

		/* If a 0 byte packet was sent, return 0, otherwise

		 * we play havoc with people using select with

		 * blocking sockets.  Let them handle a packet at a time,

		 * they should really be using non-blocking sockets. */

		if (s->s2->ract_data_length == 0)

			return(0);

		return(ssl2_read(s,buf,len));

#endif

		}

	else

		{

		return(NULL);

	}

/* The problem is that it may not be the correct record type */

int ssl3_pending(SSL *s)

	{

	return(s->s3->rrec.length);

	return (s->s3->rrec.type == SSL3_RT_APPLICATION_DATA) ? s->s3->rrec.length : 0;

	}

int ssl3_new(SSL *s)