Decrypting SSL at scale with eBPF, libbpf and K8s

Decrypting SSL at scale with eBPF, libbpf and K8s(containiq.com)

10 points by mlenhard 3 years ago | 6 comments

> OpenSSL goes to great lengths to make them unreadable once the handshake is finished. Even if you have access to a program’s memory once they are derived, they are useless to Wireshark.

Wait, how can this be? Doesn't OpenSSL need to encrypt and decrypt all of the data that goes across the connection, for the connection's entire lifetime?

fl_ciq 3 years ago | |

Author here.

This is in process, we are using eBPF to read the keys out of memory in process and then write them into a pcapng file that tshark can use.

The handshake is only partially encrypted, the public keys and client random can be traced from the network, but the private keys need to be read from memory.

Some of the keys necessary to decrypt the stream are only found in memory for a limited time after which they are overwritten, if the keys are not retrieved in this time window the connection cannot be decrypted by tshark.

josephcsible 3 years ago | | |

But don't the keys to decrypt the stream have to remain in memory for at least as long as the stream itself is active? Or is the issue that the connection completes too quickly, so that that doesn't give you enough time?