Understanding the AnyConnect SSL VPN Connection Flow

Introduction

This document focuses on the flow of events that take place between AnyConnect and the secure gateway during an SSLVPN connection.

Background Information

AnyConnect

AnyConnect is the Cisco VPN client designed for SSL and IKEv2 protocols. It is available for most of the desktop and mobile platforms. AnyConnect primarily establishes secure connections with Firepower Threat Defense (FTD), Adaptive Security Appliances (ASA), or Cisco IOS®/Cisco IOS® XE routers referred to as Secure Gateways.

Secure Gateway

In Cisco terminology, an SSL VPN server is referred to as a Secure Gateway, while an IPSec (IKEv2) server is known as a Remote Access VPN Gateway. Cisco supports SSL VPN tunnel termination on these platforms:

• Cisco ASA 5500 and 5500-X Series
• Cisco FTD (2100, 4100, and 9300 Series)
• Cisco ISR 4000 and ISR G2 Series
• Cisco CSR 1000 Series
• Cisco Catalyst 8000 Series

AnyConnect SSL VPN Connection Flow

This document breaks down the events that take place between AnyConnect and the Secure Gateway during an SSL VPN connection establishment into six phases:

1. SSL Handshake

2. POST - Group Selection

3. POST - User Authentication with Username/Password (Optional)

4. VPN Downloader (Optional)

5. CSTP CONNECT

6. DTLS Connection (Optional)

1. SSL Handshake

The SSL handshake is initiated by the AnyConnect client after the completion of the TCP 3-way handshake with a 'Client Hello' message. The flow of events and the key takeaways are as mentioned.

Client Hello

The SSL session begins with the client sending a 'Client Hello' message. In this message:

a) The SSL Session ID is set to 0, indicating the initiation of a new session.

b) The payload includes the client-supported cipher suites and a client-generated random nonce.

Server Hello

The server responds with a "Server Hello" message, which includes:

a) The selected cipher suite from the list provided by the client.

b) The server generated the SSL Session ID, and a server generated a random nonce.

Server Certificate

After the 'Server Hello', the server transmits its SSL certificate, which serves as its identity. Key points to note include:

a) If this certificate fails a strict validation check, AnyConnect, by default, blocks the server.

b) The user has the option to disable this block, but subsequent connections display a warning until the reported errors are resolved.

Client Certificate Request

The server can also request a client certificate, sending a list of Subject Name DNs of all the CA certificates loaded on the Secure Gateway. This request serves two purposes:

a) It helps the client (user) choose the correct identity certificate if multiple ID certificates are available.

b) Ensures that the returned certificate is trusted by the Secure Gateway, although further certificate validation must still occur.

Client Key Exchange

The client then sends a 'Client Key Exchange' message, which includes a pre-master secret key. This key is encrypted using:

a) The public key of the server from the server certificate, if the chosen cipher suite is RSA-based (for example, TLS_RSA_WITH_AES_128_CBC_SHA).

b) The DH public key of the server provided in the Server Hello message, if the chosen cipher suite is DHE-based (for example, TLS_DHE_DSS_WITH_AES_256_CBC_SHA).

Based on the pre-master secret, the client-generated random nonce, and the server-generated random nonce, both the client and the Secure Gateway independently generate a master secret. This master secret is then used to derive session keys, ensuring secure communication between the client and the server.

SSL Session 1

2. POST - Group Selection

During this operation, the client does not possess information about the connection profile unless explicitly specified by the user. The connection attempt is directed towards the Secure Gateway URL (asav.cisco.com), as indicated by the 'group-access' element in the request. The client indicates its support for 'aggregate-authentication' version 2. This version represents a significant improvement over the earlier version, particularly in terms of efficient XML transactions. Both the secure gateway and the client must agree on the version to be used. In scenarios where the secure gateway does not support version 2, an additional POST operation is triggered, causing the client to fall back to the version.

In the HTTP response, the secure gateway indicates these:

1. The version of aggregate authentication that the secure gateway supports.

2. Tunnel group list and the Username/Password Form. 

Note: The Form includes a 'select' element, which lists the group aliases of all connection profiles configured on the secure gateway. By default, one of these group aliases is highlighted with the selected = "true" boolean attribute. The tunnel-group and group-alias elements correspond to this chosen connection profile. 

POST - Group Selection 1

If the user chooses a different connection profile from this list, another POST operation takes place. In this case, the client sends a POST request with the 'group-select' element updated in order to reflect the chosen connection profile, as shown here.

