<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;" dir="ltr">
<p>Hi,</p>
<p><br>
</p>
<p>I was wondering if someone could clarify what I'm looking at. From the new_ssl page:</p>
<p><br>
</p>
<p><a class="OWAAutoLink" id="LPlnk164161" href="http://erlang.org/documentation/doc-5.7.4/lib/ssl-3.10.7/doc/html/new_ssl.html" previewremoved="true">http://erlang.org/documentation/doc-5.7.4/lib/ssl-3.10.7/doc/html/new_ssl.html</a></p>
<br>
<p><i>If verify_none is specified x509-certificate path validation errors at the client side will not automatically cause the connection to fail, as it will if the verify type is verify_peer. See also the option verify_fun. Servers only do the path validation
if verify_peer is set to true, as it then will send a certificate request to the client (this message is not sent if the verify option is verify_none) and you may then also want to specify the option fail_if_no_peer_cert.
</i></p>
<p><br>
</p>
<p>Based on the above, I would that if we do not specify, verify_none, the new_ssl library would be expected to verify the path. This doesn't seem to be the case:</p>
<p><br>
</p>
<p> ssl:connect('self-signed.badssl.com', 443, [binary, {active, false}, {ssl_imp, new}], 5000).<br>
{ok,{sslsocket,{gen_tcp,#Port<0.43819>,tls_connection,<br>
undefined},<br>
<0.203.0>}}<br>
</p>
<p><br>
</p>
<p>Moreover, ssl errors that aren't related to verifying the peer's path still seem to come up fine by default:</p>
<p><br>
</p>
<p></p>
<div>ssl:connect('wrong.host.badssl.com',443, [binary, {active, false}, {packet, raw}], 5000).<br>
{ok,{sslsocket,{gen_tcp,#Port<0.41371>,tls_connection,<br>
undefined},<br>
<0.110.0>}}<br>
</div>
<p></p>
<p><br>
</p>
<p> ssl:connect('expired.badssl.com', 443, [binary, {active, false}, {packet, raw}], 5000).<br>
{ok,{sslsocket,{gen_tcp,#Port<0.37428>,tls_connection,<br>
undefined},<br>
<0.107.0>}}<br>
</p>
<p><br>
</p>
<p>This sort of thing can lead to a lot of insecure SSL clients, even if users do have the ability to manually turn on a verifier. For example, the popular ibrowse library appears to pass this behaviour directly to the client:</p>
<p><br>
</p>
<p>ibrowse:send_req("https://wrong.host.badssl.com",[], get).<br>
{ok,"200",<br>
</p>
<p>...</p>
<p><br>
</p>
<p>With the only documented statement being "<span>Can talk to secure webservers using SSL</span>".</p>
<p><br>
</p>
<p>And similarly with the "gun" library:</p>
<p><br>
</p>
<p></p>
<div>9> {ok, Pid2} = gun:open("expired.badssl.com", 443),<br>
9> gun:await_up(Pid2).<br>
{ok,http}</div>
<p></p>
<p>flush()</p>
<p>..etc</p>
<p><br>
</p>
<p>There are two separate issues here:</p>
<p><br>
</p>
<ul>
<li>Am I simply reading or implementing the new_ssl page incorrectly? Otherwise, I'd suggest the documentation could be considered bugged. I'd be happy to log a bug and propose alternate wording if this is the case. The ssl page provides big red warnings around
BEAST mitigation. It would be odd to panic over BEAST yet accept self-signed certs.</li><li>Regardless, every major library I've looked at appears to happily accept self signed, expired, or otherwise invalid certs. I'd be happy to reach out to those vendors, but I'm wondering whether the community would feel there's a root cause here that should
be addressed first, even if it's just a documentation fix?</li></ul>
<p>Any assistance here appreciated.</p>
<p><br>
</p>
<p><br>
</p>
</div>
</body>
</html>