Kryptografie/VPN

Virtual Private Networks

Virtual Private Networks (VPN) provide means of connecting private networks over external / public transport networks. Since we do not control the transport networks we have to to take care about data integrity and privacy.

Some providers also offer VPNs for connecting company networks via MPLS or simular technologies. The provider promises you that nobody else has access to your data trnfserred over their lines. You have to decide if this promise does fit to your information security requirements.

Basically there are two ways to ensure the privacy and integrity of the data sent via external lines. First you could utilize the built-in security of the Internet Protocol (IPsec). The other way are specific applications that encrypt the data before sending it over the line. IPsec is an Internet standard (TODO RFC 6071). This guarantees the interoperability between implementations of different vendors. You can establish a secure connection with your customer or your supplier. On the other hand VPN applications mostly utilize TLS to secury the communication between the partners. TODO: Descision criteria IPsec vs. VPN application.

IPsec

IPsec is the Internet standard to encrypt the transport of data between private networks.

Technology

We describe only the use the Internet Key Exchange (IKE) version 2 in this dodument. IKEv1 has some usage and security problems and should not be used any more. (TODO: reference).

Authentication

IPsec authentication should optimally be performed via RSA signatures, with a key size of 2048 bits or more. Configuring only the trusted CA that issued the peer certificate provides for additional protection against fake certificates. If you need to use Pre-Shared Key (PSK) authentication:* Choose a random, long enough PSK (see below)

• Use a separate PSK for any IPsec connection
• Change the PSKs regularly
• Think aboute a secure way to exchange the PSK. Sending an SMS it not secure.

