Cipher Exchange Between the GlobalProtect App and Gateway
Focus
Focus
GlobalProtect

Cipher Exchange Between the GlobalProtect App and Gateway

Table of Contents

Cipher Exchange Between the GlobalProtect App and Gateway

The following figure displays the exchange of ciphers between GlobalProtect gateways and GlobalProtect apps when creating the VPN tunnel.
Cipher Exchange Between the App and the Gateway
The following table describes these stages in more detail.
Cipher Exchange Between the App and Gateway
Communication Stage
Description
1. Client Hello
The app proposes a list of cipher suites depending on the OS of the endpoint.
2. Server Hello
The gateway selects the cipher suite proposed by the app. When selecting the ciphers to set up the tunnel, the gateway ignores both the number and order of cipher suites proposed by the app and instead relies on the SSL/TLS versions and algorithm of the gateway server certificate and its preferred list (as described in About GlobalProtect Cipher Selection).
3. Optional Client Certificate
The gateway can optionally request a client certificate from the app to use to trust the identity of the user or endpoint.
4. SSL Session
After setting up the SSL/TLS session, the app authenticates with the gateway and requests the gateway configuration (Get-Config-Request). To request the configuration, the app proposes the encryption and authentication algorithms and other settings such as preferred IP address for the tunnel interface. The gateway responds to the request and selects the encryption and authentication algorithm to use based on the configuration of the GlobalProtect IPSec Crypto Profile (Get-Config-Response).
The following table displays an example of the cipher exchange between an app on a macOS endpoint and the gateway.
Example: Cipher Exchange for macOS Endpoints
Communication Stage
Example: macOS Endpoints
1. Client Hello
2. Server Hello
  • When GlobalProtect uses an ECDSA certificate and TLS 1.2 is accepted, the SSL session uses ECDSA-AES256-CBC-SHA.
  • When GlobalProtect uses an RSA certificate and TLS 1.2 is accepted, the SSL session uses RSA-AES256-CBC-SHA256.
3. Optional Client Certificate
Client certificates signed with ECDSA or RSA and using SHA1, SHA256, or SHA384
4. SSL Session
  • SSL Session uses ECDSA-AES256-CBC-SHA or RSA-AES256-CBC-SHA256
  • Get-Config-Request
    • Encryption—AES-256-GCM, AES-128-GCM, AES-128-CBC
    • Authentication—SHA1 and OS type, Preferred IP address etc
  • Get-Config-Response
    • Client to server, and server to client SPIs, encryption keys, and authentication keys
    • Tunnel type, ports, split tunnel mode, IP, and DNS etc

Recommended For You