# Revision history [back]

While the key log file is non-empty, some keys are still missing.

To cross-reference the keys from the key log file, note that the Key Log File uses the following format for TLS 1.2 secrets:

CLIENT_RANDOM <ClientRandom> <MasterSecret>


This <ClientRandom> is matched against the Random field in the Client Hello message. This command lists the frame number, the Random field and the Server Name for Client Hello messages:

tshark -Y "ssl.handshake.random and ssl.handshake.type==1" -Tfields -e frame.number -e ssl.handshake.random -e ssl.handshake.extensions_server_name -r ssl-decryption-pluralsight.pcapng


We can find a couple of entries, for example:

109     a6268092b93dae607b43fc33d77ef0c44075f24607349f5e12b28ea7fd9d1c4d        mtalk.google.com

Of all entries, only a few appear to have a match against the key log file (109, 115, 172, 1641, 1960). All others have no match. Let's investigate packet 1018. Its Client Hello looks very unusual, it has a Heartbeat extension and advertises a plethora of cipher suites (53 in total, including uncommon ones such as fixed-DH with DSA (TLS_DH_DSS_WITH_AES_256_GCM_SHA384) and TLS_RSA_WITH_CAMELLIA_256_CBC_SHA). This looks like a client (using OpenSSL?) that has everything enabled by default.
Compare that against frame 109 which advertises only 17 cipher suites, includes GREASE and supported_versions (to advertise TLS 1.3 support). This looks more like a modern browser (Chrome).
My guess is that you have some kind of "antivirus software" installed that intercepts traffic from Chrome and then performs its own external connection. The SSLKEYLOGFILE environment variable likely has no effect on this other piece of software as it requires support from the application (such as Firefox or Chrome).