The size of the PSK should not be shorter than the output size of the hash algorithm used in IKE.footnote[It is used in a HMAC, see RFC2104  and the discussion starting in TODO: verify http://www.vpnc.org/ietf-ipsec/02.ipsec/msg00268.html.]. For a key composed only of upper- and lowercase letters, numbers, and two additional characters[9], table #tab:IPSEC_psk_len gives the minimum lengths in characters.

Cryptographic Suites:

IPSEC Cryptographic Suites are pre-defined settings for all the items of a configuration; they try to provide a balanced security level and make setting up VPNs easier. [10] When using any of those suites, make sure to enable “Perfect Forward Secrecy“ for Phase 2, as this is not specified in the suites. The equivalents to the recommended ciphers suites in section Recommended cipher suites are shown in table #tab:IPSEC_suites.

Phase 1:

TODO: Phase 1 and 2 are phrases from IKEv1. Re-write for IKEv2. Alternatively to the pre-defined cipher suites, you can define your own, as described in this and the next section. Phase 1 is the mutual authentication and key exchange phase; table #tab:IPSEC_ph1_params shows the parameters. Use only “main mode“, as “aggressive mode“ has known security vulnerabilities [11].

Phase 2:

Phase 2 is where the parameters that protect the actual data are negotiated; recommended parameters are shown in table #tab:IPSEC_ph2_params.

References

• Fergusen, N. and Schneier, B.: A Cryptographic Evaluation of IPsec: https://www.schneier.com/paper-ipsec.pdf

Check Point Next Generation Firewall

Tested with Versions

Table 9. Tested CheckPoint Versions

Program Version	OS/Distribution/Version	Comment
R77	Secure Platform

Settings

Please see section IPsec for guidance on parameter choice. In this section, we will configure a strong setup according to Configuration A. This is based on the concept of a VPN Community, which has all the settings for the gateways that are included in that community. Communities can be found in the IPSEC VPN tab of SmartDashboard. "VPN Community encryption properties" [fig:checkpoint_1] Either choose one of the encryption suites in the properties dialog (figure [checkpoint_1], or proceed to Custom Encryption..., where you can set encryption and hash for Phase 1 and 2 (figure [checkpoint_2]. "Custom Encryption Suite Properties" [checkpoint_2] The Diffie-Hellman groups and Perfect Forward Secrecy Settings can be found under Advanced Settings / Advanced VPN Properties (figure [checkpoint_3]. "Advanced VPN Properties" [checkpoint_3]

Additional settings

For remote Dynamic IP Gateways, the settings are not taken from the community, but set in the Global Properties dialog under Remote Access / VPN Authentication and Encryption. Via the Edit... button, you can configure sets of algorithms that all gateways support (figure [checkpoint_4]). "Remote Access Encryption Properties" [checkpoint_4] Please note that these settings restrict the available algorithms for all gateways, and also influence the VPN client connections.

References

• Check Point VPN R77 Administration Guide (may require a UserCenter account to access)

TLS Based Applications

Tested with Versions

Table 10. Tested OpenVPN Versions

Program Version	OS/Distribution/Version	Comment
2.3.10	Ubuntu Xenial 16.04.1 LTS	linked against openssl (libssl.so.1.0.0)
2.3.2	Debian Wheezy (backports)	linked against openssl (libssl.so.1.0.0)
2.2.1	Debian Wheezy	linked against openssl (libssl.so.1.0.0)
2.3.2	Windows

Settings

General

We describe a configuration with certificate-based authentication; see below for details on the easyrsa tool to help you with that. OpenVPN uses TLS only for authentication and key exchange. The bulk traffic is then encrypted and authenticated with the OpenVPN protocol using those keys. Note that while the tls-cipher option takes a list of ciphers that is then negotiated as usual with TLS, the cipher and auth options both take a single argument that must match on client and server. OpenVPN duplexes the tunnel into a data and a control channel. The control channel is a usual TLS connection, the data channel currently uses encrypt-then-mac CBC, see https://github.com/BetterCrypto/Applied-Crypto-Hardening/pull/91#issuecomment-75365286

Client Configuration

Client and server have to use compatible configurations, otherwise they can’t communicate. The cipher and auth directives have to be identical.

Justification for special settings

OpenVPN 2.3.1 changed the values that the tls-cipher option expects from OpenSSL to IANA cipher names. That means from that version on you will get Deprecated TLS cipher name warnings for the configurations above. You cannot use the selection strings from section Recommended cipher suites directly from 2.3.1 on, which is why we give an explicit cipher list here. In addition, there is a 256 character limit on configuration file line lengths; that limits the size of cipher suites, so we dropped all ECDHE suites. The configuration shown above is compatible with all tested versions.

References

• OpenVPN Documentation: Security Overview https://openvpn.net/index.php/open-source/documentation/security-overview.html

Additional settings

Key renegotiation interval

The default for renegotiation of encryption keys is one hour (reneg-sec 3600). If you transfer huge amounts of data over your tunnel, you might consider configuring a shorter interval, or switch to a byte- or packet-based interval (reneg-bytes or reneg-pkts).

Insecure ciphers

Sweet32[12] is an attack on 64-bit block ciphers, such as 3DES and Blowfish in OpenVPN. The following ciphers are affected, and should no longer be used:* BF-*

• DES* (including 3DES variants)
• RC2-*

The following ciphers are not affected:* AES-*

• CAMELLIA-*
• SEED-*

According to mitigation section on Sweet32 website[13] users users should change the cipher from the DES or Blowfish to AES (cipher AES-128-CBC). If cipher change is not possible users can mitigate the attack by forcing frequent rekeying (reneg-bytes 64000000).

Fixing “easy-rsa”

When installing an OpenVPN server instance, you are probably using easy-rsa to generate keys and certificates. The file vars in the easyrsa installation directory has a number of settings that should be changed to secure values: This will enhance the security of the key generation by using RSA keys with a length of 4096 bits, and set a lifetime of one year for the server/client certificates and five years for the CA certificate.

4096 bits is only an example of how to do this with easy-rsa. See also section Keylengths for a discussion on keylengths.

In addition, edit the pkitool script and replace all occurrences of sha1 with sha256, to sign the certificates with SHA256.

Limitations

Note that the ciphersuites shown by openvpn --show-tls are known, but not necessarily supported [14]. Which cipher suite is actually used can be seen in the logs: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-CAMELLIA256-SHA, 2048 bit RSA

PPTP

PPTP is considered insecure, Microsoft recommends to _use a more secure VPN tunnel_[15]. There is a cloud service that cracks the underlying MS-CHAPv2 authentication protocol for the price of USD 200[16], and given the resulting MD4 hash, all PPTP traffic for a user can be decrypted.

Cisco ASA

The following settings reflect our recommendations as best as possible on the Cisco ASA platform. These are - of course - just settings regarding SSL/TLS (i.e. Cisco AnyConnect) and IPsec. For further security settings regarding this platform the appropriate Cisco guides should be followed.

Tested with Versions

Table 11. Tested Cisco ASA Versions

Program Version	OS/Distribution/Version	Comment
9.1(3)	X-series model

Settings

crypto ipsec ikev2 ipsec-proposal AES-Fallback

protocol esp encryption aes-256 aes-192 aes
protocol esp integrity sha-512 sha-384 sha-256

crypto ipsec ikev2 ipsec-proposal AES-GCM-Fallback

protocol esp encryption aes-gcm-256 aes-gcm-192 aes-gcm
protocol esp integrity sha-512 sha-384 sha-256

crypto ipsec ikev2 ipsec-proposal AES128-GCM

protocol esp encryption aes-gcm
protocol esp integrity sha-512

crypto ipsec ikev2 ipsec-proposal AES192-GCM

protocol esp encryption aes-gcm-192
protocol esp integrity sha-512

crypto ipsec ikev2 ipsec-proposal AES256-GCM

protocol esp encryption aes-gcm-256
protocol esp integrity sha-512

crypto ipsec ikev2 ipsec-proposal AES

protocol esp encryption aes
protocol esp integrity sha-1 md5

crypto ipsec ikev2 ipsec-proposal AES192

protocol esp encryption aes-192
protocol esp integrity sha-1 md5

crypto ipsec ikev2 ipsec-proposal AES256

protocol esp encryption aes-256
protocol esp integrity sha-1 md5

crypto ipsec ikev2 sa-strength-enforcement crypto ipsec security-association pmtu-aging infinite crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group14 crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set ikev2 ipsec-proposal AES256-GCM AES192-GCM AES128-GCM AES-GCM-Fallback AES-Fallback crypto map Outside-DMZ_map 65535 ipsec-isakmp dynamic SYSTEM_DEFAULT_CRYPTO_MAP crypto map Outside-DMZ_map interface Outside-DMZ crypto ikev2 policy 1

encryption aes-gcm-256
integrity null
group 14
prf sha512 sha384 sha256 sha
lifetime seconds 86400

crypto ikev2 policy 2

encryption aes-gcm-256 aes-gcm-192 aes-gcm
integrity null
group 14
prf sha512 sha384 sha256 sha
lifetime seconds 86400

crypto ikev2 policy 3

encryption aes-256 aes-192 aes
integrity sha512 sha384 sha256
group 14
prf sha512 sha384 sha256 sha
lifetime seconds 86400

crypto ikev2 policy 4

encryption aes-256 aes-192 aes
integrity sha512 sha384 sha256 sha
group 14
prf sha512 sha384 sha256 sha
lifetime seconds 86400

crypto ikev2 enable Outside-DMZ client-services port 443 crypto ikev2 remote-access trustpoint ASDM_TrustPoint0 ssl server-version tlsv1-only ssl client-version tlsv1-only ssl encryption dhe-aes256-sha1 dhe-aes128-sha1 aes256-sha1 aes128-sha1 ssl trust-point ASDM_TrustPoint0 Outside-DMZ

Justification for special settings

New IPsec policies have been defined which do not make use of ciphers that may be cause for concern. Policies have a "Fallback" option to support legacy devices. 3DES has been completely disabled as such Windows XP AnyConnect Clients will no longer be able to connect. The Cisco ASA platform does not currently support RSA Keys above 2048bits. Legacy ASA models (e.g. 5505, 5510, 5520, 5540, 5550) do not offer the possibility to configure for SHA256/SHA384/SHA512 nor AES-GCM for IKEv2 proposals.

References

• http://www.cisco.com/en/US/docs/security/asa/roadmap/asaroadmap.html
• http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html

Openswan

Tested with Version

Table 12. Tested OpenS/WAN Versions

Program Version	OS/Distribution/Version	Comment
2.6.39	Gentoo

Settings

The available algorithms depend on your kernel configuration (when using protostack=netkey) and/or build-time options.

To list the supported algorithms $ ipsec auto --status | less and look for ’algorithm ESP/IKE’ at the beginning. aggrmode=no

# ike format: cipher-hash;dhgroup
# recommended ciphers:
# - aes
# recommended hashes:
# - sha2_256 with at least 43 byte PSK
# - sha2_512 with at least 86 byte PSK
# recommended dhgroups:
# - modp2048 = DH14
# - modp3072 = DH15
# - modp4096 = DH16
# - modp6144 = DH17
# - modp8192 = DH18

ike=aes-sha2_256;modp2048 type=tunnel phase2=esp

# esp format: cipher-hash;dhgroup
# recommended ciphers configuration A:
# - aes_gcm_c-256 = AES_GCM_16
# - aes_ctr-256
# - aes_ccm_c-256 = AES_CCM_16
# - aes-256
# additional ciphers configuration B:
# - camellia-256
# - aes-128
# - camellia-128
# recommended hashes configuration A:
# - sha2-256
# - sha2-384
# - sha2-512
# - null (only with GCM/CCM ciphers)
# additional hashes configuration B:
# - sha1
# recommended dhgroups: same as above

phase2alg=aes_gcm_c-256-sha2_256;modp2048 salifetime=8h pfs=yes auto=ignore

How to test

Start the vpn and using $ ipsec auto --status | less and look for ’IKE algorithms wanted/found’ and ’ESP algorithms wanted/loaded’.

References

• https://www.openswan.org/

tinc

Tested with Versions

Table 13. Tested tinc Versions

Program Version	OS/Distribution/Version	Comment
1.0.23	Gentoo	linked against OpenSSL 1.0.1e
1.0.23	Sabayon	linked against OpenSSL 1.0.1e

Defaults

tinc uses 2048 bit RSA keys, Blowfish-CBC, and SHA1 as default settings and suggests the usage of CBC mode ciphers. Any key length up to 8192 is supported and it does not need to be a power of two. OpenSSL Ciphers and Digests are supported by tinc.

Settings

Generate keys with $ tincd -n NETNAME -K8192 Old keys will not be deleted (but disabled), you have to delete them manually. Add the following lines to your tinc.conf on all machines

References

• tincd(8) man page
• tinc.conf(5) man page
• tinc mailinglist http://www.tinc-vpn.org/pipermail/tinc/2014-January/003538.html