TLS sessions

Concept

Applicative level communication in a TCP session may be enciphered using TLS.
TLS is well described in Wikipedia.

Spider is able to capture TLS secrets used to encrypt and decrypt the TLS records in a TCP session.
These secrets are used in parsing services to decipher the encrypted content before parsing the applicative protocol.
This is managed completely behind the scenes, and the TLS session information is not stored in Spider.

Should you want to see, study or debug a TLS session, you may do it in the TCP content tab. As show below.

TLS secrets capture and link

TLS secrets are captured by Gociphers agents and then linked to their related TCP session.
You may find them in the TCP session resource:

• The *Secret, clientRandom, serverRandom, cipher.name and tlsVersion are the values captured from OpenSSL memory.
• The *Key and *Iv are the keys and crypto initialisation vectors derived from the secrets in Spider backend.
• The latter are used to decrypt the TLS records and content

Analysing the TLS session

The TLS session is best described as a diagram (from Wikipedia):

You may study the handshake of the TLS session in TCP content tab of the TCP session:

Spider parses the TLS records to extract the most relevant information allowing to understand and even debug the handshake. Encrypted TLS records are decrypting live and parsed the same way, while keeping the structure of the messages.

An encrypted handshake message may then include any Handshake records inside it:

Application data records are represented with their aggregated deciphered payload below:

You may then apply the TCP content decoder plugins to decode the deciphered data:

• HTTP
• Redis
• MQTT
• ... and any other available plugin

Your TLS communications have no secret for you anymore 😍

Security concerns

Do decrypt TLS sessions, Spider does not hack the session, nor perform brute force.
It extracts TLS secrets from OpenSSL memory using eBPF kernel plugin technology.

To be able to do it, you need to give Spider high level permissions on your Linux hosts.
Make sure that you are allowed to do it!

Technology

Concept

Spider uses eBPF technology to capture OpenSSL secrets.

Spider loads the binary of OpenSSL library used - or of the application that statically linked OpenSSL - to determine OpenSSL version.
Then it attaches eBPF probes to OpenSSL libraries functions to fetch the TLS secrets when they are called.

Spider may capture secrets from applications running on a Host - physical or virtual machine, but it also can capture secrets from applications running in containers, by hooking in their kernel namespaces.
To perform this, the Gociphers Kubernetes daemonset uses wide permissions.
This may raise issues on your security tools, but this is required to use this feature.

Limitations

With current state of development:

• eBPF work on Linux kernel with minimum version of 4.18
• Spider only captures secrets from OpenSSL and from version 1.1.1 to 3.0.
  • It captures secrets from TLS 1.1 to TLS 1.3
• Spider only decrypts TLS session enciphered with TLS 1.2 and TLS 1.3 protocols.
  • The only 'recommended' ones to use.
• As TLS is stateful,
  • Spider must capture the first packets of the session to decrypt TLS.
  • TCP content tab needs to have the first packets in its view to decrypt TLS.
    • Moving the blue cursor on the TCP timeline breaks decrypting feature.
    • Except if you have loaded all parts first.

Also:

• TLS key renewal capture has not been tested (not used anywhere in our systems)
• TLS sessions using session reuse or early data handshake messages have not been tested either.
  • But these features are often disabled in production due to security concerns.

Supported applications languages whose capture is possible

But it can capture secrets from applications being both statically or dynamically linked to OpenSSL library.
This covers a wide range of applications coded with numerous programming languages:

• C, C++
• Java
• Node.js
• PHP
• Python
• .Net framework
• ...

Are not managed:

• Applications coded in Go, which are using Go standard library crypto/tls
• Applications linked to other SSL libraries
  • BoringSSL: A fork of OpenSSL developed by Google, tailored for their internal needs. It is utilized in various Google products and services.
  • LibreSSL: An OpenSSL fork created by the OpenBSD Project, focusing on code simplification and security enhancements.
  • GnuTLS: An open-source TLS library written in C, offering a comprehensive API for secure communications.
  • Network Security Services (NSS): Developed by Mozilla, AOL, Red Hat, Sun, Oracle, Google, and others, NSS is a set of libraries designed to support cross-platform development of security-enabled client and server applications.
  • Mbed TLS: Formerly known as PolarSSL, this library is designed for embedded systems and is developed by Arm.
  • Bouncy Castle: A collection of APIs used in cryptography, including TLS implementations for Java and C#.
  • Rustls: A modern TLS library written in Rust, emphasizing safety and performance.
  • s2n: A TLS implementation developed by Amazon, designed to be small and fast, suitable for use in their cloud services.
  • And other less known SSL libraries

Supported Ciphers

The 5 ciphers of TLS 1.3 are supported, but only 3 are supported by OpenSSL.

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256 (not supported by OpenSSL)
• TLS_AES_128_CCM_8_SHA256 (not supported by OpenSSL)

TLS 1.2 includes hundreds of cipher suites!
Spider only supports the active ones on OpenSSL at the time of writing -openssl ciphers -tls1_2 -stdname -s -V -, which matches Mozilla recommended ciphers.

• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_3DES_EDE_CBC_SHA