Editing Transport Layer Security (section)

====TLS 1.3 handshake====

The TLS 1.3 handshake was condensed to only one round trip compared to the two round trips required in previous versions of TLS/SSL.

To start the handshake, the client guesses which key exchange algorithm will be selected by the server and sends a '''ClientHello''' message to the server containing a list of supported ciphers (in order of the client's preference) and public keys for some or all of its key exchange guesses. If the client successfully guesses the key exchange algorithm, 1 round trip is eliminated from the handshake. After receiving the '''ClientHello''', the server selects a cipher and sends back a '''ServerHello''' with its own public key, followed by server '''Certificate''' and '''Finished''' messages.<ref>{{cite IETF|title= The Transport Layer Security (TLS) Protocol Version 1.3|rfc=8446|section=4.1.1 |sectionname=Cryptographic Negotiation|publisher=IETF |date=August 2018 |last1=Rescorla |first1=Eric }}</ref>

After the client receives the server's finished message, it now is coordinated with the server on which cipher suite to use.<ref>{{cite web|last=Valsorda|first=Filippo|title=An overview of TLS 1.3 and Q&A|url=https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a|website=The Cloudflare Blog|date=23 September 2016|access-date=3 May 2019|archive-date=3 May 2019|archive-url=https://web.archive.org/web/20190503043936/https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/|url-status=live}}</ref>

=====Session IDs=====
In an ordinary ''full'' handshake, the server sends a ''session id'' as part of the '''ServerHello''' message. The client associates this ''session id'' with the server's IP address and TCP port, so that when the client connects again to that server, it can use the ''session id'' to shortcut the handshake. In the server, the ''session id'' maps to the cryptographic parameters previously negotiated, specifically the "master secret". Both sides must have the same "master secret" or the resumed handshake will fail (this prevents an eavesdropper from using a ''session id''). The random data in the '''ClientHello''' and '''ServerHello''' messages virtually guarantee that the generated connection keys will be different from in the previous connection. In the RFCs, this type of handshake is called an ''abbreviated'' handshake. It is also described in the literature as a ''restart'' handshake.

#Negotiation phase:
#*A client sends a '''ClientHello''' message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods. Included in the message is the ''session id'' from the previous TLS connection.
#*The server responds with a '''ServerHello''' message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. If the server recognizes the ''session id'' sent by the client, it responds with the same ''session id''. The client uses this to recognize that a resumed handshake is being performed. If the server does not recognize the ''session id'' sent by the client, it sends a different value for its ''session id''. This tells the client that a resumed handshake will not be performed. At this point, both the client and server have the "master secret" and random data to generate the key data to be used for this connection.
#The server now sends a '''ChangeCipherSpec''' record, essentially telling the client, "Everything I tell you from now on will be encrypted." The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
#*Finally, the server sends an encrypted '''Finished''' message, containing a hash and MAC over the previous handshake messages.
#*The client will attempt to decrypt the server's ''Finished'' message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
#Finally, the client sends a '''ChangeCipherSpec''', telling the server, "Everything I tell you from now on will be encrypted."
#*The client sends its own encrypted '''Finished''' message.
#*The server performs the same decryption and verification procedure as the client did in the previous step.
#Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their ''Finished'' message.

=====Session tickets=====
{{IETF RFC|5077}} extends TLS via use of session tickets, instead of session IDs. It defines a way to resume a TLS session without requiring that session-specific state is stored at the TLS server.

When using session tickets, the TLS server stores its session-specific state in a session ticket and sends the session ticket to the TLS client for storing. The client resumes a TLS session by sending the session ticket to the server, and the server resumes the TLS session according to the session-specific state in the ticket. The session ticket is encrypted and authenticated by the server, and the server verifies its validity before using its contents.

One particular weakness of this method with [[OpenSSL]] is that it always limits encryption and authentication security of the transmitted TLS session ticket to <code>AES128-CBC-SHA256</code>, no matter what other TLS parameters were negotiated for the actual TLS session.<ref name="ticketsecwp">{{cite web|title=TLS "Secrets": Whitepaper presenting the security implications of the deployment of session tickets (RFC 5077) as implemented in OpenSSL|first=Florent|last=Daignière|publisher=Matta Consulting Limited|access-date=7 August 2013|url=https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf|url-status=live|archive-url=https://web.archive.org/web/20130806233112/https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf|archive-date=6 August 2013}}</ref> This means that the state information (the TLS session ticket) is not as well protected as the TLS session itself. Of particular concern is OpenSSL's storage of the keys in an application-wide context (<code>SSL_CTX</code>), i.e. for the life of the application, and not allowing for re-keying of the <code>AES128-CBC-SHA256</code> TLS session tickets without resetting the application-wide OpenSSL context (which is uncommon, error-prone and often requires manual administrative intervention).<ref name="ticketsecslides">{{cite web|title=TLS "Secrets": What everyone forgot to tell you…|first=Florent|last=Daignière|publisher=Matta Consulting Limited|access-date=7 August 2013|url=https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-Slides.pdf|url-status=live|archive-url=https://web.archive.org/web/20130805134805/https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-Slides.pdf|archive-date=5 August 2013}}</ref><ref name="botchingpfs">{{cite web|title=How to botch TLS forward secrecy|first=Adam|last=Langley|website=imperialviolet.org|date=27 June 2013|url=https://www.imperialviolet.org/2013/06/27/botchingpfs.html|url-status=live|archive-url=https://web.archive.org/web/20130808221614/https://www.imperialviolet.org/2013/06/27/botchingpfs.html|archive-date=8 August 2013}}</ref>