[erlang-questions] SSL: Getting master_secret and client_random (or premaster_secret)
Fri Jan 6 00:13:35 CET 2017
Is it a solution to for you to deal with it on the client side?
Chrome lets you write keys out.
From: erlang-questions-bounces@REDACTED <erlang-questions-bounces@REDACTED> on behalf of Roger Lipscombe <roger@REDACTED>
Sent: Friday, 6 January 2017 1:20 AM
Subject: [erlang-questions] SSL: Getting master_secret and client_random (or premaster_secret)
We're using ECDHE and DHE ciphers for our SSL connections. This
provides perfect forward secrecy, which is good, but it makes it
impossible to decipher packet captures in wireshark, which is
expected, and also good, almost all of the time.
Sometimes, however, we *do* need to decipher the traffic.
Note that we own both the client (which is embedded) and the server
(which uses Erlang -- otherwise I wouldn't be asking here -- and
ranch). We *could* offer a different cipher suite on the server, which
would disable PFS, but would do it for all connections. I'd prefer
something a bit more fine-grained.
You can feed a key log to Wireshark, as documented at
NSS Key Log Format - Mozilla | MDN<https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format>
Key logs can be written by NSS so that external programs can decrypt TLS connections. Wireshark 1.6.0 and above can use these log files to decrypt packets.
and it'll correctly decipher the traffic for that connection.
I'd like to find a way to generate a key log file. This requires
either (client_random, master_secret) or (encrypted_premaster_secret,
Note that I'm looking at the OTP 17.5 source, because that's what we're using.
It would seem that premaster_secret is not stored past the initial
negotiation, but the client_random and master_secret values are in the
#security_parameters record in the #connection_state record in the
#connection_states record, which is in the #state record of the SSL
But I can't see any (clean) way to retrieve these values, in order to
generate a key log suitable for Wireshark.
Is there any clean way to do this in OTP 17.5, or is there a supported
way to do this in OTP 18.x or 19.x?
erlang-questions mailing list
erlang-questions Info Page<http://erlang.org/mailman/listinfo/erlang-questions>
Mailing list for general discussions about Erlang/OTP, the language, implementation, usage, beginners questions, etc... To see the collection of prior postings to the ...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions