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