[erlang-questions] SSL: Getting master_secret and client_random (or premaster_secret)

[Ingela Andin]

Hi!

2017-01-13 19:16 GMT+01:00 Kenneth Lakin <kennethlakin@REDACTED>:

> On 01/13/2017 01:39 AM, Ingela Andin wrote:
> > When it comes to security you should be very careful...
>
> Agreed.
>
> > 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
be allowed.



> > 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
security.



> > 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
an
active choise.

Regards Ingela Erlang/OTP team - Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170113/b049f9f8/attachment.htm>