Explore Cisco
How to Buy

Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

Adopting TLS 1.3 on Cisco Secure Web Appliance (formerly Web Security Appliance): A Step Forward White Paper

White Paper

Available Languages

Download Options

  • PDF
    (1.0 MB)
    View with Adobe Reader on a variety of devices
Updated:December 16, 2020

Available Languages

Download Options

  • PDF
    (1.0 MB)
    View with Adobe Reader on a variety of devices
Updated:December 16, 2020

Table of Contents



Communication over the internet is susceptible to a range of attacks including message tampering, forgery, and spying. This makes it critical to protect confidential or business transaction against any data leakage. Securing your interaction over the Internet involves securing both the communication channel and the data itself.

What is Transport Layer Security (TLS)?

TLS is the core security protocol of internet securing internet communication between applications (like web browsers) and servers. It uses asymmetric cryptography for connection establishment and shared secret key is negotiated at the beginning of a session, referred as a TLS handshake. The shared key is then used for symmetric cryptography after connection establishment.

The Internet Engineering Task Force (IETF) (https://www.ietf.org) has a TLS working group (https://datatracker.ietf.org/wg/tls/about) for standardizing and developing it.

Timeline of TLS Evolution

Evolution of TLS

IP based protocols including HTTPS, FTP, SMTP/POP3 support TLS to encrypt session data. TLS evolved primarily due to vulnerabilities in erstwhile SSL (Secure Sockets Layer) and went through various iterations as depicted at right:

TLS 1.3 is the latest standard which addresses vulnerabilities in previous versions, optimizes performance and improves privacy. It will provide a solid foundation for secure and efficient communication over the internet.

TLS handshake

Before communicating any data over the internet, the client and server establish a secure channel between them by validating each other and agreeing to encryption and session parameters - known as TLS handshake.

In TLS 1.2 or earlier, two round trips are required to complete the TLS handshake (as depicted below):

TLS 1.2 handshake

TLS 1.2 handshake

1.     The Client sends a ClientHello message with highest supported TLS version, supported cipher suites, compression methods and other session parameters.

2.     The server responds with a ServerHello message with selected cipher suite, TLS version, selected compression method and other session parameters. The server also sends a certificate to prove its identity to the client and its share of key (needed to derive key for encrypting application data).

3.     The client verifies the server certificate and post successful verification, sends its key share encrypted with server’s public key. It sends a ChangeCipherSpec message to signal that subsequent messages will be encrypted using the negotiated cipher and sends an encrypted Finished message.

4.     The server confirms the switch to the encrypted mode with a ChangeCipherSpec message and sends an encrypted Finished message to complete TLS handshake. Encrypted finished messages ensure the integrity of the TLS handshake.

After successful TLS handshake, the client and server begin to share application data.

TLS 1.3 Benefits

Major differences or improvements in TLS 1.3 when compared to TLS 1.2 are:

Strengthened security:

      Vulnerable key exchange cipher suites like static RSA and Diffie-Hellman are not supported. Public-key based key exchange mechanisms (such as Ephemeral Diffie-Hellman) now provide Perfect Forward Secrecy (PFS). PFS ensures that past sessions are protected against any future compromises of session keys or passwords.

      Vulnerable symmetric algorithms like RC4 and CBC have been deprecated and only Authenticated Encryption with Associated Data (AEAD) algorithms are used for symmetric encryption. The cipher suite concept separates the authentication and key exchange mechanisms from the record protection algorithm (including secret key length). A hash must be used with both the key derivation function and handshake Message Authentication Code (MAC).

      The entire TLS handshake after ServerHello message is encrypted so that attackers cannot modify parameters in the handshake. The EncryptedExtensions message is used to encrypt extensions sent in clear earlier (including the certificate).

      The TLS 1.2 re-negotiation mechanism has been deprecated.

      MD5 and SHA1, SHA224 cryptographic hash functions are no longer supported.

      Improvements in signatures by using RSA-PSS (Probabilistic Signature Scheme) and the removal of compression, the Digital Signature Algorithm (DSA), and custom Ephemeral Diffie-Hellman (DHE) groups.

Optimized for performance:

      Simplified TLS handshake due to lesser key exchange algorithms with defined parameters and few supported ciphers

      Reduced latency by supporting one round trip time (1-RTT):

TLS 1.3 supports 1-RTT to complete TLS handshake compared to minimum 2-RTT required in TLS 1.2 for every new session. This reduces session establishment time and, proportionally reducing latency in web requests using TLS 1.3 (as depicted below):

TLS 1.2 handshake

TLS 1.2 handshake

TLS 1.3 handshake

1.     The client sends it’s DH key share or pre-shared key in the ClientHello by pre-guessing the cryptographic information which the server will use instead of first negotiating parameters.

2.     The server responds with ServerHello message with its key share and other cryptographic information like certificate for authentication. The certificate is encrypted in TLS 1.3, and sent as a part of EncryptedExtensions.

The TLS handshake is completed in 1-RTT provided the client successfully pre-guesses the cryptographic information.

Additional improvements:

a. Introduction of 0-RTT mode in TLS 1.3 (also known as resumption mode)

In 0-RTT, the client and the server both save the pre-shared encryption key from previous transaction locally. Next time, the client can use this key to send encrypted data to the server in the first message itself. Effectively, the RTT is reduced to zero by eliminating the first TLS handshake itself.

TLS 1.3 0-RTT resumption mode

TLS 1.3 0-RTT resumption mode

Secure Web Appliance does not support 0-RTT due to the inherent security flaw – Replayability.

If an attacker captures the 0-RTT packet, then it can be replayed, and the server will accept it as a valid request. If the 0-RTT packet is intended to change server state like modifying the database to increment or decrement (for example, altering balance in a bank account) then it is very risky.

b. Improved privacy and support for encrypted SNI

TLS 1.3 supports EncryptedExtensions which encrypts all TLS handshake data after ServerHello message including server certificate. So, eavesdroppers cannot snoop on the server certificate which was sent in clear earlier.

Encrypted SNI is not part of TLS 1.3 specification and tracked as a separate internet draft: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption.

The TLS Server Name Indication (SNI) extension allows web clients to specify which site they want to connect to in a server that is hosting multiple TLS-enabled sites on the same IP. SNI information allows the server to know which certificate and configuration to use. The SNI info can be intercepted to track which websites internet users are visiting even though they are using HTTPS, which lead to privacy concerns.

TLS 1.3 along with Encrypted SNI will improve privacy but the web usage can still be tracked using other means like monitoring DNS requests.

TLS 1.3 on the Cisco Secure Web Appliance

The previous whitepaper - Speed, Privacy, and Control on the Web highlights detailed use-cases of TLS handling with Secure Web Appliance and associated challenges with Async OS 11.8 or earlier.

The Secure Web Appliance now supports TLSv1.3 as part of AsyncOS 12.0. Cipher ‘TLS_AES_256_GCM_SHA384’ is added to the default cipher list and TLSv1.3 is enabled on the appliance by default.

TLS 1.3 passthrough

TLS 1.3 passthrough

Secure Web Appliance supports TLS 1.3 in both passthrough and decrypt mode.

For a TLS ClientHello message from an end-client, Secure Web Appliance establishes a separate TLS 1.3 session to webserver to validate the Common Name, Subject Alternative Name, validity of the web server certificate, the issuer and matches to a policy.

If the decision is passthrough, then Secure Web Appliance closes its connection with the web server and the end-client establishes a TLS connection directly with the web server.

TLS 1.3 decrypt

TLS 1.3 decrypt

If the decision is to decrypt, then Secure Web Appliance sits in middle maintaining two separate TLS sessions (with the end-client and the webserver), decrypting traffic and taking configured policy action(s) on web requests. This also means that Secure Web Appliance can establish a TLS 1.3 connection to the server, even when the client does not support it.


By supporting TLS 1.3, Secure Web Appliance has taken a big step forward towards a secure internet access. Now, you can be secure by leveraging strengthened security in TLS 1.3, enjoy reduced latency in web requests due to faster handshake and make most of available resources at the same time!


To learn more about Cisco Secure Web Appliance, go to cisco.com/go/websecurity.

Learn more