| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | =pod | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | =head1 NAME | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-09-16 23:39:28 +08:00
										 |  |  | SSL_connect - initiate the TLS/SSL handshake with an TLS/SSL server | 
					
						
							| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | 
 | 
					
						
							|  |  |  | =head1 SYNOPSIS | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |  #include <openssl/ssl.h> | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |  int SSL_connect(SSL *ssl); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | =head1 DESCRIPTION | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-09-17 00:02:35 +08:00
										 |  |  | SSL_connect() initiates the TLS/SSL handshake with a server. The communication | 
					
						
							| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | channel must already have been set and assigned to the B<ssl> by setting an | 
					
						
							| 
									
										
										
										
											2000-09-21 14:46:15 +08:00
										 |  |  | underlying B<BIO>. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | =head1 NOTES | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2016-05-20 20:11:46 +08:00
										 |  |  | The behaviour of SSL_connect() depends on the underlying BIO. | 
					
						
							| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-09-16 23:39:28 +08:00
										 |  |  | If the underlying BIO is B<blocking>, SSL_connect() will only return once the | 
					
						
							|  |  |  | handshake has been finished or an error occurred. | 
					
						
							| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-09-16 23:39:28 +08:00
										 |  |  | If the underlying BIO is B<non-blocking>, SSL_connect() will also return | 
					
						
							| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | when the underlying BIO could not satisfy the needs of SSL_connect() | 
					
						
							| 
									
										
										
										
											2003-06-03 17:59:44 +08:00
										 |  |  | to continue the handshake, indicating the problem by the return value -1. | 
					
						
							|  |  |  | In this case a call to SSL_get_error() with the | 
					
						
							| 
									
										
										
										
											2000-09-16 23:39:28 +08:00
										 |  |  | return value of SSL_connect() will yield B<SSL_ERROR_WANT_READ> or | 
					
						
							|  |  |  | B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after | 
					
						
							| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | taking appropriate action to satisfy the needs of SSL_connect(). | 
					
						
							|  |  |  | 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. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2018-05-01 18:46:58 +08:00
										 |  |  | Many systems implement Nagle's algorithm by default which means that it will | 
					
						
							|  |  |  | buffer outgoing TCP data if a TCP packet has already been sent for which no | 
					
						
							|  |  |  | corresponding ACK has been received yet from the peer. This can have performance | 
					
						
							|  |  |  | impacts after a successful TLSv1.3 handshake or a successful TLSv1.2 (or below) | 
					
						
							|  |  |  | resumption handshake, because the last peer to communicate in the handshake is | 
					
						
							|  |  |  | the client. If the client is also the first to send application data (as is | 
					
						
							|  |  |  | typical for many protocols) then this data could be buffered until an ACK has | 
					
						
							|  |  |  | been received for the final handshake message. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | The B<TCP_NODELAY> socket option is often available to disable Nagle's | 
					
						
							|  |  |  | algorithm. If an application opts to disable Nagle's algorithm consideration | 
					
						
							|  |  |  | should be given to turning it back on again later if appropriate. The helper | 
					
						
							|  |  |  | function BIO_set_tcp_ndelay() can be used to turn on or off the B<TCP_NODELAY> | 
					
						
							|  |  |  | option. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | =head1 RETURN VALUES | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | The following return values can occur: | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | =over 4 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-10-21 17:03:01 +08:00
										 |  |  | =item Z<>0 | 
					
						
							| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-09-16 23:39:28 +08:00
										 |  |  | 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 | 
					
						
							| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | return value B<ret> to find out the reason. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-10-21 17:03:01 +08:00
										 |  |  | =item Z<>1 | 
					
						
							| 
									
										
										
										
											2013-02-16 01:44:11 +08:00
										 |  |  | 
 | 
					
						
							|  |  |  | The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been | 
					
						
							|  |  |  | established. | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-10-10 17:15:47 +08:00
										 |  |  | =item E<lt>0 | 
					
						
							| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2000-09-16 23:39:28 +08:00
										 |  |  | 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 | 
					
						
							| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | for non-blocking BIOs. Call SSL_get_error() with the return value B<ret> | 
					
						
							|  |  |  | to find out the reason. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | =back | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | =head1 SEE ALSO | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2015-08-18 03:21:33 +08:00
										 |  |  | L<SSL_get_error(3)>, L<SSL_accept(3)>, | 
					
						
							| 
									
										
										
										
											2016-11-11 16:33:09 +08:00
										 |  |  | L<SSL_shutdown(3)>, L<ssl(7)>, L<bio(7)>, | 
					
						
							| 
									
										
										
										
											2015-08-18 03:21:33 +08:00
										 |  |  | L<SSL_set_connect_state(3)>, | 
					
						
							|  |  |  | L<SSL_do_handshake(3)>, | 
					
						
							|  |  |  | L<SSL_CTX_new(3)> | 
					
						
							| 
									
										
										
										
											2000-09-14 21:11:56 +08:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2016-05-18 23:44:05 +08:00
										 |  |  | =head1 COPYRIGHT | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2018-05-29 20:07:08 +08:00
										 |  |  | Copyright 2000-2018 The OpenSSL Project Authors. All Rights Reserved. | 
					
						
							| 
									
										
										
										
											2016-05-18 23:44:05 +08:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2018-12-06 21:04:44 +08:00
										 |  |  | Licensed under the Apache License 2.0 (the "License").  You may not use | 
					
						
							| 
									
										
										
										
											2016-05-18 23:44:05 +08:00
										 |  |  | this file except in compliance with the License.  You can obtain a copy | 
					
						
							|  |  |  | in the file LICENSE in the source distribution or at | 
					
						
							|  |  |  | L<https://www.openssl.org/source/license.html>. | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | =cut |