Abbreviated TLS handshake after HA failover

TLS sessions that pass through an HA A-A or A-P cluster can use an abbreviated TLS handshake instead of a full TLS handshake upon failover from a primary HA unit to a secondary HA unit. This reduces session pickup delays by reducing the time needed to renegotiate the TLS session, given that the TLS session ticket can be re-used.

To accomplish this, FortiOS uses the web proxy global ssl-ca-cert to generate the key used in the TLS session ticket:

config web-proxy global
    set ssl-ca-cert "Fortinet_CA_SSL"
end

The certificate can be synchronized to the secondary HA unit, which allows the secondary unit to generate the same session key for a TLS session. When a TLS session reconnects after HA failover using the same session ticket as the first session, the new primary unit is able to generate the same key matching that session ticket and allow an abbreviated handshake.

Example

In this example, OpenSSL is used to create a TLS session between the client and the server through the primary FortiGate. The session ticket is outputted and saved. Upon failover, the same session ticket is reused to create a TLS session through the new primary unit. Because the new primary unit uses the same certificate to generate the key for the TLS session ticket, it allows the connection to be made using an abbreviated TLS handshake.

This example is for demonstration purposes only. In a normal failover, TLS sessions from clients will automatically be able to re-establish using an abbreviated handshake through the new primary unit.

To verify if an abbreviated TLS handshake is used after HA failover:

1. On the client using OpenSSL, open a new session to 172.16.200.44:443 and output the session ticket to a file called aaa.txt. This session will pass through the current HA primary unit:

   # openssl s_client -connect 172.16.200.44:443 -sess_out aaa.txt

2. Fail over the primary unit to the secondary unit. The HA secondary unit starts handling the traffic.

3. On the client, try connecting to 172.16.200.44:443 using the same saved session ticket as before (aaa.txt):

   # openssl s_client -connect 172.16.200.44:443 -sess_in aaa.txt

4. Verify whether the session succeeds in using the original session ticket:

   Reused, 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: 19 (self signed certificate in certificate chain)
   ...

   If the session is established using the same ticket, Reused, TLSv1.3, Cipher is <name> is displayed. If session is established using a new ticket, New, TLSv1.3, Cipher is <name> is displayed.

   The new primary is able to use the web proxy global ssl-ca-cert to generate the same key as the old primary that was used in the session ticket. So, the second TLS connection that reuses the TLS session ticket from the first session can complete an abbreviated TLS handshake.