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

[Ingela Andin]

2017-01-13 21:27 GMT+01:00 Kenneth Lakin <kennethlakin@REDACTED>:

> On 01/13/2017 10:57 AM, Ingela Andin wrote:
> > Yes interop vs security can be a tradeoff. All these needs the user to
> make
> > an active choise.
>
> Notably, that active choice _doesn't_ include forcing the programmer to
> also start the connection in "interop mode". Marking those ssl_options
> with Big Red Dire Warnings was (correctly) deemed quite enough notice. :)
>
> Heck, verify_fun is documented as normal, non-hazardous (that is, it
> lacks a Big Red Warning box) API, but can be misused to (accidentally)
> seriously compromise one's connection security. verify_fun does _not_
> depend on an "enable_hazardous_options" connection flag.
>
>
verify_fun can be abused (maybe we should add a warning)
but it still in a smaller context however .....




> > This to ensure that it is the intent of the connection starter
> > that this behaviour should be allowed.
>
> Given that the caller can bypass this check by pulling the PID out of
> the SSLSocket, calling sys:get_state/1 and extracting the
> security_parameters, this check seems to be more of an annoyance than
> anything else. For instance, how would the author of the (hypothetical)
> TLS connection pool library I'm using know that I _never_ will have a
> legitimate need to extract the client_random from a connection it
> establishes for me?
>
>
>
... maybe I am being to paranoid ;) Well it seem like  a good compromise
would
be that connection_information will only return these values when
explicitly requested
along with a warning in the documentation, as we can not protect against a
malicious
attacker that has access to the node anyway.


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