1
0

ossl-guide-libssl-introduction.pod 4.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115
  1. =pod
  2. =head1 NAME
  3. ossl-guide-libssl-introduction, ssl
  4. - OpenSSL Guide: An introduction to libssl
  5. =head1 INTRODUCTION
  6. The OpenSSL C<libssl> library provides implementations of several secure network
  7. communications protocols. Specifically it provides SSL/TLS (SSLv3, TLSv1,
  8. TLSv1.1, TLSv1.2 and TLSv1.3), DTLS (DTLSv1 and DTLSv1.2) and QUIC (client side
  9. only). The library depends on C<libcrypto> for its underlying cryptographic
  10. operations (see L<ossl-guide-libcrypto-introduction(7)>).
  11. The set of APIs supplied by C<libssl> is common across all of these different
  12. network protocols, so a developer familiar with writing applications using one
  13. of these protocols should be able to transition to using another with relative
  14. ease.
  15. An application written to use C<libssl> will include the F<< <openssl/ssl.h> >>
  16. header file and will typically use two main data structures, i.e. B<SSL> and
  17. B<SSL_CTX>.
  18. An B<SSL> object is used to represent a connection to a remote peer. Once a
  19. connection with a remote peer has been established data can be exchanged with
  20. that peer.
  21. When using DTLS any data that is exchanged uses "datagram" semantics, i.e.
  22. the packets of data can be delivered in any order, and they are not guaranteed
  23. to arrive at all. In this case the B<SSL> object used for the connection is also
  24. used for exchanging data with the peer.
  25. Both TLS and QUIC support the concept of a "stream" of data. Data sent via a
  26. stream is guaranteed to be delivered in order without any data loss. A stream
  27. can be uni- or bi-directional.
  28. SSL/TLS only supports one stream of data per connection and it is always
  29. bi-directional. In this case the B<SSL> object used for the connection also
  30. represents that stream. See L<ossl-guide-tls-introduction(7)> for more
  31. information.
  32. The QUIC protocol can support multiple streams per connection and they can be
  33. uni- or bi-directional. In this case an B<SSL> object can represent the
  34. underlying connection, or a stream, or both. Where multiple streams are in use
  35. a separate B<SSL> object is used for each one. See
  36. L<ossl-guide-quic-introduction(7)> for more information.
  37. An B<SSL_CTX> object is used to create the B<SSL> object for the underlying
  38. connection. A single B<SSL_CTX> object can be used to create many connections
  39. (each represented by a separate B<SSL> object). Many API functions in libssl
  40. exist in two forms: one that takes an B<SSL_CTX> and one that takes an B<SSL>.
  41. Typically settings that you apply to the B<SSL_CTX> will then be inherited by
  42. any B<SSL> object that you create from it. Alternatively you can apply settings
  43. directly to the B<SSL> object without affecting other B<SSL> objects. Note that
  44. you should not normally make changes to an B<SSL_CTX> after the first B<SSL>
  45. object has been created from it.
  46. =head1 DATA STRUCTURES
  47. As well as B<SSL_CTX> and B<SSL> there are a number of other data structures
  48. that an application may need to use. They are summarised below.
  49. =over 4
  50. =item B<SSL_METHOD> (SSL Method)
  51. This structure is used to indicate the kind of connection you want to make, e.g.
  52. whether it is to represent the client or the server, and whether it is to use
  53. SSL/TLS, DTLS or QUIC (client only). It is passed as a parameter when creating
  54. the B<SSL_CTX>.
  55. =item B<SSL_SESSION> (SSL Session)
  56. After establishing a connection with a peer the agreed cryptographic material
  57. can be reused to create future connections with the same peer more rapidly. The
  58. set of data used for such a future connection establishment attempt is collected
  59. together into an B<SSL_SESSION> object. A single successful connection with a
  60. peer may generate zero or more such B<SSL_SESSION> objects for use in future
  61. connection attempts.
  62. =item B<SSL_CIPHER> (SSL Cipher)
  63. During connection establishment the client and server agree upon cryptographic
  64. algorithms they are going to use for encryption and other uses. A single set
  65. of cryptographic algorithms that are to be used together is known as a
  66. ciphersuite. Such a set is represented by an B<SSL_CIPHER> object.
  67. The set of available ciphersuites that can be used are configured in the
  68. B<SSL_CTX> or B<SSL>.
  69. =back
  70. =head1 FURTHER READING
  71. See L<ossl-guide-tls-introduction(7)> for an introduction to the SSL/TLS
  72. protocol and L<ossl-guide-quic-introduction(7)> for an introduction to QUIC.
  73. See L<ossl-guide-libcrypto-introduction(7)> for an introduction to C<libcrypto>.
  74. =head1 SEE ALSO
  75. L<ossl-guide-libcrypto-introduction(7)>, L<ossl-guide-tls-introduction(7)>,
  76. L<ossl-guide-quic-introduction(7)>
  77. =head1 COPYRIGHT
  78. Copyright 2000-2023 The OpenSSL Project Authors. All Rights Reserved.
  79. Licensed under the Apache License 2.0 (the "License"). You may not use
  80. this file except in compliance with the License. You can obtain a copy
  81. in the file LICENSE in the source distribution or at
  82. L<https://www.openssl.org/source/license.html>.
  83. =cut