Background
Dispel connections are always end-to-end encrypted. Due to the flexible nature of Dispel's platform, additional encrypted tunnels can be established from the Wicket to downstream resources.
This article will cover the ways in which those tunnels are established and provide a starting point for configuration changes/minimum thresholds a customer may request for their deployment. Most frequently, we've seen customers request that a Wicket to MTD-Network tunnel run through an HTTP-Proxy rather than a standard request.
Note
As part of our SaaS services, Dispel supports, monitors, orchestrates, updates, patches, and maintains all encrypted tunnels, from each Virtual Desktop, all the way down to each Wicket at each customer location. Changes to any baseline configurations must be discussed with your Dispel representative and agreed in writing before a change can take place.
What is encryption, and how does it work in Dispel?
In a Dispel deployment, data is transformed from its original form (plaintext) into a secure format known as ciphertext through the process of encryption. Ciphertext is unreadable without proper decryption, which requires a specific encryption key available only to authorized individuals. This ensures that sensitive information such as files, virtual desktop connections, and other communications remains confidential and accessible solely by intended recipients.
Encryption alone does not safeguard against the interception of data. It is a critical component of a broader security strategy designed to protect organizational information. Utilizing encryption helps guarantee that encrypted data can only be interpreted and used by authorized parties.
Dispel allows for the implementation of multiple encryption layers simultaneously. For instance, not only can passwords be encrypted, but also the channels over which these passwords are transmitted. In the context of Dispel, your data benefits from robust encryption both at rest and in transit, employing a variety of strong encryption protocols and technologies. These include Transport Layer Security/Secure Sockets Layer (TLS/SSL), Internet Protocol Security (IPSec), and Advanced Encryption Standard (AES), among others, to ensure comprehensive data protection.
This article covers the tunnel component of our encryption strategy, and how they are implemented within a Dispel deployment.
Supported Protocols
Dispel supports the following encrypted tunnel protocols in our deployments:
Application Layer |
IKEv2 IPSec StrongSwan |
OpenVPN |
Network Architecture
This diagram provides an overview of the connection architecture + tunnel options:
OpenVPN Implementation
Within our platform OpenVPN tunnels are configured with the following options. Please note this is a subset of available options, but cover the high level decision a customer will potentially need to reconfigure. Descriptions are pulled from: https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4
Key Variables
OpenVPN, v2.4.7 (v2.3.4+ supported)
Protocols: TCP or UDP
Cipher: AES-256, CBC or GCM
Auth: SHA512
Port: [variable]
HTTP-Proxy: [available, customer config]
TLS min version: 1.0, 1.2 (default), 1.3
customer configurable + enforceable
NAT: available, source & destination
RSA key sizes: 2048, 4096+
DHCP + Route pushing: available
DNS pushing: available
Descriptions of the options provided below
Protocols
--proto p
Use protocol p for communicating with remote host. p can be udp, tcp-client, or tcp-server.The default protocol is udp when --proto is not specified.
For UDP operation, --proto udp should be specified on both peers.
For TCP operation, one peer must use --proto tcp-server and the other must use --proto tcp-client. A peer started with tcp-server will wait indefinitely for an incoming connection. A peer started with tcp-client will attempt to connect, and if that fails, will sleep for 5 seconds (adjustable via the --connect-retry option) and try again infinite or up to N retries (adjustable via the --connect-retry-max option). Both TCP client and server will simulate a SIGUSR1 restart signal if either side resets the connection.
OpenVPN is designed to operate optimally over UDP, but TCP capability is provided for situations where UDP cannot be used. In comparison with UDP, TCP will usually be somewhat less efficient and less robust when used over unreliable or congested networks.
Web Proxy Support
--http-proxy-option type [parm]
Set extended HTTP proxy options. Repeat to set multiple options.VERSION version -- Set HTTP version number to version (default=1.0).
Port Selection
--port port
TCP/UDP port number or port name for both local and remote (sets both --lport and --rport options to given port). The current default of 1194 represents the official IANA port number assignment for OpenVPN and has been used since version 2.0-beta17. Previous versions used port 5000 as the default.
Customers may choose non-standard ports for their deployments.
Push Routing
--route network/IP [netmask] [gateway] [metric]
Add route to routing table after connection is established. Multiple routes can be specified. Routes will be automatically torn down in reverse order prior to TUN/TAP device close.This option is intended as a convenience proxy for the route shell command, while at the same time providing portable semantics across OpenVPN's platform space.
netmask default -- 255.255.255.255
gateway default -- taken from --route-gateway or the second parameter to --ifconfig when --dev tun is specified.
metric default -- taken from --route-metric otherwise 0.
The default can be specified by leaving an option blank or setting it to "default".
The network and gateway parameters can also be specified as a DNS or /etc/hosts file resolvable name, or as one of three special keywords:
Auth Algorithm
--auth alg
Authenticate data channel packets and (if enabled) tls-auth control channel packets with HMAC using message digest algorithm alg. (The default is SHA512 ). HMAC is a commonly used message authentication algorithm (MAC) that uses a data string, a secure hash algorithm, and a key, to produce a digital signature.The OpenVPN data channel protocol uses encrypt-then-mac (i.e. first encrypt a packet, then HMAC the resulting ciphertext), which prevents padding oracle attacks.
If an AEAD cipher mode (e.g. GCM) is chosen, the specified --auth algorithm is ignored for the data channel, and the authentication method of the AEAD cipher is used instead. Note that alg still specifies the digest used for tls-auth.
In static-key encryption mode, the HMAC key is included in the key file generated by --genkey. In TLS mode, the HMAC key is dynamically generated and shared between peers via the TLS control channel. If OpenVPN receives a packet with a bad HMAC it will drop the packet. HMAC usually adds 16 or 20 bytes per packet. Set alg=none to disable authentication.
Dispel uses SHA512 by default.
Cipher Algorithms
Dispel defaults are AES-256-CBC or GCM
AES-256 in either CBC (Cipher Block Chaining) or GCM (Galois/Counter Mode) mode is considered secure and meets stringent security requirements. They are the same level of security, but more recent OpenVPN versions use the faster AES-GCM method to combine the encryption and authentication steps. SHA512 HMAC is used for the packet authentication when CBC mode is used.
Encrypt data channel packets with cipher algorithm alg. The default is AES-256-CBC.
Recommended values:
AES-256-GCM
AES-128-GCM
CHACHA20-POLY1305
Optional values:
AES-256-CBC
AES-192-CBC
AES-128-CBC
Deprecated values:
BF-CBC
DES-CBC
DES-EDE3-CBC
DESX-CBC
none (i.e. there is no option for no encryption)
TLS Version
--tls-version-min version ['or-highest']
Sets the minimum TLS version we will accept from the peer (default is "1.0"). Examples for version include "1.0", "1.1", or "1.2". If 'or-highest' is specified and version is not recognized, we will only accept the highest TLS version supported by the local SSL implementation.
IKEv2 IPSec Implementation (StrongSwan)
IKEv2 IPSec support was released for Dispel in H2 2023. Customers now have the option to enforce IPSec for tunnel creation and can leverage IPSec when connecting downstream resources to Wickets. Dispel's implementation leverages both IPv4 and IPv6 routing and connection schemas to perform connections.
Variable descriptions are pulled from StrongSwan documentation and edited for Dispel's context where applicable. StrongSwan docs are found here: https://docs.strongswan.org/docs/5.9/config/IKEv2CipherSuites.html
Key Variables
IKEv2 IPSec
Application layer: StrongSwan
Protocols: UDP(17), Optionally ESP(50)
Ports: (default) 500 & 4500, others configurable.
Cipher: aes256gcm16-prfsha512-ecp384
256 bit AES-GCM with 128 bit ICV
SHA2_256 PRF (pseudorandom function)
NIST elliptic curve group: 384 bits
Secrets: PKCS12
RSA Key size: 4096+
NAT: Compatible, both source & destination
StrongSwan
StrongSwan is basically a keying daemon that uses the Internet Key Exchange Version 2 (IKEv2) protocol to establish Security Associations (SAs) and negotiate Security Policies (SPs) between two peers.
IKE provides strong authentication of both peers and derives unique cryptographically-strong session keys. Such an IKE session is often denoted IKE_SA in StrongSwan documentation. Besides authentication and key material IKE also provides the means to exchange configuration information (e.g. virtual IP addresses) and to negotiate IPsec SAs, which are often called CHILD_SAs. IPsec SAs define which network traffic is to be secured and how it has to be encrypted and authenticated.
A CHILD_SA consists of two components:
The actual IPsec SAs (two of them are established, one in each direction) describing the algorithms and keys used to encrypt and authenticate the traffic.
The policies (there are at least two) that define which network traffic shall use that SA.
The policies work both ways, i.e. only traffic matching an inbound policy will be allowed after decryption. Policies are derived from the traffic selectors (TS) negotiated via IKE when establishing a CHILD_SA. Unprotected traffic that the kernel receives and for which there is no matching inbound IPsec policy will be dropped. This is a security feature.
The actual IPsec traffic is not handled by strongSwan but will be relegated to the network and IPsec stack of the operating system kernel - For Dispel, this is Ubuntu 22.04 LTS or a customer supplied operating system. strongSwan installs the negotiated IPsec SAs and SPs into the kernel by using a platform-dependent kernel interface.
Cipher
Dispel uses aes256gcm16-prfsha512-ecp384 as the encryption cipher for IPSec connections. This is a concatenation of different cipher options:
aes256gcm16 refers to AES 256 in GCM mode with a 128 bit integrity check value (ICV)
prfsha512 refers to a SHA512 pseudo random function used for integrity verification purposes.
ecp384 refers to the use of a NIST Elliptic Curve Group with 384 bits for Diffie Hellman
RSA Key Size
As with OpenVPN Dispel uses larger key sizes to increase security. Given the newer release of IPSec within Dispel's architecture a default key size of 4096 is used. Customers can work with Dispel on downstream endpoints if a smaller key size is required.
NAT + Push Routing & DNS
As in OpenVPN, options exist for customers to configure pushed routes within an IPSec tunnel framework. This is used for routing customer traffic and dynamic route allocation within the moving target defense network. For reconfiguration constructs, visit:
example:
ip link set ipsec0 up
ip route add 10.1.0.0/16 dev ipsec0
ip route add 10.2.0.0/16 dev ipsec0
Local NAT rules are applied at the OS routing layer between traffic nodes where applicable. IPSec can be configured to survive NAT Traversal: https://docs.strongswan.org/docs/5.9/features/natTraversal.html
The IKEv2 protocol includes NAT Traversal (NAT-T) in the core standard but it is optional. The strongSwan charon daemon implements NAT-Traversal without any special prior configuration but the mechanism cannot be disabled, either.
TLS Considerations
The strongSwan libtls library offers a full Transport Layer Security (TLS) stack implementing TLS version 1.3 and TLS version 1.2.
Legacy TLS version 1.1 and TLS version 1.0 are technically supported by strongSwan, but these should not be used because they are no longer secure.
Conclusion
In general, a customer will never interact with the tunnel connections between Dispel nodes as those are securely orchestrated by Dispel's engine. Support, patch, and update responsibility for these tunnels (excluding on-prem Wicket to endpoint tunnels) are provided by Dispel within the scope of all contracts and availability thresholds are covered in our service level agreements with customers.
This deep-dive into Dispel's tunnel and encryption architectures is instead meant to give customers a starting point for Wicket to Endpoint connections within their internal networks and to demonstrate the strong security standards present in each of Dispel's tunnels.