Decrypting SSL at scale with eBPF, libbpf and K8s

containiq.com

10 points·mlenhard··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?

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.

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?

The application keys definitely do. The handshake keys are modified and at some point become useless to tshark. Not sure if it is a defensive coding thing, or what, but yeah if we don't catch it at the exact right moment they don't work.

Okay, that makes sense. What do you need the handshake keys for, though? Aren't the application keys enough to decrypt all of the data that you need to?

I think it's related to perfect forward secrecy. We used curl's SSLKEYLOGFILE environment variable to find out what tshark needed and then worked to reproduce what curl was producing.

Reply on news.ycombinator.com