mirror of https://github.com/openssl/openssl.git
				
				
				
			
		
			
	
	
		
			116 lines
		
	
	
		
			4.7 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
		
		
			
		
	
	
			116 lines
		
	
	
		
			4.7 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
| 
								 | 
							
								=pod
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								=head1 NAME
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								ossl-guide-libssl-introduction, ssl
							 | 
						||
| 
								 | 
							
								- OpenSSL Guide: An introduction to libssl
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								=head1 INTRODUCTION
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								The OpenSSL C<libssl> library provides implementations of several secure network
							 | 
						||
| 
								 | 
							
								communications protocols. Specifically it provides SSL/TLS (SSLv3, TLSv1,
							 | 
						||
| 
								 | 
							
								TLSv1.1, TLSv1.2 and TLSv1.3), DTLS (DTLSv1 and DTLSv1.2) and QUIC (client side
							 | 
						||
| 
								 | 
							
								only). The library depends on C<libcrypto> for its underlying cryptographic
							 | 
						||
| 
								 | 
							
								operations (see L<ossl-guide-libcrypto-introduction(7)>).
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								The set of APIs supplied by C<libssl> is common across all of these different
							 | 
						||
| 
								 | 
							
								network protocols, so a developer familiar with writing applications using one
							 | 
						||
| 
								 | 
							
								of these protocols should be able to transition to using another with relative
							 | 
						||
| 
								 | 
							
								ease.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								An application written to use C<libssl> will include the F<< <openssl/ssl.h> >>
							 | 
						||
| 
								 | 
							
								header file and will typically use two main data structures, i.e. B<SSL> and
							 | 
						||
| 
								 | 
							
								B<SSL_CTX>.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								An B<SSL> object is used to represent a connection to a remote peer. Once a
							 | 
						||
| 
								 | 
							
								connection with a remote peer has been established data can be exchanged with
							 | 
						||
| 
								 | 
							
								that peer.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								When using DTLS any data that is exchanged uses "datagram" semantics, i.e.
							 | 
						||
| 
								 | 
							
								the packets of data can be delivered in any order, and they are not guaranteed
							 | 
						||
| 
								 | 
							
								to arrive at all. In this case the B<SSL> object used for the connection is also
							 | 
						||
| 
								 | 
							
								used for exchanging data with the peer.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Both TLS and QUIC support the concept of a "stream" of data. Data sent via a
							 | 
						||
| 
								 | 
							
								stream is guaranteed to be delivered in order without any data loss. A stream
							 | 
						||
| 
								 | 
							
								can be uni- or bi-directional.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								SSL/TLS only supports one stream of data per connection and it is always
							 | 
						||
| 
								 | 
							
								bi-directional. In this case the B<SSL> object used for the connection also
							 | 
						||
| 
								 | 
							
								represents that stream. See L<ossl-guide-tls-introduction(7)> for more
							 | 
						||
| 
								 | 
							
								information.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								The QUIC protocol can support multiple streams per connection and they can be
							 | 
						||
| 
								 | 
							
								uni- or bi-directional. In this case an B<SSL> object can represent the
							 | 
						||
| 
								 | 
							
								underlying connection, or a stream, or both. Where multiple streams are in use
							 | 
						||
| 
								 | 
							
								a separate B<SSL> object is used for each one. See
							 | 
						||
| 
								 | 
							
								L<ossl-guide-quic-introduction(7)> for more information.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								An B<SSL_CTX> object is used to create the B<SSL> object for the underlying
							 | 
						||
| 
								 | 
							
								connection. A single B<SSL_CTX> object can be used to create many connections
							 | 
						||
| 
								 | 
							
								(each represented by a separate B<SSL> object). Many API functions in libssl
							 | 
						||
| 
								 | 
							
								exist in two forms: one that takes an B<SSL_CTX> and one that takes an B<SSL>.
							 | 
						||
| 
								 | 
							
								Typically settings that you apply to the B<SSL_CTX> will then be inherited by
							 | 
						||
| 
								 | 
							
								any B<SSL> object that you create from it. Alternatively you can apply settings
							 | 
						||
| 
								 | 
							
								directly to the B<SSL> object without affecting other B<SSL> objects. Note that
							 | 
						||
| 
								 | 
							
								you should not normally make changes to an B<SSL_CTX> after the first B<SSL>
							 | 
						||
| 
								 | 
							
								object has been created from it.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								=head1 DATA STRUCTURES
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								As well as B<SSL_CTX> and B<SSL> there are a number of other data structures
							 | 
						||
| 
								 | 
							
								that an application may need to use. They are summarised below.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								=over 4
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								=item B<SSL_METHOD> (SSL Method)
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								This structure is used to indicate the kind of connection you want to make, e.g.
							 | 
						||
| 
								 | 
							
								whether it is to represent the client or the server, and whether it is to use
							 | 
						||
| 
								 | 
							
								SSL/TLS, DTLS or QUIC (client only). It is passed as a parameter when creating
							 | 
						||
| 
								 | 
							
								the B<SSL_CTX>.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								=item B<SSL_SESSION> (SSL Session)
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								After establishing a connection with a peer the agreed cryptographic material
							 | 
						||
| 
								 | 
							
								can be reused to create future connections with the same peer more rapidly. The
							 | 
						||
| 
								 | 
							
								set of data used for such a future connection establishment attempt is collected
							 | 
						||
| 
								 | 
							
								together into an B<SSL_SESSION> object. A single successful connection with a
							 | 
						||
| 
								 | 
							
								peer may generate zero or more such B<SSL_SESSION> objects for use in future
							 | 
						||
| 
								 | 
							
								connection attempts.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								=item B<SSL_CIPHER> (SSL Cipher)
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								During connection establishment the client and server agree upon cryptographic
							 | 
						||
| 
								 | 
							
								algorithms they are going to use for encryption and other uses. A single set
							 | 
						||
| 
								 | 
							
								of cryptographic algorithms that are to be used together is known as a
							 | 
						||
| 
								 | 
							
								ciphersuite. Such a set is represented by an B<SSL_CIPHER> object.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								The set of available ciphersuites that can be used are configured in the
							 | 
						||
| 
								 | 
							
								B<SSL_CTX> or B<SSL>.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								=back
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								=head1 FURTHER READING
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								See L<ossl-guide-tls-introduction(7)> for an introduction to the SSL/TLS
							 | 
						||
| 
								 | 
							
								protocol and L<ossl-guide-quic-introduction(7)> for an introduction to QUIC.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								See L<ossl-guide-libcrypto-introduction(7)> for an introduction to C<libcrypto>.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								=head1 SEE ALSO
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								L<ossl-guide-libcrypto-introduction(7)>, L<ossl-guide-tls-introduction(7)>,
							 | 
						||
| 
								 | 
							
								L<ossl-guide-quic-introduction(7)>
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								=head1 COPYRIGHT
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Copyright 2000-2023 The OpenSSL Project Authors. All Rights Reserved.
							 | 
						||
| 
								 | 
							
								
							 | 
						||
| 
								 | 
							
								Licensed under the Apache License 2.0 (the "License").  You may not use
							 | 
						||
| 
								 | 
							
								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
							 |