1 files changed, 160 insertions, 0 deletions
diff --git a/upstream/debian-unstable/man7/ossl-guide-libssl-introduction.7ssl b/upstream/debian-unstable/man7/ossl-guide-libssl-introduction.7ssl
new file mode 100644
index 00000000..a63133a2
--- /dev/null
+++ b/upstream/debian-unstable/man7/ossl-guide-libssl-introduction.7ssl
@@ -0,0 +1,160 @@
+.\" -*- mode: troff; coding: utf-8 -*-
+.\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
+.ie n \{\
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is >0, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{\
+.    if \nF \{\
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{\
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\" ========================================================================
+.\"
+.IX Title "OSSL-GUIDE-LIBSSL-INTRODUCTION 7SSL"
+.TH OSSL-GUIDE-LIBSSL-INTRODUCTION 7SSL 2024-04-04 3.2.2-dev OpenSSL
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH NAME
+ossl\-guide\-libssl\-introduction, ssl
+\&\- OpenSSL Guide: An introduction to libssl
+.SH INTRODUCTION
+.IX Header "INTRODUCTION"
+The OpenSSL \f(CW\*(C`libssl\*(C'\fR 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 \f(CW\*(C`libcrypto\*(C'\fR for its underlying cryptographic
+operations (see \fBossl\-guide\-libcrypto\-introduction\fR\|(7)).
+.PP
+The set of APIs supplied by \f(CW\*(C`libssl\*(C'\fR 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.
+.PP
+An application written to use \f(CW\*(C`libssl\*(C'\fR will include the \fI<openssl/ssl.h>\fR
+header file and will typically use two main data structures, i.e. \fBSSL\fR and
+\&\fBSSL_CTX\fR.
+.PP
+An \fBSSL\fR 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.
+.PP
+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 \fBSSL\fR object used for the connection is also
+used for exchanging data with the peer.
+.PP
+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.
+.PP
+SSL/TLS only supports one stream of data per connection and it is always
+bi-directional. In this case the \fBSSL\fR object used for the connection also
+represents that stream. See \fBossl\-guide\-tls\-introduction\fR\|(7) for more
+information.
+.PP
+The QUIC protocol can support multiple streams per connection and they can be
+uni\- or bi-directional. In this case an \fBSSL\fR object can represent the
+underlying connection, or a stream, or both. Where multiple streams are in use
+a separate \fBSSL\fR object is used for each one. See
+\&\fBossl\-guide\-quic\-introduction\fR\|(7) for more information.
+.PP
+An \fBSSL_CTX\fR object is used to create the \fBSSL\fR object for the underlying
+connection. A single \fBSSL_CTX\fR object can be used to create many connections
+(each represented by a separate \fBSSL\fR object). Many API functions in libssl
+exist in two forms: one that takes an \fBSSL_CTX\fR and one that takes an \fBSSL\fR.
+Typically settings that you apply to the \fBSSL_CTX\fR will then be inherited by
+any \fBSSL\fR object that you create from it. Alternatively you can apply settings
+directly to the \fBSSL\fR object without affecting other \fBSSL\fR objects. Note that
+you should not normally make changes to an \fBSSL_CTX\fR after the first \fBSSL\fR
+object has been created from it.
+.SH "DATA STRUCTURES"
+.IX Header "DATA STRUCTURES"
+As well as \fBSSL_CTX\fR and \fBSSL\fR there are a number of other data structures
+that an application may need to use. They are summarised below.
+.IP "\fBSSL_METHOD\fR (SSL Method)" 4
+.IX Item "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 \fBSSL_CTX\fR.
+.IP "\fBSSL_SESSION\fR (SSL Session)" 4
+.IX Item "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 \fBSSL_SESSION\fR object. A single successful connection with a
+peer may generate zero or more such \fBSSL_SESSION\fR objects for use in future
+connection attempts.
+.IP "\fBSSL_CIPHER\fR (SSL Cipher)" 4
+.IX Item "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 \fBSSL_CIPHER\fR object.
+.Sp
+The set of available ciphersuites that can be used are configured in the
+\&\fBSSL_CTX\fR or \fBSSL\fR.
+.SH "FURTHER READING"
+.IX Header "FURTHER READING"
+See \fBossl\-guide\-tls\-introduction\fR\|(7) for an introduction to the SSL/TLS
+protocol and \fBossl\-guide\-quic\-introduction\fR\|(7) for an introduction to QUIC.
+.PP
+See \fBossl\-guide\-libcrypto\-introduction\fR\|(7) for an introduction to \f(CW\*(C`libcrypto\*(C'\fR.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fBossl\-guide\-libcrypto\-introduction\fR\|(7), \fBossl\-guide\-tls\-introduction\fR\|(7),
+\&\fBossl\-guide\-quic\-introduction\fR\|(7)
+.SH COPYRIGHT
+.IX Header "COPYRIGHT"
+Copyright 2000\-2023 The OpenSSL Project Authors. All Rights Reserved.
+.PP
+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
+<https://www.openssl.org/source/license.html>.