<div dir="ltr">Hi!<br><div><div class="gmail_extra"><br><div class="gmail_quote">2017-01-12 0:17 GMT+01:00 Roger Lipscombe <span dir="ltr"><<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 11 January 2017 at 19:12, Ingela Andin <span dir="ltr"><<a href="mailto:ingela.andin@gmail.com" target="_blank">ingela.andin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>There is currently no supported way. ERL-166 <a href="https://bugs.erlang.org/browse/ERL-166" target="_blank">https://bugs.erlang.org/browse<wbr>/ERL-166</a> talks about the possibility to add such a feature. We have not had time to look further into this as yet.<br></div></div></blockquote><div><br></div></span><div>I'm happy to submit a PR to implement this, provided we can agree on the approach (but it'll be a month or two -- we're still on Erlang 17.x, and there's no point in submitting a patch against that). <br></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Of course, it is possible to provide such an API, although it seems to me that the use case is violating the concept of using TLS in the first place. It can, of course, be argued that if you have access to the erlang node you may dig out the information anyway even if it might be a dirty hack. </div></div></blockquote><div><br></div></span><div>I *would* argue that: We own the server, so the unencrypted traffic is already available. All this is doing is making it easier to see that data in wireshark, where there's a bunch of other useful context.</div></div></div></div></blockquote><div><br><br></div><div>Well our reasoning at the moment is that we could add a debug possibility, that would let connection_information (ssl connection_info is deprecated due to its inflexible return value from old ssl).<br></div><div>return client/server/master_secret values for connections started in debug mode. Just like you can configure a connection to run anonymous ciphers suites for test and debugging purposes. However we would<br></div><div>not want connection_information to return these values by default. Even if you conceptually can get at the information by hacking we do not want to make it easy to do bad things to security by "accident" or<br></div><div>otherwise.<br><br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB<br></div><div> <br> </div></div><br></div></div></div>