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

[Kenneth Lakin]

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.

> 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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20170113/28d5fa3a/attachment.bin>