| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115 |
- =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
|