[erlang-questions] SSL: Getting master_secret and client_random (or premaster_secret)
Fri Jan 13 19:57:15 CET 2017
2017-01-13 19:16 GMT+01:00 Kenneth Lakin <>:
> On 01/13/2017 01:39 AM, Ingela Andin wrote:
> > When it comes to security you should be very careful...
> > However we would not want connection_information to return these values
> > by default.
> That's sensible. master_secret, server_random, and client_random should
> be documented options (with a "THIS INFORMATION IS SECURITY SENSITIVE!
> BE CAREFUL!" warning attached to them) for ssl:connection_information/2.
> However, what does it mean to start a connection in "debug mode"? The
> string "debug" neither appears in the ssl module documentation, nor in
> its source code (OTP 19.2). Isn't limiting access to those parameters to
> an explicit request (via ssl:connection_information/2) a sufficiently
> high barrier? Why require one to start a connection in a special mode in
> addition to making the explicit request for the parameters?
"debug mode" would be a new option (maybe called something else) that
when set connection_information would be allowed to return
master_secret, server_random, and client_random. This to ensure
that it is the intent of the connection starter that this behaviour should
> > What if someone thinks its a good idea to decrypt the data
> > outside the TLS connection in the server and send it to an
> > external logging server in the clear!
> The server already has the plaintext that was transferred through the
> TLS tunnel. TLS doesn't protect you from your peer, it protects you from
> someone in the middle. :)
Well yes the peer can choose to handle the plain-text uncarfully and TLS
can do nothing about it.
I think there is a reason for the joke (a)lawful interception ;)
The point here is that if it seems to standard (normal API) people might
use it out of convinance for
testing/debuging or not understanding better and end up compromising
> > What if someone decides to transfer the logs in an insecure way from
> > the server!
> Sure, but "malicious or poorly-thought-out TLS peers (or system
> operators)" are -AFAICT- outside the scope of the protection that TLS
> provides. Given that both OpenSSL and BoringSSL provide functions to
> extract client/server random and master secret, it seems that there is a
> legitimate (if niche) reason for exposing this information to clients.
> I mean, the Erlang ssl module allows you to turn off BEAST mitigation
> and the block cypher padding check. These options are arguably more
> dangerous than what's being discussed (as they weaken TLS's MITM
> protections (leaving you open to POODLE and BEAST)) but they are _very_
> useful in certain niche situations.
Yes interop vs security can be a tradeoff. All these needs the user to make
Regards Ingela Erlang/OTP team - Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions