By Michael Gray and Keiran Robinson
TLS 1.3, RFC 8446, was published in August 2018 and is a major update to TLS 1.2, RFC 5246, published in August 2008.
Works out of the box
Reverse Proxy support for TLS 1.3 was introduced to ISAM in version 9.0.7.0. The new configuration entries can be found in the [ssl] and [junctions] stanzas of the Reverse Proxy configuration file alongside the existing entries which control the enabled SSL protocols. By default, TLS 1.3 is disabled on new or existing Reverse Proxy instances.
To enable TLS 1.3 for the Reverse Proxy front end, set [ssl] disable-tls-v13 to false.
To enable TLS 1.3 for backend (junctioned) application connections, set [junction] disable-tls-v13 to false.
Note that if TLS 1.3 is enabled, SSL 2.0 and SSL 3.0 will be disabled regardless of any value provided for disable-ssl-v2 or disable-ssl-v3.
Individual ciphers can be managed using the [ssl-qop-mgmt-default] stanza. A complete list of ciphers can be found in the stanza reference documentation.
Forward Secrecy
TLS 1.3 only has Forward Secrecy (ECDHE CipherSuites) CipherSuites. By default the X22519 ‘safe’ curve (https://safecurves.cr.yp.to/) is used (NIST announced it will be FIPS approved) giving effective security of 125.8 bits.
Note: The safe curves; X22519 (Bernstein) and X448 (Goldilocks; 222.8 bit security) are currently less performant than NIST P256 (127.8 bit security) as P256 is highly optimised however this gap is expected to close over time.
Also note that Finite Field Diffie–Hellman key agreement is not currently supported.
Session Tickets
TLS 1.3 uses Session Tickets instead of Session IDs for Session Resumption. ISAM uses Session Tickets in a Forward Secrecy mode that causes the SID Cache to be reused and the cache operation, size wise, is same as TLSV12 although caches update will be more frequent. This mode of operation prevents secrets being transmitted between the Server and Client to ensure Forward Secrecy.
ISAM also operates in a Resumption Forward Secrecy mode which means a new Key Share is computed for each resumption.
Additionally, Session Tickets have single use only which means a new Session Ticket is issued for every resume operation.
Encrypted Handshake
In TLS 1.3 only the Client Hello and Server Hello are transmitted in Clear Text. All other handshake messages are encrypted and appear as application data flow on the wire; however, it is still possible to deduce aspects of the handshake message flow from size and sequence.
Handshake Revealed
Middle Box Compatibility
GSKit always operates in what is called the TLS 1.3 Middle Box compatibility mode i.e. it sends fake ChangeCipherSpec and Phoney Session ID’s to maximise interoperability. In this way the Middle Box assumes that it is seeing a session resumption handshake.
Automatic Key Updates
When using AES GCM in TLS 1.3, Keys will be updated transparently every 2^24.5 (23,726,566) records.
The ChaChaPoly1305 CipherSuite does not require Key Updates.
Security Enforcement
TLS 1.3 enforces 112 bit minimum security which means RSA Keys must be >= 2048, EC keys >= 224 and DSA Keys >= 2048
Additionally, TLS 1.3 will not allow fallback to a peer that is offering weak ciphers i.e. less than 112 bits of security.
Caveat
TLS 1.3 will not work with traffic inspectors as RSA Key Exchange is not supported by TLS 1.3.
