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