[erlang-questions] SSL: Getting master_secret and client_random (or premaster_secret)
Mon Jan 16 12:06:24 CET 2017
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
> > 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
be that connection_information will only return these values when
along with a warning in the documentation, as we can not protect against a
attacker that has access to the node anyway.
Regards Ingela Erlang/OTP team - Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions