ae5c1ca377
podlators 2.5.0 has switched to dying on POD syntax errors. This means
that a bunch of long-standing erroneous POD in the openssl documentation
now leads to fatal errors from pod2man, halting installation.
Unfortunately POD constraints mean that you have to sort numeric lists
in ascending order if they start with 1: you cannot do 1, 0, 2 even if
you want 1 to appear first. I've reshuffled such (alas, I wish there
were a better way but I don't know of one).
(cherry picked from commit 5cc2707742)
75 lines
2.5 KiB
Text
75 lines
2.5 KiB
Text
=pod
|
|
|
|
=head1 NAME
|
|
|
|
SSL_do_handshake - perform a TLS/SSL handshake
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
#include <openssl/ssl.h>
|
|
|
|
int SSL_do_handshake(SSL *ssl);
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
SSL_do_handshake() will wait for a SSL/TLS handshake to take place. If the
|
|
connection is in client mode, the handshake will be started. The handshake
|
|
routines may have to be explicitly set in advance using either
|
|
L<SSL_set_connect_state(3)|SSL_set_connect_state(3)> or
|
|
L<SSL_set_accept_state(3)|SSL_set_accept_state(3)>.
|
|
|
|
=head1 NOTES
|
|
|
|
The behaviour of SSL_do_handshake() depends on the underlying BIO.
|
|
|
|
If the underlying BIO is B<blocking>, SSL_do_handshake() will only return
|
|
once the handshake has been finished or an error occurred, except for SGC
|
|
(Server Gated Cryptography). For SGC, SSL_do_handshake() may return with -1,
|
|
but SSL_get_error() will yield B<SSL_ERROR_WANT_READ/WRITE> and
|
|
SSL_do_handshake() should be called again.
|
|
|
|
If the underlying BIO is B<non-blocking>, SSL_do_handshake() will also return
|
|
when the underlying BIO could not satisfy the needs of SSL_do_handshake()
|
|
to continue the handshake. In this case a call to SSL_get_error() with the
|
|
return value of SSL_do_handshake() will yield B<SSL_ERROR_WANT_READ> or
|
|
B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after
|
|
taking appropriate action to satisfy the needs of SSL_do_handshake().
|
|
The action depends on the underlying BIO. When using a non-blocking socket,
|
|
nothing is to be done, but select() can be used to check for the required
|
|
condition. When using a buffering BIO, like a BIO pair, data must be written
|
|
into or retrieved out of the BIO before being able to continue.
|
|
|
|
=head1 RETURN VALUES
|
|
|
|
The following return values can occur:
|
|
|
|
=over 4
|
|
|
|
=item 0
|
|
|
|
The TLS/SSL handshake was not successful but was shut down controlled and
|
|
by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
|
|
return value B<ret> to find out the reason.
|
|
|
|
=item 1
|
|
|
|
The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
|
|
established.
|
|
|
|
=item E<lt>0
|
|
|
|
The TLS/SSL handshake was not successful because a fatal error occurred either
|
|
at the protocol level or a connection failure occurred. The shutdown was
|
|
not clean. It can also occur of action is need to continue the operation
|
|
for non-blocking BIOs. Call SSL_get_error() with the return value B<ret>
|
|
to find out the reason.
|
|
|
|
=back
|
|
|
|
=head1 SEE ALSO
|
|
|
|
L<SSL_get_error(3)|SSL_get_error(3)>, L<SSL_connect(3)|SSL_connect(3)>,
|
|
L<SSL_accept(3)|SSL_accept(3)>, L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)>,
|
|
L<SSL_set_connect_state(3)|SSL_set_connect_state(3)>
|
|
|
|
=cut
|