Tls handshake schnell sicher: Difference between revisions

From
Jump to navigation Jump to search
No edit summary
No edit summary
Line 18: Line 18:
# Client Change Cipher Spec: Client responds that it also has started encrypted messaging
# Client Change Cipher Spec: Client responds that it also has started encrypted messaging


== Performance considerations ==
Instead of the standard AES-256-algorithm the ChaCha20-algorithm may be used. This algorithm is typically faster than a software implementation of AES-256. However current CPUs have instructions to execute AES in hardware, which can be used by tools like openssl.
Instead of the standard AES-256-algorithm the ChaCha20-algorithm may be used. This algorithm is typically faster than a software implementation of AES-256. However current CPUs have instructions to execute AES in hardware, which can be used by tools like openssl.
A comparison of a openssl-speedtest with and without usage of CPU instructions for AES as well as for ChaCha20 on a Intel Xeon Gold 6150 yields following results:
A comparison of a openssl-speedtest with and without usage of CPU instructions for AES as well as for ChaCha20 on a Intel Xeon Gold 6150 yields the following results, the OPENSSL_ia32cap[https://docs.openssl.org/3.0/man3/OPENSSL_ia32cap/] was used to disable the AES CPU-instructions for testing:


$ OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -aead -evp aes-256-gcm
$ OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -aead -evp aes-256-gcm
Line 28: Line 29:
AES-256-GCM 12352.14k 156771.30k 600536.56k 2364060.33k 3829205.67k 4008596.82k
AES-256-GCM 12352.14k 156771.30k 600536.56k 2364060.33k 3829205.67k 4008596.82k
ChaCha20-Poly1305 5406.06k 79034.59k 256344.41k 1439373.99k 2491817.98k 2634612.74k
ChaCha20-Poly1305 5406.06k 79034.59k 256344.41k 1439373.99k 2491817.98k 2634612.74k

Other factors that may lead to a performance gain in Unixoid operating systems is kernel TLS (kTLS) wherein the TLS-workflow is completely offloaded from the userspace program to kernelspace functions. The kernel used has to support this, it is typically available since kernel version 5.14 and can be queried via
$ lsmod|grep tls
tls 151552 0
Furthermore the application also must have support for kTLS, either built in or by using external libraries such as openssl.
Definite usage by programms is tracked via the following counters, wherein TlsTxSw means 91967 served connections used the kTLS-function, but nothing uses it at the moment of querying.
$ cat /proc/net/tls_stat
TlsCurrTxSw 0
TlsCurrRxSw 0
TlsCurrTxDevice 0
TlsCurrRxDevice 0
TlsTxSw 91967
TlsRxSw 0
TlsTxDevice 0
TlsRxDevice 0
TlsDecryptError 0
TlsRxDeviceResync 0
TlsDecryptRetry 0
TlsRxNoPadViolation 0

Revision as of 07:31, 7 October 2024

Introduction

TLS is a cryptographic protocol used to encrypt data transfer between communication partners. It is located in the application layer of the Internet Protocol Suite (IP Suite) or in the presentation layer of the OSI model. It is typically used as a wrapper for other (insecure) protocols like HTTP or SMTP. Besides encryption TLS could be used for identification purposes of both communication partners. There are several versions of TLS with versions below 1.2 being deprecated. The current versions 1.2 and 1.3 dropped support of unsecure hash functions like MD5 or SHA224. An unconfigured v1.3 connection defaults to the cipher suite AES256_GCM_SHA384.

A typical v1.2 connection without client authentication is done as follows:

  1. Client Hello: Client initiates connection to the Server, transmitting list of supported cipher suites, possibly indicating requiring server certificate status information (OCSP-stapling via flag status_request)
  2. Server Hello: Server replies chosen supported cipher suite
  3. Server-Certificate-Exchange: Server sends its certificate along with certificate chain (also sends valid OCSP-response if OCSP-stapling is configured)
  4. Client-Certificate-Exchange: Client acknowledges validity of certificate
  5. Session-Ticket: Client generates session ticket using on of the following methods:
    - random data created with public key of the server
    - random key via Diffie-Hellmann-Key-Exchange

In v1.3 this was revised to speed up the handshake, it now is as follows:

  1. Client Hello: Client initiates Connection to the Server, sends list of supported cipher suites
  2. Server Hello and Change Cipher Spec:
    - If Server knows and supports one of the cipher suites, Server sends its certificate, certifcate chain, possibly OCSP-response
    - Server signals started encrypted messaging
  3. Client Change Cipher Spec: Client responds that it also has started encrypted messaging

Performance considerations

Instead of the standard AES-256-algorithm the ChaCha20-algorithm may be used. This algorithm is typically faster than a software implementation of AES-256. However current CPUs have instructions to execute AES in hardware, which can be used by tools like openssl. A comparison of a openssl-speedtest with and without usage of CPU instructions for AES as well as for ChaCha20 on a Intel Xeon Gold 6150 yields the following results, the OPENSSL_ia32cap[1] was used to disable the AES CPU-instructions for testing:

$ OPENSSL_ia32cap="~0x200000200000000" openssl speed -elapsed -aead -evp aes-256-gcm
$ openssl speed -elapsed -aead -evp aes-256-gcm
$ openssl speed -elapsed -aead -evp chacha20-poly1305
type              2 bytes     31 bytes    136 bytes   1024 bytes   8192 bytes  16384 bytes
AES-256-GCM       3912.58k    43681.83k   119433.57k   220805.46k   240091.14k   241401.86k
AES-256-GCM      12352.14k   156771.30k   600536.56k  2364060.33k  3829205.67k  4008596.82k
ChaCha20-Poly1305 5406.06k    79034.59k   256344.41k  1439373.99k  2491817.98k  2634612.74k

Other factors that may lead to a performance gain in Unixoid operating systems is kernel TLS (kTLS) wherein the TLS-workflow is completely offloaded from the userspace program to kernelspace functions. The kernel used has to support this, it is typically available since kernel version 5.14 and can be queried via

$ lsmod|grep tls
tls                   151552  0

Furthermore the application also must have support for kTLS, either built in or by using external libraries such as openssl. Definite usage by programms is tracked via the following counters, wherein TlsTxSw means 91967 served connections used the kTLS-function, but nothing uses it at the moment of querying.

$ cat /proc/net/tls_stat
TlsCurrTxSw                             0
TlsCurrRxSw                             0
TlsCurrTxDevice                         0
TlsCurrRxDevice                         0
TlsTxSw                                 91967
TlsRxSw                                 0
TlsTxDevice                             0
TlsRxDevice                             0
TlsDecryptError                         0
TlsRxDeviceResync                       0
TlsDecryptRetry                         0
TlsRxNoPadViolation                     0