<div dir="ltr">Hi!<br><div class="gmail_extra"><br></div><div class="gmail_extra">Here is my contribution to this discussion.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-04-22 0:07 GMT+02:00 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</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">You're partly wrong about curl, curl only can check the CA certs if they are installed. It just happens that if they are installed curl is generally configured to find them automatically (by the OS' package maintainers usually). If they are not installed, then curl rejects pretty much everything, which is neither better nor worse than accepting everything (I wouldn't want either to do things differently than they do now though).<br>
<br>
I agree though that there should be a simple option to do the usual stuff, aka "what browsers and command-line clients do", that would take care of 99% of use cases without needing to spend an hour setting the thing up. Just set the verify_it_properly option, pass the CA certs, done.<div class="">
<br></div></blockquote><div><br></div><div>httpc is not a full browser/command line client. It could be argued some such extensions/additions to httpc could be nice,<br></div><div>suggestions and contributions are welcome. At the moment httpc only forwards raw ssl options to the ssl application.<br>
</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"><div class="">
On 04/21/2014 11:56 PM, Ransom Richardson wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
Thanks, it looks like that would work, and I also don't see an easier way.<br>
<br>
<br>
But I'm still shocked that to make a https request in Erlang that<br>
verifies that the server cert matches the URL, I need to define my own<br>
verify function. And I need to pass a bunch of ssl options on each<br>
request - presumably one of which is platform dependent (the list of<br>
root CA certs). All to do something that curl does by default.<br>
<br>
<br>
For the record, I've tested httpc, lhttpc, ibrowse and hackney, and none<br>
of them actually verify the server has a certificate for the URL they<br>
are connecting to.<br>
<br>
<br>
<br></div>
------------------------------<u></u>------------------------------<u></u>------------<br>
*From:* Alexei Sholik <<a href="mailto:alcosholik@gmail.com" target="_blank">alcosholik@gmail.com</a>><br>
*Sent:* Monday, April 21, 2014 4:55 PM<br>
*To:* Ransom Richardson<br>
*Cc:* Benoit Chesneau; <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
*Subject:* Re: [erlang-questions] HTTPC doesn't do HTTPS validation<div class=""><br>
Ransom, if you look at the code closely, you'll see that it uses<br>
UserVerifyFun (undefined by default) for the verification.<br></div></blockquote></blockquote><div><br></div><div><br>Yes and if you look even closer at the code you will see that if the<br></div><div>option is verify_peer and there is no user defined verify_fun the<br>
</div><div>verify_fun will be the default verify_fun of the public_key application <br>that looks like<br><br>fun(_,{bad_cert, _} = Reason, _) -><br> {fail, Reason};<br> (_,{extension, _}, UserState) -><br>
{unknown, UserState};<br> (_, valid, UserState) -><br> {valid, UserState};<br> (_, valid_peer, UserState) -><br> {valid, UserState}<br> end<br></div><div><br><br></div><div>
e.i no certificate path evaluation errors are allowed. Certificate path validation is defined in RFC 5280.<br></div><div>Currently so called policies are not supported, and CRL-validation is implemented in public_key but<br>
</div><div>no automatic integration in ssl is done yet, you can however use it by supplying information in your own verify_fun.</div><div><br></div><div>If there is a path validation error covered by RFC 5280 not handled by public_key you are welcome to suggest patches or<br>
</div><div>file error reports.<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"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">
<br>
There is also fail_if_no_peer_cert option which is set to false by default.<br>
<br>
<a href="https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L589" target="_blank">https://github.com/erlang/otp/<u></u>blob/maint/lib/ssl/src/ssl.<u></u>erl#L589</a><br></div></blockquote></blockquote><div><br>
<br></div><div>This is a server side option and configures the servers behavior for servers that request client certificates.<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">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">
<br>
<br>
On Mon, Apr 21, 2014 at 9:58 PM, Ransom Richardson <<a href="mailto:ransomr@talko.com" target="_blank">ransomr@talko.com</a><br></div><div class="">
<mailto:<a href="mailto:ransomr@talko.com" target="_blank">ransomr@talko.com</a>>> wrote:<br>
<br>
verify_none does seem like the default.<br>
<br></div></blockquote></blockquote><div><br><br></div><div>Yes verify_none is the default, there is always a trade off between interoperability and security and you<br></div><div>should concern yourself with understanding and configuring ssl for the safety requirements that you have. <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"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">
Also, even if I pass verify_peer, nothing checks if the host name in<br>
the certificate matches the host that I am connecting to. So a<br>
server can present any validly signed certificate for a different site.<br>
<br>
<br>
Ransom<br>
<br>
<br></div>
------------------------------<u></u>------------------------------<u></u>------------<br>
*From:* Benoit Chesneau <<a href="mailto:bchesneau@gmail.com" target="_blank">bchesneau@gmail.com</a><br>
<mailto:<a href="mailto:bchesneau@gmail.com" target="_blank">bchesneau@gmail.com</a>>><br>
*Sent:* Saturday, April 19, 2014 12:31 AM<br>
<br>
*To:* Ransom Richardson<br>
*Cc:* <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><br>
*Subject:* Re: [erlang-questions] HTTPC doesn't do HTTPS validation<div class=""><br>
<br>
<br>
<br>
On Sat, Apr 19, 2014 at 6:17 AM, Ransom Richardson<br></div><div class="">
<<a href="mailto:ransomr@talko.com" target="_blank">ransomr@talko.com</a> <mailto:<a href="mailto:ransomr@talko.com" target="_blank">ransomr@talko.com</a>>> wrote:<br>
<br>
But as I reported in this issue<br>
<a href="https://github.com/benoitc/hackney/issues/101" target="_blank">https://github.com/benoitc/<u></u>hackney/issues/101</a> I tested against a<br>
server with an invalid cert, and hackney did not catch the<br>
error. httpc also returned ok.<br>
<br>
<br>
|1> hackney:get(<<"<a href="https://localhost:8443/delay" target="_blank">https://<u></u>localhost:8443/delay</a>">>, [], <<>>, []).<br>
{ok,200,<br>
[{<<"connection">>,<<"keep-<u></u>alive">>},<br>
{<<"server">>,<<"Cowboy">>},<br>
{<<"date">>,<<"Sat, 19 Apr 2014 00:00:26 GMT">>},<br>
{<<"content-length">>,<<"0">>}<u></u>],<br>
#Ref<0.0.0.111>}|<br>
<br>
The same happens if I pass validate_peer and the rootCA file as<br>
ssl_options.<br>
<br>
<br>
curl correctly rejects the server:<br>
<br>
<br></div>
|talko@ubuntu:~/dev/<u></u>httpcbench$ curlhttps://localhost:8443/<u></u>delay<div class=""><br>
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:<br>
error:14090086:SSL routines:SSL3_GET_SERVER_<u></u>CERTIFICATE:certificate verify failed<br>
<br></div>
talko@ubuntu:~/dev/httpcbench$ curl --cacert priv/ssl/rootCA.pemhttps://<u></u>localhost:8443/delay<div class=""><br>
curl: (51) SSL: certificate subject name 'httpcbench server' does not match target host name 'localhost'|<br>
<br>
<br>
This is using Erlang 17.0. Is it possible that the ssl default<br>
changed?<br>
<br>
<br>
Or am I doing something wrong?</div></blockquote><br></blockquote></div><br></div><div class="gmail_extra">If you use openssl s_client that would be a more equal comparison for the ssl application, will it be rejected then? <br>
<br><br></div><div class="gmail_extra">Regards Ingela Erlang/OTP team - Ericsson AB<br></div><div class="gmail_extra"><br><br></div></div>