TLSv1.3
TLS stands for Transport Layer Security and is the successor to SSL (Secure Sockets Layer). TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This section mostly focus on TLSv 1.3. TLS 1.3 was defined in RFC 8446 in August 2018. It is based on the earlier TLS 1.2 specification.
TLS Histrory and Development
| Protocol | Published |
|---|---|
| SSL 1.0 | Unpublished |
| SSL 2.0 | 1995 |
| SSL 3.0 | 1996 |
| TLS 1.0 | 1999 |
| TLS 1.1 | 2006 |
| TLS 1.2 | 2008 |
| TLS 1.3 | 2018 |
TLS1.3 has been over eight years since the last encryption protocol update, but the final version of TLS 1.3 has now been published as of August 2018 Image Ref
Major Differences from TLS 1.2
From the Wireshark packet capture, its clearly visible the TLSv.1.3, the number of packets is being reduced this offer better speed in TLS v1.3 , and some of the major changes from TLS1.2 as follows
- The list of supported symmetric encryption algorithms has been pruned of all algorithms that are considered legacy. Those that remain are all Authenticated Encryption with Associated Data (AEAD) algorithms.
- The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with both the key derivation function and handshake message authentication code (MAC).
- A zero round-trip time (0-RTT) mode was added, saving a round trip at connection setup for some application data, at the cost of certain security properties. IMP 0-rtt should be avoided , there are proven replay attack has been found
- All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtensions message allows various extensions previously sent in the clear in the ServerHello to also enjoy confidentiality protection.
- Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
- The key derivation functions have been redesigned.
- The handshake state machine has been significantly restructured to be more consistent and to remove superfluous messages such as ChangeCipherSpec (except when needed for middlebox compatibility).
- Elliptic curve algorithms are now in the base spec, and new signature algorithms, such as EdDSA, are included. TLS 1.3 removed point format negotiation in favor of a single point format for each curve.
- The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation.
- Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange
TLS 1.3 Handshake
The handshake can be thought of as having three phases (indicated in the diagram below)

- In the first phase, the client sends the ClientHello message, which contains
- random nonce (ClientHello.random);
- protocol versions;
- symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key shares (in the “key_share” extension
- A set of pre- shared key labels (in the “pre_shared_key” extension or both;
- And potentially additional extensions.
The “key_share” extension contains the endpoint’s cryptographic parameters.In TLSv1.3 the client selects a “groupâ€� that it will use for key exchange.
The PSK: If clients offer “pre_shared_key” without a “psk_key_exchange_modes” extension, servers abort the handshake and used to negotiate the identity of the pre-shared key to be used with a given handshake in association with PSK key establishment
- The server processes the ClientHello and determines the appropriate cryptographic parameters for the connection. It then responds with its own ServerHello which indicates the negotiated connection parameters. The combination of the ClientHello and the ServerHello determines the shared keys
- Upon receiving the server’s messages, the client responds with its Authentication messages, namely Certificate and CertificateVerify (if requested), and Finished.
Ciphersuites
OpenSSL has implemented support for five TLSv1.3 ciphersuites as follows:
- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_GCM_SHA256
- TLS_AES_128_CCM_8_SHA256
- TLS_AES_128_CCM_SHA256
openssl ciphers -v | grep TLSv1.3 TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=\ AEAD TLS_AES_128_GCM_SHA256 **TLSv1.3** Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
Start the TLS1.3 server in openssl
The forthcoming openssl 1.1.1-pre9 (beta) release has included support for TLSv1.3.
openssl version
OpenSSL 1.1.1-pre9 (beta) 21 Aug 2018
openssl command to start the tls1.3 server
openssl s_server -accept 443 -tls1_3 -ciphersuites TLS_AES_256_GCM_SHA384 -key key.\
pem -cert cert.pem
Using default temp DH parameters
ACCEPT
Connect to TLS1.3
The openssl command to connect to tlsv1.3.
openssl s_client -connect 127.0.0.1:443
-----
-----
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self signed certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 2BC1AB6B0BE58B527AE4CAEFEABC6D9654094BC1F4D529E5F3F0912A80C97001
Session-ID-ctx:
Resumption PSK: EA4A8E23B397F4F822B770C0922F47F7A66F6A7AA2F2DC4B94B961941AA87ACD\
611AC293259EFB130887F9A2D02AC89E
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
Browser Support
Checkout the browser compatibility for TLS 1.3 here : https://caniuse.com/#feat=tls1-3