POST - Group Selection 2

3. POST - User Authentication

In this operation, which follows the POST-Group Selection, AnyConnect sends this information to the Secure Gateway:

1. Chosen Connection Profile Information: This includes the tunnel-group name and the group alias as indicated by the Secure Gateway in the earlier operation.

2. Username and Password: The authentication credentials of the user.

Note: Since this flow is specific to AAA authentication, it can differ from other authentication methods.

In response to the POST operation, the Secure Gateway sends an XML file containing this information:

1. Session ID: This is not the same as the SSL session ID.

2. Session Token: This token is later used by the client as the WebVPN cookie.

3. Authentication Status: Indicated by an auth element with id = 'success'.

4. Server Certificate Hash: This hash is cached in the preferences.xml file.

5. vpn-core-manifest Element: This element indicates the path and version of the AnyConnect core package, along with other components like Dart, Posture, ISE Posture, and so on. It is used by the VPN Downloader in the next section.

6. vpn-profile-manifest Element: This element indicates the path (the name of the profile) and the SHA-1 hash of the profile.

Note: If the client does not have the profile, the VPN Downloader in the next section downloads it. If the client already has the profile, the SHA-1 hash of the client profile is compared with that of the server. In case of a mismatch, the VPN Downloader overwrites the client profile with the one on the Secure Gateway. This ensures that the profile on the Secure Gateway is enforced on the client post-authentication.

POST - User Authentication

4. AnyConnect Downloader

The AnyConnect Downloader always initiates a new SSL session, which is why users can encounter a second certificate warning if the certificate of the Secure Gateway is untrusted. During this phase, it performs separate GET operations for each item that needs to be downloaded.

Note: If the client profile is uploaded on Secure Gateway, it is mandatory for download; otherwise, the entire connection attempt is terminated.

VPN Downloader

5. CSTP CONNECT

AnyConnect performs a CONNECT operation as the final step in establishing a secure channel. During the CONNECT operation, the AnyConnect client sends various X-CSTP and X-DTLS attributes for the Secure Gateway in order to process. The Secure Gateway responds with additional X-CSTP and X-DTLS attributes that the client applies to the current connection attempt. This exchange includes the X-CSTP-Post-Auth-XML, accompanied by an XML file, which is largely similar to the one seen in the POST - User Authentication step.

After receiving a successful response, AnyConnect initiates the TLS data channel. Simultaneously the AnyConnect Virtual adapter interface is activated with an MTU value equal to X-DTLS-MTU, assuming that the subsequent DTLS handshake is successful.

CSTP Connect

6. DTLS Handshake

The DTLS handshake proceeds as outlined here. This setup is relatively quick due to the attributes exchanged between the client and server during the CONNECT event.

Client

X-DTLS-Master-Secret: The DTLS Master Secret is generated by the client and shared with the server. This key is crucial for establishing a secure DTLS session.

X-DTLS-CipherSuite: The list of DTLS cipher suites supported by the client, indicating the encryption capabilities of the client.

Server

X-DTLS-Session-ID: The DTLS Session ID assigned by the server for the client to use, ensuring session continuity.

X-DTLS-CipherSuite: The cipher suite selected by the server from the list provided by the client, ensuring both parties use a compatible encryption method.

Note: While the DTLS handshake is in progress, the TLS data channel continues to operate. This ensures that data transmission remains consistent and secure during the handshake process. A seamless transition to the DTLS data encryption channel occurs only after the DTLS handshake is complete.

DTLS Handshake

6.1. DTLS Port Blocked

In the event that the DTLS port is blocked or the Secure Gateway fails to respond to DTLS Client Hello packets, AnyConnect performs an exponential backoff with up to five retries, beginning with a 1-second delay and increasing up to 16 seconds.

If these attempts are unsuccessful, AnyConnect then applies the actual TLS MTU, as specified by the X-CSTP-MTU value returned by the Secure Gateway in Phase 5., to the AnyConnect virtual adapter. Since this MTU differs from the earlier applied MTU (X-DTLS-MTU), a reconfiguration of the virtual adapter is necessary. This reconfiguration appears to the end-user as a reconnect attempt, though no new negotiations occur during this process. Once the virtual adapter is reconfigured, the TLS data channel continues to operate.

DTLS Port Block

Related Information

• Cisco VPN Technologies Documentation Reference

• Cisco Technical Support & Downloads