|
Packit |
aea12f |
@node Introduction to TLS
|
|
Packit |
aea12f |
@chapter Introduction to @acronym{TLS} and @acronym{DTLS}
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@acronym{TLS} stands for ``Transport Layer Security'' and is the
|
|
Packit |
aea12f |
successor of SSL, the Secure Sockets Layer protocol @xcite{SSL3}
|
|
Packit |
aea12f |
designed by Netscape. @acronym{TLS} is an Internet protocol, defined
|
|
Packit |
aea12f |
by @acronym{IETF}@footnote{IETF, or Internet Engineering Task Force,
|
|
Packit |
aea12f |
is a large open international community of network designers,
|
|
Packit |
aea12f |
operators, vendors, and researchers concerned with the evolution of
|
|
Packit |
aea12f |
the Internet architecture and the smooth operation of the Internet.
|
|
Packit |
aea12f |
It is open to any interested individual.}, described in @xcite{RFC5246}.
|
|
Packit |
aea12f |
The protocol provides
|
|
Packit |
aea12f |
confidentiality, and authentication layers over any reliable transport
|
|
Packit |
aea12f |
layer. The description, above, refers to @acronym{TLS} 1.0 but applies
|
|
Packit |
aea12f |
to all other TLS versions as the differences between the protocols are not major.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The @acronym{DTLS} protocol, or ``Datagram @acronym{TLS}'' @xcite{RFC4347} is a
|
|
Packit |
aea12f |
protocol with identical goals as @acronym{TLS}, but can operate
|
|
Packit |
aea12f |
under unreliable transport layers such as @acronym{UDP}. The
|
|
Packit |
aea12f |
discussions below apply to this protocol as well, except when
|
|
Packit |
aea12f |
noted otherwise.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@menu
|
|
Packit |
aea12f |
* TLS layers::
|
|
Packit |
aea12f |
* The transport layer::
|
|
Packit |
aea12f |
* The TLS record protocol::
|
|
Packit |
aea12f |
* The TLS Alert Protocol::
|
|
Packit |
aea12f |
* The TLS Handshake Protocol::
|
|
Packit |
aea12f |
* TLS Extensions::
|
|
Packit |
aea12f |
* How to use TLS in application protocols::
|
|
Packit |
aea12f |
* On SSL 2 and older protocols::
|
|
Packit |
aea12f |
@end menu
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node TLS layers
|
|
Packit |
aea12f |
@section TLS Layers
|
|
Packit |
aea12f |
@cindex TLS layers
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@acronym{TLS} is a layered protocol, and consists of the record
|
|
Packit |
aea12f |
protocol, the handshake protocol and the alert protocol. The record
|
|
Packit |
aea12f |
protocol is to serve all other protocols and is above the transport
|
|
Packit |
aea12f |
layer. The record protocol offers symmetric encryption, and data
|
|
Packit |
aea12f |
authenticity@footnote{In early versions of TLS compression was optionally
|
|
Packit |
aea12f |
available as well. This is no longer the case in recent versions of the
|
|
Packit |
aea12f |
protocol.}.
|
|
Packit |
aea12f |
The alert protocol offers some signaling to the other protocols. It
|
|
Packit |
aea12f |
can help informing the peer for the cause of failures and other error
|
|
Packit |
aea12f |
conditions. @xref{The Alert Protocol}, for more information. The
|
|
Packit |
aea12f |
alert protocol is above the record protocol.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The handshake protocol is responsible for the security parameters'
|
|
Packit |
aea12f |
negotiation, the initial key exchange and authentication.
|
|
Packit |
aea12f |
@xref{The Handshake Protocol}, for more information about the handshake
|
|
Packit |
aea12f |
protocol. The protocol layering in TLS is shown in @ref{fig-tls-layers}.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@float Figure,fig-tls-layers
|
|
Packit |
aea12f |
@image{gnutls-layers,12cm}
|
|
Packit |
aea12f |
@caption{The TLS protocol layers.}
|
|
Packit |
aea12f |
@end float
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node The transport layer
|
|
Packit |
aea12f |
@section The Transport Layer
|
|
Packit |
aea12f |
@cindex transport protocol
|
|
Packit |
aea12f |
@cindex transport layer
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@acronym{TLS} is not limited to any transport layer and can be used
|
|
Packit |
aea12f |
above any transport layer, as long as it is a reliable one. @acronym{DTLS}
|
|
Packit |
aea12f |
can be used over reliable and unreliable transport layers.
|
|
Packit |
aea12f |
@acronym{GnuTLS} supports TCP and UDP layers transparently using
|
|
Packit |
aea12f |
the Berkeley sockets API. However, any transport layer can be used
|
|
Packit |
aea12f |
by providing callbacks for @acronym{GnuTLS} to access the transport layer
|
|
Packit |
aea12f |
(for details see @ref{Setting up the transport layer}).
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node The TLS record protocol
|
|
Packit |
aea12f |
@section The TLS record protocol
|
|
Packit |
aea12f |
@cindex record protocol
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The record protocol is the secure communications provider. Its purpose
|
|
Packit |
aea12f |
is to encrypt, and authenticate packets.
|
|
Packit |
aea12f |
The record layer functions can be called at any time after
|
|
Packit |
aea12f |
the handshake process is finished, when there is need to receive
|
|
Packit |
aea12f |
or send data. In @acronym{DTLS} however, due to re-transmission
|
|
Packit |
aea12f |
timers used in the handshake out-of-order handshake data might
|
|
Packit |
aea12f |
be received for some time (maximum 60 seconds) after the handshake
|
|
Packit |
aea12f |
process is finished.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The functions to access the record protocol are limited to send
|
|
Packit |
aea12f |
and receive functions, which might, given
|
|
Packit |
aea12f |
the importance of this protocol in @acronym{TLS}, seem awkward. This is because
|
|
Packit |
aea12f |
the record protocol's parameters are all set by the handshake protocol.
|
|
Packit |
aea12f |
The record protocol initially starts with NULL parameters, which means
|
|
Packit |
aea12f |
no encryption, and no MAC is used. Encryption and authentication begin
|
|
Packit |
aea12f |
just after the handshake protocol has finished.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@menu
|
|
Packit |
aea12f |
* Encryption algorithms used in the record layer::
|
|
Packit |
aea12f |
* Compression algorithms and the record layer::
|
|
Packit |
aea12f |
* On Record Padding::
|
|
Packit |
aea12f |
@end menu
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node Encryption algorithms used in the record layer
|
|
Packit |
aea12f |
@subsection Encryption algorithms used in the record layer
|
|
Packit |
aea12f |
@cindex symmetric encryption algorithms
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Confidentiality in the record layer is achieved by using symmetric
|
|
Packit |
aea12f |
ciphers like @code{AES} or @code{CHACHA20}. Ciphers are encryption algorithms
|
|
Packit |
aea12f |
that use a single, secret, key to encrypt and decrypt data. Early
|
|
Packit |
aea12f |
versions of TLS separated between block and stream ciphers and had
|
|
Packit |
aea12f |
message authentication plugged in to them by the protocol, though later
|
|
Packit |
aea12f |
versions switched to using authenticated-encryption (AEAD) ciphers. The AEAD
|
|
Packit |
aea12f |
ciphers are defined to combine encryption and authentication, and as such
|
|
Packit |
aea12f |
they are not only more efficient, as the primitives used are designed to
|
|
Packit |
aea12f |
interoperate nicely, but they are also known to interoperate in a secure
|
|
Packit |
aea12f |
way.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The supported in @acronym{GnuTLS} ciphers and MAC algorithms are shown in @ref{tab:ciphers} and
|
|
Packit |
aea12f |
@ref{tab:macs}.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@float Table,tab:ciphers
|
|
Packit |
aea12f |
@multitable @columnfractions .20 .10 .15 .55
|
|
Packit |
aea12f |
@headitem Algorithm @tab Type @tab Applicable Protocols @tab Description
|
|
Packit |
aea12f |
@item AES-128-GCM, AES-256-GCM @tab
|
|
Packit |
aea12f |
AEAD @tab
|
|
Packit |
aea12f |
TLS 1.2, TLS 1.3 @tab
|
|
Packit |
aea12f |
This is the AES algorithm in the authenticated encryption GCM mode.
|
|
Packit |
aea12f |
This mode combines message authentication and encryption and can
|
|
Packit |
aea12f |
be extremely fast on CPUs that support hardware acceleration.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item AES-128-CCM, AES-256-CCM @tab
|
|
Packit |
aea12f |
AEAD @tab
|
|
Packit |
aea12f |
TLS 1.2, TLS 1.3 @tab
|
|
Packit |
aea12f |
This is the AES algorithm in the authenticated encryption CCM mode.
|
|
Packit |
aea12f |
This mode combines message authentication and encryption and is
|
|
Packit |
aea12f |
often used by systems without AES or GCM acceleration support.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item CHACHA20-POLY1305 @tab
|
|
Packit |
aea12f |
AEAD @tab
|
|
Packit |
aea12f |
TLS 1.2, TLS 1.3 @tab
|
|
Packit |
aea12f |
CHACHA20-POLY1305 is an authenticated encryption algorithm based on CHACHA20 cipher and
|
|
Packit |
aea12f |
POLY1305 MAC. CHACHA20 is a refinement of SALSA20 algorithm, an approved cipher by
|
|
Packit |
aea12f |
the European ESTREAM project. POLY1305 is Wegman-Carter, one-time authenticator. The
|
|
Packit |
aea12f |
combination provides a fast stream cipher suitable for systems where a hardware AES
|
|
Packit |
aea12f |
accelerator is not available.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item AES-128-CCM-8, AES-256-CCM-8 @tab
|
|
Packit |
aea12f |
AEAD @tab
|
|
Packit |
aea12f |
TLS 1.2, TLS 1.3 @tab
|
|
Packit |
aea12f |
This is the AES algorithm in the authenticated encryption CCM mode
|
|
Packit |
aea12f |
with a truncated to 64-bit authentication tag. This mode is for
|
|
Packit |
aea12f |
communication with restricted systems.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item CAMELLIA-128-GCM, CAMELLIA-256-GCM @tab
|
|
Packit |
aea12f |
AEAD @tab
|
|
Packit |
aea12f |
TLS 1.2 @tab
|
|
Packit |
aea12f |
This is the CAMELLIA algorithm in the authenticated encryption GCM mode.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item AES-128-CBC, AES-256-CBC @tab
|
|
Packit |
aea12f |
Legacy (block) @tab
|
|
Packit |
aea12f |
TLS 1.0, TLS 1.1, TLS 1.2 @tab
|
|
Packit |
aea12f |
AES or RIJNDAEL is the block cipher algorithm that replaces the old
|
|
Packit |
aea12f |
DES algorithm. It has 128 bits block size and is used in CBC mode.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item CAMELLIA-128-CBC, CAMELLIA-256-CBC @tab
|
|
Packit |
aea12f |
Legacy (block) @tab
|
|
Packit |
aea12f |
TLS 1.0, TLS 1.1, TLS 1.2 @tab
|
|
Packit |
aea12f |
This is an 128-bit block cipher developed by Mitsubishi and NTT. It
|
|
Packit |
aea12f |
is one of the approved ciphers of the European NESSIE and Japanese
|
|
Packit |
aea12f |
CRYPTREC projects.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item 3DES-CBC @tab
|
|
Packit |
aea12f |
Legacy (block) @tab
|
|
Packit |
aea12f |
TLS 1.0, TLS 1.1, TLS 1.2 @tab
|
|
Packit |
aea12f |
This is the DES block cipher algorithm used with triple
|
|
Packit |
aea12f |
encryption (EDE). Has 64 bits block size and is used in CBC mode.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item ARCFOUR-128 @tab
|
|
Packit |
aea12f |
Legacy (stream) @tab
|
|
Packit |
aea12f |
TLS 1.0, TLS 1.1, TLS 1.2 @tab
|
|
Packit |
aea12f |
ARCFOUR-128 is a compatible algorithm with RSA's RC4 algorithm, which is considered to be a trade
|
|
Packit |
aea12f |
secret. It is a considered to be broken, and is only used for compatibility
|
|
Packit |
aea12f |
purposed. For this reason it is not enabled by default.
|
|
Packit |
aea12f |
|
|
Packit Service |
991b93 |
@item GOST28147-TC26Z-CNT @tab
|
|
Packit Service |
991b93 |
Legacy (stream) @tab
|
|
Packit Service |
991b93 |
TLS 1.2 @tab
|
|
Packit Service |
991b93 |
This is a 64-bit block cipher GOST 28147-89 with TC26Z S-Box working in CNT
|
|
Packit Service |
991b93 |
mode. It is one of the approved ciphers in Russia. It is not enabled by default.
|
|
Packit Service |
991b93 |
|
|
Packit |
aea12f |
@item NULL @tab
|
|
Packit |
aea12f |
Legacy (stream) @tab
|
|
Packit |
aea12f |
TLS 1.0, TLS 1.1, TLS 1.2 @tab
|
|
Packit |
aea12f |
NULL is the empty/identity cipher which doesn't encrypt any data. It can be
|
|
Packit |
aea12f |
combined with data authentication under TLS 1.2 or earlier, but is only used
|
|
Packit |
aea12f |
transiently under TLS 1.3 until encryption starts. This cipher cannot be negotiated
|
|
Packit |
aea12f |
by default (need to be explicitly enabled) under TLS 1.2, and cannot be
|
|
Packit |
aea12f |
negotiated at all under TLS 1.3. When enabled, TLS 1.3 (or later) support will be
|
|
Packit |
aea12f |
implicitly disabled.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@end multitable
|
|
Packit |
aea12f |
@caption{Supported ciphers in TLS.}
|
|
Packit |
aea12f |
@end float
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@float Table,tab:macs
|
|
Packit |
aea12f |
@multitable @columnfractions .20 .70
|
|
Packit |
aea12f |
@headitem Algorithm @tab Description
|
|
Packit |
aea12f |
@item MAC-MD5 @tab
|
|
Packit |
aea12f |
This is an HMAC based on MD5 a cryptographic hash algorithm designed
|
|
Packit |
aea12f |
by Ron Rivest. Outputs 128 bits of data.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item MAC-SHA1 @tab
|
|
Packit |
aea12f |
An HMAC based on the SHA1 cryptographic hash algorithm
|
|
Packit |
aea12f |
designed by NSA. Outputs 160 bits of data.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item MAC-SHA256 @tab
|
|
Packit |
aea12f |
An HMAC based on SHA2-256. Outputs 256 bits of data.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item MAC-SHA384 @tab
|
|
Packit |
aea12f |
An HMAC based on SHA2-384. Outputs 384 bits of data.
|
|
Packit |
aea12f |
|
|
Packit Service |
991b93 |
@item GOST28147-TC26Z-IMIT @tab
|
|
Packit Service |
991b93 |
This is a 64-bit block cipher GOST 28147-89 with TC26Z S-Box working in special
|
|
Packit Service |
991b93 |
MAC mode called Imitovstavks. It is one of the approved MAC algorithms in
|
|
Packit Service |
991b93 |
Russia. Outputs 32 bits of data. It is not enabled by default.
|
|
Packit Service |
991b93 |
|
|
Packit |
aea12f |
@item MAC-AEAD @tab
|
|
Packit |
aea12f |
This indicates that an authenticated encryption algorithm, such as
|
|
Packit |
aea12f |
GCM, is in use.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@end multitable
|
|
Packit |
aea12f |
@caption{Supported MAC algorithms in TLS.}
|
|
Packit |
aea12f |
@end float
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node Compression algorithms and the record layer
|
|
Packit |
aea12f |
@subsection Compression algorithms and the record layer
|
|
Packit |
aea12f |
@cindex compression algorithms
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
In early versions of TLS the record layer supported compression. However,
|
|
Packit |
aea12f |
that proved to be problematic in many ways, and enabled several attacks
|
|
Packit |
aea12f |
based on traffic analysis on the transported data. For that newer versions of the protocol no longer
|
|
Packit |
aea12f |
offer compression, and @acronym{GnuTLS} since 3.6.0 no longer implements any
|
|
Packit |
aea12f |
support for compression.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node On Record Padding
|
|
Packit |
aea12f |
@subsection On record padding
|
|
Packit |
aea12f |
@cindex record padding
|
|
Packit |
aea12f |
@cindex bad_record_mac
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The TLS 1.3 protocol allows for extra padding of records to prevent
|
|
Packit |
aea12f |
statistical analysis based on the length of exchanged messages.
|
|
Packit |
aea12f |
GnuTLS takes advantage of this feature, by allowing the user
|
|
Packit |
aea12f |
to specify the amount of padding for a particular message. The simplest
|
|
Packit |
aea12f |
interface is provided by @funcref{gnutls_record_send2}, and is made
|
|
Packit |
aea12f |
available when under TLS1.3; alternatively @funcref{gnutls_record_can_use_length_hiding}
|
|
Packit |
aea12f |
can be queried.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Note that this interface is not sufficient to completely hide the length of the
|
|
Packit |
aea12f |
data. The application code may reveal the data transferred by leaking its
|
|
Packit |
aea12f |
data processing time, or by leaking the TLS1.3 record processing time by
|
|
Packit |
aea12f |
GnuTLS. That is because under TLS1.3 the padding removal time depends on the
|
|
Packit |
aea12f |
padding data for an efficient implementation. To make that processing
|
|
Packit |
aea12f |
constant time the @funcref{gnutls_init} function must be called with
|
|
Packit |
aea12f |
the flag @code{GNUTLS_SAFE_PADDING_CHECK}.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@showfuncdesc{gnutls_record_send2}
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Older GnuTLS versions provided an API suitable for cases where the sender
|
|
Packit |
aea12f |
sends data that are always within a given range. That API is still
|
|
Packit |
aea12f |
available, and consists of the following functions.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@showfuncB{gnutls_record_can_use_length_hiding,gnutls_record_send_range}
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node The TLS Alert Protocol
|
|
Packit |
aea12f |
@section The TLS alert protocol
|
|
Packit |
aea12f |
@anchor{The Alert Protocol}
|
|
Packit |
aea12f |
@cindex alert protocol
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The alert protocol is there to allow signals to be sent between peers.
|
|
Packit |
aea12f |
These signals are mostly used to inform the peer about the cause of a
|
|
Packit |
aea12f |
protocol failure. Some of these signals are used internally by the
|
|
Packit |
aea12f |
protocol and the application protocol does not have to cope with them
|
|
Packit |
aea12f |
(e.g. @code{GNUTLS_@-A_@-CLOSE_@-NOTIFY}), and others refer to the
|
|
Packit |
aea12f |
application protocol solely (e.g. @code{GNUTLS_@-A_@-USER_@-CANCELLED}). An
|
|
Packit |
aea12f |
alert signal includes a level indication which may be either fatal or
|
|
Packit |
aea12f |
warning (under TLS1.3 all alerts are fatal). Fatal alerts always terminate
|
|
Packit |
aea12f |
the current connection, and prevent future re-negotiations using the current
|
|
Packit |
aea12f |
session ID. All supported alert messages are summarized in the table below.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The alert messages are protected by the record protocol, thus the
|
|
Packit |
aea12f |
information that is included does not leak. You must take extreme care
|
|
Packit |
aea12f |
for the alert information not to leak to a possible attacker, via
|
|
Packit |
aea12f |
public log files etc.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@include alerts.texi
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node The TLS Handshake Protocol
|
|
Packit |
aea12f |
@section The TLS handshake protocol
|
|
Packit |
aea12f |
@anchor{The Handshake Protocol}
|
|
Packit |
aea12f |
@cindex handshake protocol
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The handshake protocol is responsible for the ciphersuite negotiation,
|
|
Packit |
aea12f |
the initial key exchange, and the authentication of the two peers.
|
|
Packit |
aea12f |
This is fully controlled by the application layer, thus your program
|
|
Packit |
aea12f |
has to set up the required parameters. The main handshake function
|
|
Packit |
aea12f |
is @funcref{gnutls_handshake}. In the next paragraphs we elaborate on
|
|
Packit |
aea12f |
the handshake protocol, i.e., the ciphersuite negotiation.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@menu
|
|
Packit |
aea12f |
* TLS Cipher Suites:: TLS session parameters.
|
|
Packit |
aea12f |
* Authentication:: TLS authentication.
|
|
Packit |
aea12f |
* Client Authentication:: Requesting a certificate from the client.
|
|
Packit |
aea12f |
* Resuming Sessions:: Reusing previously established keys.
|
|
Packit |
aea12f |
@end menu
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node TLS Cipher Suites
|
|
Packit |
aea12f |
@subsection TLS ciphersuites
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The TLS cipher suites have slightly different meaning under different
|
|
Packit |
aea12f |
protocols. Under @acronym{TLS 1.3}, a cipher suite indicates the symmetric
|
|
Packit |
aea12f |
encryption algorithm in use, as well as the pseudo-random function (PRF)
|
|
Packit |
aea12f |
used in the TLS session.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Under TLS 1.2 or early the handshake protocol negotiates cipher suites of
|
|
Packit |
aea12f |
a special form illustrated by the @code{TLS_DHE_RSA_WITH_3DES_CBC_SHA} cipher suite name.
|
|
Packit |
aea12f |
A typical cipher suite contains these parameters:
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@itemize
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item The key exchange algorithm.
|
|
Packit |
aea12f |
@code{DHE_RSA} in the example.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item The Symmetric encryption algorithm and mode
|
|
Packit |
aea12f |
@code{3DES_CBC} in this example.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item The MAC@footnote{MAC stands for Message Authentication Code. It can be described as a keyed hash algorithm. See RFC2104.} algorithm used for authentication.
|
|
Packit |
aea12f |
@code{MAC_SHA} is used in the above example.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@end itemize
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The cipher suite negotiated in the handshake protocol will affect the
|
|
Packit |
aea12f |
record protocol, by enabling encryption and data authentication. Note
|
|
Packit |
aea12f |
that you should not over rely on @acronym{TLS} to negotiate the
|
|
Packit |
aea12f |
strongest available cipher suite. Do not enable ciphers and algorithms
|
|
Packit |
aea12f |
that you consider weak.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
All the supported ciphersuites are listed in @ref{ciphersuites}.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node Authentication
|
|
Packit |
aea12f |
@subsection Authentication
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The key exchange algorithms of the @acronym{TLS} protocol offer
|
|
Packit |
aea12f |
authentication, which is a prerequisite for a secure connection.
|
|
Packit |
aea12f |
The available authentication methods in @acronym{GnuTLS}, under
|
|
Packit |
aea12f |
TLS 1.3 or earlier versions, follow.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@itemize
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item Certificate authentication: Authenticated key exchange using public key infrastructure and X.509 certificates.
|
|
Packit |
aea12f |
@item @acronym{PSK} authentication: Authenticated key exchange using a pre-shared key.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@end itemize
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Under TLS 1.2 or earlier versions, the following authentication methods
|
|
Packit |
aea12f |
are also available.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@itemize
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item @acronym{SRP} authentication: Authenticated key exchange using a password.
|
|
Packit |
aea12f |
@item Anonymous authentication: Key exchange without peer authentication.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@end itemize
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node Client Authentication
|
|
Packit |
aea12f |
@subsection Client authentication
|
|
Packit |
aea12f |
@cindex client certificate authentication
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
In the case of ciphersuites that use certificate authentication, the
|
|
Packit |
aea12f |
authentication of the client is optional in @acronym{TLS}. A server
|
|
Packit |
aea12f |
may request a certificate from the client using the
|
|
Packit |
aea12f |
@funcref{gnutls_certificate_server_set_request} function. We elaborate
|
|
Packit |
aea12f |
in @ref{Certificate credentials}.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node Resuming Sessions
|
|
Packit |
aea12f |
@subsection Resuming sessions
|
|
Packit |
aea12f |
@anchor{resume}
|
|
Packit |
aea12f |
@cindex resuming sessions
|
|
Packit |
aea12f |
@cindex session resumption
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The TLS handshake process performs expensive calculations
|
|
Packit |
aea12f |
and a busy server might easily be put under load. To
|
|
Packit |
aea12f |
reduce the load, session resumption may be used. This
|
|
Packit |
aea12f |
is a feature of the @acronym{TLS} protocol which allows a
|
|
Packit |
aea12f |
client to connect to a server after a successful handshake, without
|
|
Packit |
aea12f |
the expensive calculations. This is achieved by re-using the previously
|
|
Packit |
aea12f |
established keys, meaning the server needs to store the state of established
|
|
Packit |
aea12f |
connections (unless session tickets are used -- @ref{Session tickets}).
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Session resumption is an integral part of @acronym{GnuTLS}, and
|
|
Packit |
aea12f |
@ref{Session resumption}, @ref{ex-resume-client} illustrate typical
|
|
Packit |
aea12f |
uses of it.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node TLS Extensions
|
|
Packit |
aea12f |
@section TLS extensions
|
|
Packit |
aea12f |
@cindex TLS extensions
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
A number of extensions to the @acronym{TLS} protocol have been
|
|
Packit |
aea12f |
proposed mainly in @xcite{TLSEXT}. The extensions supported
|
|
Packit |
aea12f |
in @acronym{GnuTLS} are discussed in the subsections that follow.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@menu
|
|
Packit |
aea12f |
* Maximum fragment length negotiation::
|
|
Packit |
aea12f |
* Server name indication::
|
|
Packit |
aea12f |
* Session tickets::
|
|
Packit |
aea12f |
* HeartBeat::
|
|
Packit |
aea12f |
* Safe renegotiation::
|
|
Packit |
aea12f |
* OCSP status request::
|
|
Packit |
aea12f |
* SRTP::
|
|
Packit |
aea12f |
* False Start::
|
|
Packit |
aea12f |
* Application Layer Protocol Negotiation (ALPN)::
|
|
Packit |
aea12f |
* Extensions and Supplemental Data::
|
|
Packit |
aea12f |
@end menu
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node Maximum fragment length negotiation
|
|
Packit |
aea12f |
@subsection Maximum fragment length negotiation
|
|
Packit |
aea12f |
@cindex TLS extensions
|
|
Packit |
aea12f |
@cindex maximum fragment length
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
This extension allows a @acronym{TLS} implementation to negotiate a
|
|
Packit |
aea12f |
smaller value for record packet maximum length. This extension may be
|
|
Packit |
aea12f |
useful to clients with constrained capabilities. The functions shown
|
|
Packit |
aea12f |
below can be used to control this extension.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@showfuncB{gnutls_record_get_max_size,gnutls_record_set_max_size}
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node Server name indication
|
|
Packit |
aea12f |
@subsection Server name indication
|
|
Packit |
aea12f |
@anchor{serverind}
|
|
Packit |
aea12f |
@cindex TLS extensions
|
|
Packit |
aea12f |
@cindex server name indication
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
A common problem in @acronym{HTTPS} servers is the fact that the
|
|
Packit |
aea12f |
@acronym{TLS} protocol is not aware of the hostname that a client
|
|
Packit |
aea12f |
connects to, when the handshake procedure begins. For that reason the
|
|
Packit |
aea12f |
@acronym{TLS} server has no way to know which certificate to send.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
This extension solves that problem within the @acronym{TLS} protocol,
|
|
Packit |
aea12f |
and allows a client to send the HTTP hostname before the handshake
|
|
Packit |
aea12f |
begins within the first handshake packet. The functions
|
|
Packit |
aea12f |
@funcref{gnutls_server_name_set} and @funcref{gnutls_server_name_get} can be
|
|
Packit |
aea12f |
used to enable this extension, or to retrieve the name sent by a
|
|
Packit |
aea12f |
client.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@showfuncB{gnutls_server_name_set,gnutls_server_name_get}
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node Session tickets
|
|
Packit |
aea12f |
@subsection Session tickets
|
|
Packit |
aea12f |
@cindex TLS extensions
|
|
Packit |
aea12f |
@cindex session tickets
|
|
Packit |
aea12f |
@cindex tickets
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
To resume a TLS session, the server normally stores session parameters. This
|
|
Packit |
aea12f |
complicates deployment, and can be avoided by delegating the storage
|
|
Packit |
aea12f |
to the client. Because session parameters are sensitive they are encrypted
|
|
Packit |
aea12f |
and authenticated with a key only known to the server and then sent to the
|
|
Packit |
aea12f |
client. The Session Tickets extension is described in RFC 5077 @xcite{TLSTKT}.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
A disadvantage of session tickets is that they eliminate the effects of
|
|
Packit |
aea12f |
forward secrecy when a server uses the same key for long time. That is,
|
|
Packit |
aea12f |
the secrecy of all sessions on a server using tickets depends on the ticket
|
|
Packit |
aea12f |
key being kept secret. For that reason server keys should be rotated and discarded
|
|
Packit |
aea12f |
regularly.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Since version 3.1.3 GnuTLS clients transparently support session tickets,
|
|
Packit |
aea12f |
unless forward secrecy is explicitly requested (with the PFS priority string).
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Under TLS 1.3 session tickets are mandatory for session resumption, and they
|
|
Packit |
aea12f |
do not share the forward secrecy concerns as with TLS 1.2 or earlier.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node HeartBeat
|
|
Packit |
aea12f |
@subsection HeartBeat
|
|
Packit |
aea12f |
@cindex TLS extensions
|
|
Packit |
aea12f |
@cindex heartbeat
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
This is a TLS extension that allows to ping and receive confirmation from the peer,
|
|
Packit |
aea12f |
and is described in @xcite{RFC6520}. The extension is disabled by default and
|
|
Packit |
aea12f |
@funcref{gnutls_heartbeat_enable} can be used to enable it. A policy
|
|
Packit |
aea12f |
may be negotiated to only allow sending heartbeat messages or sending and receiving.
|
|
Packit |
aea12f |
The current session policy can be checked with @funcref{gnutls_heartbeat_allowed}.
|
|
Packit |
aea12f |
The requests coming from the peer result to @code{GNUTLS_@-E_@-HEARTBEAT_@-PING_@-RECEIVED}
|
|
Packit |
aea12f |
being returned from the receive function. Ping requests to peer can be send via
|
|
Packit |
aea12f |
@funcref{gnutls_heartbeat_ping}.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@showfuncB{gnutls_heartbeat_allowed,gnutls_heartbeat_enable}
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@showfuncD{gnutls_heartbeat_ping,gnutls_heartbeat_pong,gnutls_heartbeat_set_timeouts,gnutls_heartbeat_get_timeout}
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node Safe renegotiation
|
|
Packit |
aea12f |
@subsection Safe renegotiation
|
|
Packit |
aea12f |
@cindex renegotiation
|
|
Packit |
aea12f |
@cindex safe renegotiation
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
TLS gives the option to two communicating parties to renegotiate
|
|
Packit |
aea12f |
and update their security parameters. One useful example of this feature
|
|
Packit |
aea12f |
was for a client to initially connect using anonymous negotiation to a
|
|
Packit |
aea12f |
server, and the renegotiate using some authenticated ciphersuite. This occurred
|
|
Packit |
aea12f |
to avoid having the client sending its credentials in the clear.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
However this renegotiation, as initially designed would not ensure that
|
|
Packit |
aea12f |
the party one is renegotiating is the same as the one in the initial negotiation.
|
|
Packit |
aea12f |
For example one server could forward all renegotiation traffic to an other
|
|
Packit |
aea12f |
server who will see this traffic as an initial negotiation attempt.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
This might be seen as a valid design decision, but it seems it was
|
|
Packit |
aea12f |
not widely known or understood, thus today some application protocols use the TLS
|
|
Packit |
aea12f |
renegotiation feature in a manner that enables a malicious server to insert
|
|
Packit |
aea12f |
content of his choice in the beginning of a TLS session.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The most prominent vulnerability was with HTTPS. There servers request
|
|
Packit |
aea12f |
a renegotiation to enforce an anonymous user to use a certificate in order
|
|
Packit |
aea12f |
to access certain parts of a web site. The
|
|
Packit |
aea12f |
attack works by having the attacker simulate a client and connect to a
|
|
Packit |
aea12f |
server, with server-only authentication, and send some data intended
|
|
Packit |
aea12f |
to cause harm. The server will then require renegotiation from him
|
|
Packit |
aea12f |
in order to perform the request.
|
|
Packit |
aea12f |
When the proper client attempts to contact the server,
|
|
Packit |
aea12f |
the attacker hijacks that connection and forwards traffic to
|
|
Packit |
aea12f |
the initial server that requested renegotiation. The
|
|
Packit |
aea12f |
attacker will not be able to read the data exchanged between the
|
|
Packit |
aea12f |
client and the server. However, the server will (incorrectly) assume
|
|
Packit |
aea12f |
that the initial request sent by the attacker was sent by the now authenticated
|
|
Packit |
aea12f |
client. The result is a prefix plain-text injection attack.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The above is just one example. Other vulnerabilities exists that do
|
|
Packit |
aea12f |
not rely on the TLS renegotiation to change the client's authenticated
|
|
Packit |
aea12f |
status (either TLS or application layer).
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
While fixing these application protocols and implementations would be
|
|
Packit |
aea12f |
one natural reaction, an extension to TLS has been designed that
|
|
Packit |
aea12f |
cryptographically binds together any renegotiated handshakes with the
|
|
Packit |
aea12f |
initial negotiation. When the extension is used, the attack is
|
|
Packit |
aea12f |
detected and the session can be terminated. The extension is
|
|
Packit |
aea12f |
specified in @xcite{RFC5746}.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
GnuTLS supports the safe renegotiation extension. The default
|
|
Packit |
aea12f |
behavior is as follows. Clients will attempt to negotiate the safe
|
|
Packit |
aea12f |
renegotiation extension when talking to servers. Servers will accept
|
|
Packit |
aea12f |
the extension when presented by clients. Clients and servers will
|
|
Packit |
aea12f |
permit an initial handshake to complete even when the other side does
|
|
Packit |
aea12f |
not support the safe renegotiation extension. Clients and servers
|
|
Packit |
aea12f |
will refuse renegotiation attempts when the extension has not been
|
|
Packit |
aea12f |
negotiated.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Note that permitting clients to connect to servers when the safe
|
|
Packit |
aea12f |
renegotiation extension is not enabled, is open up for attacks.
|
|
Packit |
aea12f |
Changing this default behavior would prevent interoperability against
|
|
Packit |
aea12f |
the majority of deployed servers out there. We will reconsider this
|
|
Packit |
aea12f |
default behavior in the future when more servers have been upgraded.
|
|
Packit |
aea12f |
Note that it is easy to configure clients to always require the safe
|
|
Packit |
aea12f |
renegotiation extension from servers.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
To modify the default behavior, we have introduced some new priority
|
|
Packit |
aea12f |
strings (see @ref{Priority Strings}).
|
|
Packit |
aea12f |
The @code{%UNSAFE_RENEGOTIATION} priority string permits
|
|
Packit |
aea12f |
(re-)handshakes even when the safe renegotiation extension was not
|
|
Packit |
aea12f |
negotiated. The default behavior is @code{%PARTIAL_RENEGOTIATION} that will
|
|
Packit |
aea12f |
prevent renegotiation with clients and servers not supporting the
|
|
Packit |
aea12f |
extension. This is secure for servers but leaves clients vulnerable
|
|
Packit |
aea12f |
to some attacks, but this is a trade-off between security and compatibility
|
|
Packit |
aea12f |
with old servers. The @code{%SAFE_RENEGOTIATION} priority string makes
|
|
Packit |
aea12f |
clients and servers require the extension for every handshake. The latter
|
|
Packit |
aea12f |
is the most secure option for clients, at the cost of not being able
|
|
Packit |
aea12f |
to connect to legacy servers. Servers will also deny clients that
|
|
Packit |
aea12f |
do not support the extension from connecting.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
It is possible to disable use of the extension completely, in both
|
|
Packit |
aea12f |
clients and servers, by using the @code{%DISABLE_SAFE_RENEGOTIATION}
|
|
Packit |
aea12f |
priority string however we strongly recommend you to only do this for
|
|
Packit |
aea12f |
debugging and test purposes.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The default values if the flags above are not specified are:
|
|
Packit |
aea12f |
@table @code
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item Server:
|
|
Packit |
aea12f |
%PARTIAL_RENEGOTIATION
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item Client:
|
|
Packit |
aea12f |
%PARTIAL_RENEGOTIATION
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@end table
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
For applications we have introduced a new API related to safe
|
|
Packit |
aea12f |
renegotiation. The @funcref{gnutls_safe_renegotiation_status} function is
|
|
Packit |
aea12f |
used to check if the extension has been negotiated on a session, and
|
|
Packit |
aea12f |
can be used both by clients and servers.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node OCSP status request
|
|
Packit |
aea12f |
@subsection OCSP status request
|
|
Packit |
aea12f |
@cindex OCSP status request
|
|
Packit |
aea12f |
@cindex Certificate status request
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The Online Certificate Status Protocol (OCSP) is a protocol that allows the
|
|
Packit |
aea12f |
client to verify the server certificate for revocation without messing with
|
|
Packit |
aea12f |
certificate revocation lists. Its drawback is that it requires the client
|
|
Packit |
aea12f |
to connect to the server's CA OCSP server and request the status of the
|
|
Packit |
aea12f |
certificate. This extension however, enables a TLS server to include
|
|
Packit |
aea12f |
its CA OCSP server response in the handshake. That is an HTTPS server
|
|
Packit |
aea12f |
may periodically run @code{ocsptool} (see @ref{ocsptool Invocation}) to obtain
|
|
Packit |
aea12f |
its certificate revocation status and serve it to the clients. That
|
|
Packit |
aea12f |
way a client avoids an additional connection to the OCSP server.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
See @ref{OCSP stapling} for further information.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Since version 3.1.3 GnuTLS clients transparently support the certificate status
|
|
Packit |
aea12f |
request.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node SRTP
|
|
Packit |
aea12f |
@subsection SRTP
|
|
Packit |
aea12f |
@cindex SRTP
|
|
Packit |
aea12f |
@cindex Secure RTP
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The TLS protocol was extended in @xcite{RFC5764} to provide keying material to the
|
|
Packit |
aea12f |
Secure RTP (SRTP) protocol. The SRTP protocol provides an encapsulation of encrypted
|
|
Packit |
aea12f |
data that is optimized for voice data. With the SRTP TLS extension two peers can
|
|
Packit |
aea12f |
negotiate keys using TLS or DTLS and obtain keying material for use with SRTP. The
|
|
Packit |
aea12f |
available SRTP profiles are listed below.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@showenumdesc{gnutls_srtp_profile_t,Supported SRTP profiles}
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
To enable use the following functions.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@showfuncB{gnutls_srtp_set_profile,gnutls_srtp_set_profile_direct}
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
To obtain the negotiated keys use the function below.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@showfuncdesc{gnutls_srtp_get_keys}
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Other helper functions are listed below.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@showfuncC{gnutls_srtp_get_selected_profile,gnutls_srtp_get_profile_name,gnutls_srtp_get_profile_id}
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node False Start
|
|
Packit |
aea12f |
@subsection False Start
|
|
Packit |
aea12f |
@cindex False Start
|
|
Packit |
aea12f |
@cindex TLS False Start
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The TLS protocol was extended in @xcite{RFC7918} to allow the client
|
|
Packit |
aea12f |
to send data to server in a single round trip. This change however operates on the borderline
|
|
Packit |
aea12f |
of the TLS protocol security guarantees and should be used for the cases where the reduced
|
|
Packit |
aea12f |
latency outperforms the risk of an adversary intercepting the transferred data. In GnuTLS
|
|
Packit |
aea12f |
applications can use the @acronym{GNUTLS_ENABLE_FALSE_START} as option to @funcref{gnutls_init}
|
|
Packit |
aea12f |
to request an early return of the @funcref{gnutls_handshake} function. After that early
|
|
Packit |
aea12f |
return the application is expected to transfer any data to be piggybacked on the last handshake
|
|
Packit |
aea12f |
message.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
After handshake's early termination, the application is expected to transmit
|
|
Packit |
aea12f |
data using @funcref{gnutls_record_send}, and call @funcref{gnutls_record_recv} on
|
|
Packit |
aea12f |
any received data as soon, to ensure that handshake completes timely. That is, especially
|
|
Packit |
aea12f |
relevant for applications which set an explicit time limit for the handshake process
|
|
Packit |
aea12f |
via @funcref{gnutls_handshake_set_timeout}.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Note however, that the API ensures that the early return will not happen
|
|
Packit |
aea12f |
if the false start requirements are not satisfied. That is, on ciphersuites which are not
|
|
Packit |
aea12f |
whitelisted for false start or on insufficient key sizes, the handshake
|
|
Packit |
aea12f |
process will complete properly (i.e., no early return). To verify that false start was used you
|
|
Packit |
aea12f |
may use @funcref{gnutls_session_get_flags} and check for the @acronym{GNUTLS_SFLAGS_FALSE_START}
|
|
Packit |
aea12f |
flag. For GnuTLS the false start is whitelisted for the following
|
|
Packit |
aea12f |
key exchange methods (see @xcite{RFC7918} for rationale)
|
|
Packit |
aea12f |
@itemize
|
|
Packit |
aea12f |
@item DHE
|
|
Packit |
aea12f |
@item ECDHE
|
|
Packit |
aea12f |
@end itemize
|
|
Packit |
aea12f |
but only when the negotiated parameters exceed @code{GNUTLS_SEC_PARAM_HIGH}
|
|
Packit |
aea12f |
--see @ref{tab:key-sizes}, and when under (D)TLS 1.2 or later.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node Application Layer Protocol Negotiation (ALPN)
|
|
Packit |
aea12f |
@subsection Application Layer Protocol Negotiation (ALPN)
|
|
Packit |
aea12f |
@cindex ALPN
|
|
Packit |
aea12f |
@cindex Application Layer Protocol Negotiation
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
The TLS protocol was extended in @code{RFC7301}
|
|
Packit |
aea12f |
to provide the application layer a method of
|
|
Packit |
aea12f |
negotiating the application protocol version. This allows for negotiation
|
|
Packit |
aea12f |
of the application protocol during the TLS handshake, thus reducing
|
|
Packit |
aea12f |
round-trips. The application protocol is described by an opaque
|
|
Packit |
aea12f |
string. To enable, use the following functions.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@showfuncB{gnutls_alpn_set_protocols,gnutls_alpn_get_selected_protocol}
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
Note that these functions are intended to be used with protocols that are
|
|
Packit |
aea12f |
registered in the Application Layer Protocol Negotiation IANA registry. While
|
|
Packit |
aea12f |
you can use them for other protocols (at the risk of collisions), it is preferable
|
|
Packit |
aea12f |
to register them.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node Extensions and Supplemental Data
|
|
Packit |
aea12f |
@subsection Extensions and Supplemental Data
|
|
Packit |
aea12f |
@cindex Supplemental data
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
It is possible to transfer supplemental data during the TLS handshake, following
|
|
Packit |
aea12f |
@xcite{RFC4680}. This is for "custom" protocol modifications for applications which
|
|
Packit |
aea12f |
may want to transfer additional data (e.g. additional authentication messages). Such
|
|
Packit |
aea12f |
an exchange requires a custom extension to be registered.
|
|
Packit |
aea12f |
The provided API for this functionality is low-level and described in @ref{TLS Hello Extension Handling}.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@include sec-tls-app.texi
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@node On SSL 2 and older protocols
|
|
Packit |
aea12f |
@section On SSL 2 and older protocols
|
|
Packit |
aea12f |
@cindex SSL 2
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
One of the initial decisions in the @acronym{GnuTLS} development was
|
|
Packit |
aea12f |
to implement the known security protocols for the transport layer.
|
|
Packit |
aea12f |
Initially @acronym{TLS} 1.0 was implemented since it was the latest at
|
|
Packit |
aea12f |
that time, and was considered to be the most advanced in security
|
|
Packit |
aea12f |
properties. Later the @acronym{SSL} 3.0 protocol was implemented
|
|
Packit |
aea12f |
since it is still the only protocol supported by several servers and
|
|
Packit |
aea12f |
there are no serious security vulnerabilities known.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
One question that may arise is why we didn't implement @acronym{SSL}
|
|
Packit |
aea12f |
2.0 in the library. There are several reasons, most important being
|
|
Packit |
aea12f |
that it has serious security flaws, unacceptable for a modern security
|
|
Packit |
aea12f |
library. Other than that, this protocol is barely used by anyone
|
|
Packit |
aea12f |
these days since it has been deprecated since 1996. The security
|
|
Packit |
aea12f |
problems in @acronym{SSL} 2.0 include:
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@itemize
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item Message integrity compromised.
|
|
Packit |
aea12f |
The @acronym{SSLv2} message authentication uses the MD5 function, and
|
|
Packit |
aea12f |
is insecure.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item Man-in-the-middle attack.
|
|
Packit |
aea12f |
There is no protection of the handshake in @acronym{SSLv2}, which
|
|
Packit |
aea12f |
permits a man-in-the-middle attack.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item Truncation attack.
|
|
Packit |
aea12f |
@acronym{SSLv2} relies on TCP FIN to close the session, so the
|
|
Packit |
aea12f |
attacker can forge a TCP FIN, and the peer cannot tell if it was a
|
|
Packit |
aea12f |
legitimate end of data or not.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@item Weak message integrity for export ciphers.
|
|
Packit |
aea12f |
The cryptographic keys in @acronym{SSLv2} are used for both message
|
|
Packit |
aea12f |
authentication and encryption, so if weak encryption schemes are
|
|
Packit |
aea12f |
negotiated (say 40-bit keys) the message authentication code uses the
|
|
Packit |
aea12f |
same weak key, which isn't necessary.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@end itemize
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
@cindex PCT
|
|
Packit |
aea12f |
Other protocols such as Microsoft's @acronym{PCT} 1 and @acronym{PCT}
|
|
Packit |
aea12f |
2 were not implemented because they were also abandoned and deprecated
|
|
Packit |
aea12f |
by @acronym{SSL} 3.0 and later @acronym{TLS} 1.0.
|
|
Packit |
aea12f |
|
|
Packit |
aea12f |
|