DragonFly On-Line Manual Pages

Search:
Section:

ssl(3) OpenSSL ssl(3)

NAME

SSL - OpenSSL SSL/TLS library

SYNOPSIS

DESCRIPTION

The OpenSSL ssl library implements the Secure Sockets Layer (SSL v2/v3)
and Transport Layer Security (TLS v1) protocols. It provides a rich API
which is documented here.
At first the library must be initialized; see SSL_library_init(3).
Then an SSL_CTX object is created as a framework to establish TLS/SSL
enabled connections (see SSL_CTX_new(3)). Various options regarding
certificates, algorithms etc. can be set in this object.
When a network connection has been created, it can be assigned to an
SSL object. After the SSL object has been created using SSL_new(3),
SSL_set_fd(3) or SSL_set_bio(3) can be used to associate the network
connection with the object.
Then the TLS/SSL handshake is performed using SSL_accept(3) or
SSL_connect(3) respectively. SSL_read(3) and SSL_write(3) are used to
read and write data on the TLS/SSL connection. SSL_shutdown(3) can be
used to shut down the TLS/SSL connection.

DATA STRUCTURES

Currently the OpenSSL ssl library functions deals with the following
data structures:
SSL_METHOD (SSL Method)
That's a dispatch structure describing the internal ssl library
methods/functions which implement the various protocol versions
(SSLv1, SSLv2 and TLSv1). It's needed to create an SSL_CTX.
SSL_CIPHER (SSL Cipher)
This structure holds the algorithm information for a particular
cipher which are a core part of the SSL/TLS protocol. The available
ciphers are configured on a SSL_CTX basis and the actually used
ones are then part of the SSL_SESSION.
SSL_CTX (SSL Context)
That's the global context structure which is created by a server or
client once per program life-time and which holds mainly default
values for the SSL structures which are later created for the
connections.
SSL_SESSION (SSL Session)
This is a structure containing the current TLS/SSL session details
for a connection: SSL_CIPHERs, client and server certificates,
keys, etc.
SSL (SSL Connection)
That's the main SSL/TLS structure which is created by a server or
client per established connection. This actually is the core
structure in the SSL API. Under run-time the application usually
deals with this structure which has links to mostly all other
structures.

HEADER FILES

Currently the OpenSSL ssl library provides the following C header files
containing the prototypes for the data structures and and functions:
ssl.h
That's the common header file for the SSL/TLS API. Include it into
your program to make the API of the ssl library available. It
internally includes both more private SSL headers and headers from
the crypto library. Whenever you need hard-core details on the
internals of the SSL API, look inside this header file.
ssl2.h
That's the sub header file dealing with the SSLv2 protocol only.
Usuallyyoudon'thavetoincludeitexplicitlybecauseit'salreadyincludedbyssl.h.
ssl3.h
That's the sub header file dealing with the SSLv3 protocol only.
Usuallyyoudon'thavetoincludeitexplicitlybecauseit'salreadyincludedbyssl.h.
ssl23.h
That's the sub header file dealing with the combined use of the
SSLv2 and SSLv3 protocols. Usuallyyoudon'thavetoincludeitexplicitlybecauseit'salreadyincludedbyssl.h.
tls1.h
That's the sub header file dealing with the TLSv1 protocol only.
Usuallyyoudon'thavetoincludeitexplicitlybecauseit'salreadyincludedbyssl.h.

SYNOPSIS

DESCRIPTION

SSL_COMP_add_compression_method() adds the compression method cm with
the identifier id to the list of available compression methods. This
list is globally maintained for all SSL operations within this
application. It cannot be set for specific SSL_CTX or SSL objects.
SSL_COMP_free_compression_methods() frees the internal table of
compression methods that were built internally, and possibly augmented
by adding SSL_COMP_add_compression_method().

NOTES

The TLS standard (or SSLv3) allows the integration of compression
methods into the communication. The TLS RFC does however not specify
compression methods or their corresponding identifiers, so there is
currently no compatible way to integrate compression with unknown
peers. It is therefore currently not recommended to integrate
compression into applications. Applications for non-public use may
agree on certain compression methods. Using different compression
methods with the same identifier will lead to connection failure.
An OpenSSL client speaking a protocol that allows compression (SSLv3,
TLSv1) will unconditionally send the list of all compression methods
enabled with SSL_COMP_add_compression_method() to the server during the
handshake. Unlike the mechanisms to set a cipher list, there is no
method available to restrict the list of compression method on a per
connection basis.
An OpenSSL server will match the identifiers listed by a client against
its own compression methods and will unconditionally activate
compression when a matching identifier is found. There is no way to
restrict the list of compression methods supported on a per connection
basis.
If enabled during compilation, the OpenSSL library will have the
COMP_zlib() compression method available.

WARNINGS

Once the identities of the compression methods for the TLS protocol
have been standardized, the compression API will most likely be
changed. Using it in the current state is not recommended.

RETURN VALUES

SSL_COMP_add_compression_method() may return the following values:
0 The operation succeeded.
1 The operation failed. Check the error queue to find out the reason.