Skip to content

Latest commit

 

History

History
70 lines (41 loc) · 5.79 KB

cm9cc37s7002309l5hwd89bd9.md

File metadata and controls

70 lines (41 loc) · 5.79 KB
title seoTitle datePublished cuid slug cover tags
Key Extraction by uprobe Attachment on OpenSSL for SSL Inspection
Key Extraction by uprobe Attachment on OpenSSL for SSL Inspection
Fri Apr 11 2025 05:15:50 GMT+0000 (Coordinated Universal Time)
cm9cc37s7002309l5hwd89bd9
key-extraction-by-uprobe-attachment-on-openssl-for-ssl-inspection
tls, networking, openssl, ebpf

gMan-in-the-middle attacks are elegantly mitigated in TLS, with TLS1.3 introducing more robust encryption protocols and a streamlined handshake process that significantly reduces the vulnerability to these types of attacks. By employing stricter encryption standards and eliminating outdated cipher suites, TLS 1.3 enhances security measures to effectively counter potential interception and unauthorised data decryption. This upgrade to the TLS protocol ensures a higher level of confidentiality and integrity of data in transit, making it more challenging for attackers to exploit communication channels.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1706176126187/8363e881-6a65-4b4f-885b-cf9e2729dd8b.png align="center")

SSL (Secure Sockets Layer) inspection, also known as TLS (Transport Layer Security) inspection, plays a critical role in network security. It involves the interception and decryption of encrypted traffic to allow for deep packet inspection (DPI). By examining the contents of encrypted SSL/TLS traffic, organisations can identify and mitigate potential security threats like malware, data ex-filtration, and unauthorised access that might otherwise remain hidden.

SSL Inspection can be done in multiple ways,

To extract the keys using uprobe on SSL_write (or SSL_read), the first argument to these functions must be read using bpf_probe_read_user helper function. The first argument is the SSL context, an internal struct in OpenSSL. The memory offsets of the members of this struct can be defined as macros for easy access to all of its members, since OpenSSL cannot be included in the eBPF program.

// ssl_st->version
#define SSL_ST_VERSION 0x0   

// Reading ssl_st_ptr
void *ssl_st_ptr = (void *)PT_REGS_PARM1_CORE(ctx);
__u64 *ssl_version_ptr = (__u64 *)(ssl_st_ptr + SSL_ST_VERSION);
int ret = bpf_probe_read_user(&version, sizeof(version), (void *)ssl_version_ptr);

This is how the version member of the SSL context struct is extracted. The cipher_id, client_random, handshake_secret, handshake_traffic_hash, client_app_traffic_secret, server_app_traffic_secret and exporter_master_secret can be extracted in the same way.

Once the secrets have been extracted, they are to be dumped into a perf buffer to be read from userspace. This is supposed to happen in the proxy as the proxy needs the keys to decrypt the packets. It is also important to keep in mind that the proxy must not initiate another TLS connection with the client and the server, as the proxy's certificates must not be used in this case. The encrypted packets from the client are decrypted and stored in the proxy, with the encrypted data being written into the TCP connection with the server.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1706174995302/f620a3ca-c13f-499d-a39f-fd040bd41a3a.png align="center")

  1. Client Application

    The client application sends out application data which needs to be encrypted before being sent over the network. It uses OpenSSL's SSL_write function, which takes application data and the SSL context (which contains encryption keys and other TLS session details) to produce encrypted data.

  2. Uprobe to Extract Keys from SSL Context

    A User Space Probe (uprobe) is attached to the OpenSSL SSL_write function. When SSL_write is called, the uprobe intercepts the call to extract master key information from the SSL context, which will be used for decrypting the data.

  3. Perf Buffer

    The extracted master key secrets are stored in a performance buffer (perf buffer), which is a type of data structure used to temporarily hold data for high-speed data transfer.

  4. Proxy

    The encrypted data from the client's TCP socket is sent to the proxy. The proxy has a TCP socket set up to receive this encrypted data (encrypted packet). The proxy then uses the master key secrets from the perf buffer to decrypt the packet. After decryption, the data is sent through another TCP socket to the intended server. The proxy acts as a passive entity that forwards encrypted data between the client and server.

  5. Server:

    The server has a TCP socket listening for incoming connections. Once the decrypted data reaches the server's TCP socket, it is passed to the TLS server, which processes the data as if it came directly from the client over a secure TLS connection.

  6. Data Store

    The proxy may use a data store to keep a record of the decrypted traffic for inspection, logging, or analysis purposes.

The proxy simply forwarding the handshake packets from the clients to the server is the approach to take if the proxy's certificate is not trusted by the client. In this approach, the proxy's certificate need not be used at all, it does not need to be set up as a TLS server, it only needs to be set up as a TCP server.