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