<div dir="ltr"><br><div class="gmail_extra">Hi!</div><div class="gmail_extra"><br><div class="gmail_quote">2018-01-22 16:55 GMT+01:00 San Gillis <span dir="ltr"><<a href="mailto:san.gillis@truqu.com" target="_blank">san.gillis@truqu.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"><div dir="ltr"><div>I tried adding {server_name_indication, disable} to my ssl_dist_optfile. (So it is `[{server, ...}, {client, [..., {server_name_indication, disable}]}]`, is that correct?). This doesn't change the error I get.<br><br></div></div></blockquote><div><br></div><div>Looks right  .... it is a pretty new feature so we will look into if it is tested well enough or if you just missed some little detail!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div>Also, if I understand the documentation correctly, this disables all hostname checking. Would this leave us vulnerable to MITM attacks?<br></div></blockquote><div><br></div><div><br></div><div>Yes it disables all hostname checks making you vulnerable to the things they where designed to protect. The way to customize the checks is to handle them in your own verify_fun, why do you think that is convulted?</div><div>The verify_fun can be very simple only specifically handling the <span style="font-size:12.8px"> </span><span style="font-size:12.8px">{bad_cert, hostname_check_failed} then all other checks will behave as before. The verify_fun is not meant to  replace the default certiface checks it </span></div><div><span style="font-size:12.8px">is for extending the checks </span><span style="font-size:12.8px">and possible ignoring some specific error (even though this is seldom desirable). </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Something like:</span></div><div><span style="font-size:12.8px"><br></span></div><div><pre style="font-family:mono,Courier,monospace;margin-top:0px;margin-bottom:0px;color:rgb(56,58,66);font-size:11.2px">{fun(_,{bad_cert, hostname_check_failed}, _) ->
         %%% Preform own check ...
    (_,{extension, _}, UserState) ->
         {unknown, UserState};
    (_, valid, UserState) ->
         {valid, UserState};
    (_, valid_peer, UserState) ->
         {valid, UserState}
 end, []}</pre></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Initial UserStae is </span><span style="color:rgb(56,58,66);font-family:mono,Courier,monospace;font-size:11.2px">[]</span></div><div><span style="color:rgb(56,58,66);font-family:mono,Courier,monospace;font-size:11.2px"><br></span></div><div><span style="font-size:12.8px">Regards Ingela Erlang/OTP team - Ericsson AB</span></div><div><span style="font-size:12.8px"><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">2018-01-22 16:34 GMT+01:00 Dmitry Kolesnikov <span dir="ltr"><<a href="mailto:dmkolesnikov@gmail.com" target="_blank">dmkolesnikov@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"><div style="word-wrap:break-word">Hello,<div><br></div><div>I had a similar problem with plain TLS socket after 19.x to 20.x migration. This is due to SNI feature. I’ve disabled it using following ssl socket option: {server_name_indication, disab<wbr>le}</div><div><br></div><div>I think same applies for dist sockets as well. </div><div><br></div><div>Best Regards, </div><div>Dmitry<br><div><br><blockquote type="cite"><div><div class="gmail-m_-129538267313506535h5"><div>On 22 Jan 2018, at 17.28, San Gillis <<a href="mailto:san.gillis@truqu.com" target="_blank">san.gillis@truqu.com</a>> wrote:</div><br class="gmail-m_-129538267313506535m_-1979495790397265361Apple-interchange-newline"></div></div><div><div><div class="gmail-m_-129538267313506535h5"><div dir="ltr"><div><div>Since upgrading to Erlang 20.2 (from 19.3) we've been having issues with using SSL for Erlang distribution.</div></div><div><br></div><div>We used to run our nodes with</div><div>```</div><div>-ssl_dist_opt server_verify verify_peer</div><div>-ssl_dist_opt client_verify verify_peer</div><div>```</div><div>in the vm.args file. Since the upgrade this failed with {bad_cert, hostname_check_failed}.</div><div><br></div><div>I noticed that this hostname check fails because `fun public_key:verify_hostname_mat<wbr>ch_default/2` is receiving `{dns_id, "<a href="mailto:nodename@subdomain.hostname.com" target="_blank">nodename@subdomain.hostname.c<wbr>om</a>"}` and `{dNSName,"*.<a href="http://hostname.com/" target="_blank">hostname.com</a>"}` as arguments, which will fail to check.</div><div><br></div><div>I have looked into providing `verify_fun` to do custom verification, but this seems pretty convoluted if I just want to `erl -remsh <a href="mailto:nodename@subdomain.hostname.com" target="_blank">nodename@subdomain.hostname.co<wbr>m</a> -ssl_dist_optfile ...` into the given node.</div><div><br></div><div>Did anyone else run into this issue? Are there some better ways to fix this?<br></div></div></div></div>
______________________________<wbr>_________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/list<wbr>info/erlang-questions</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div></div>