[erlang-questions] HTTPC doesn't do HTTPS validation

Ingela Andin <>
Thu Apr 24 10:39:53 CEST 2014


Here is my contribution to this discussion.

2014-04-22 0:07 GMT+02:00 Loïc Hoguin <>:

> 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).
> 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.
httpc is not a full browser/command line client. It could be argued some
such extensions/additions to httpc could be nice,
suggestions and contributions are welcome. At the moment httpc only
forwards raw ssl options to the ssl application.

> On 04/21/2014 11:56 PM, Ransom Richardson wrote:
>> Thanks, it looks like that would work, and I also don't see an easier way.
>> But I'm still shocked that to make a https request in Erlang that
>> verifies that the server cert matches the URL, I need to define my own
>> verify function. And I need to pass a bunch of ssl options on each
>> request - presumably one of which is platform dependent (the list of
>> root CA certs). All to do something that curl does by default.
>> For the record, I've tested httpc, lhttpc, ibrowse and hackney, and none
>> of them actually verify the server has a certificate for the URL they
>> are connecting to.
>> ------------------------------------------------------------------------
>> *From:* Alexei Sholik <>
>> *Sent:* Monday, April 21, 2014 4:55 PM
>> *To:* Ransom Richardson
>> *Cc:* Benoit Chesneau; 
>> *Subject:* Re: [erlang-questions] HTTPC doesn't do HTTPS validation
>> Ransom, if you look at the code closely, you'll see that it uses
>> UserVerifyFun (undefined by default) for the verification.

Yes and if you look even closer at the code you will see that if the
option is verify_peer and there is no user defined verify_fun the
verify_fun will be the default verify_fun of the public_key application
that  looks like

fun(_,{bad_cert, _} = Reason, _) ->
         {fail, Reason};
        (_,{extension, _}, UserState) ->
         {unknown, UserState};
        (_, valid, UserState) ->
         {valid, UserState};
        (_, valid_peer, UserState) ->
         {valid, UserState}

e.i no certificate path evaluation errors are allowed.  Certificate path
validation is defined in RFC 5280.
Currently so called policies are not supported, and CRL-validation is
implemented in public_key but
no automatic integration in ssl is done yet, you can however use it by
supplying information in your own verify_fun.

If there is a path validation error covered by RFC 5280 not handled by
public_key you are welcome to suggest patches or
file error reports.

>> There is also fail_if_no_peer_cert option which is set to false by
>> default.
>> https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L589

This is a server side option and configures the servers behavior for
servers that request client certificates.

>> On Mon, Apr 21, 2014 at 9:58 PM, Ransom Richardson <
>> <mailto:>> wrote:
>>     ​verify_none does seem like the default.

Yes verify_none is the default, there is always a trade off between
interoperability and security and you
should concern yourself with understanding and configuring ssl for the
safety requirements that you have.

>     Also, even if I pass verify_peer, nothing checks if the host name in
>>     the certificate matches the host that I am connecting to. So a
>>     server can present any validly signed certificate for a different
>> site.
>>     Ransom
>>     ------------------------------------------------------------
>> ------------
>>     *From:* Benoit Chesneau <
>>     <mailto:>>
>>     *Sent:* Saturday, April 19, 2014 12:31 AM
>>     *To:* Ransom Richardson
>>     *Cc:*  <mailto:
>> >
>>     *Subject:* Re: [erlang-questions] HTTPC doesn't do HTTPS validation
>>     On Sat, Apr 19, 2014 at 6:17 AM, Ransom Richardson
>>     < <mailto:>> wrote:
>>         But as I reported in this issue
>>         https://github.com/benoitc/hackney/issues/101 I tested against a
>>         server with an invalid cert, and hackney did not catch the
>>         error. httpc also returned ok.
>>         |1> hackney:get(<<"https://localhost:8443/delay">>, [], <<>>,
>> []).
>>         {ok,200,
>>              [{<<"connection">>,<<"keep-alive">>},
>>               {<<"server">>,<<"Cowboy">>},
>>               {<<"date">>,<<"Sat, 19 Apr 2014 00:00:26 GMT">>},
>>               {<<"content-length">>,<<"0">>}],
>>              #Ref<>}|
>>         The same happens if I pass validate_peer and the rootCA file as
>>         ssl_options.
>>         curl correctly rejects the server:
>>         |:~/dev/httpcbench$ curlhttps://localhost:8443/delay
>>         curl: (60) SSL certificate problem, verify that the CA cert is
>> OK. Details:
>>         error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
>> verify failed
>>         :~/dev/httpcbench$ curl --cacert
>> priv/ssl/rootCA.pemhttps://localhost:8443/delay
>>         curl: (51) SSL: certificate subject name 'httpcbench server' does
>> not match target host name 'localhost'|
>>         This is using Erlang 17.0. Is it possible that the ssl default
>>         changed?
>>         Or am I doing something wrong?
If you use openssl s_client that would be a more equal comparison for the
ssl application, will it be rejected then?

Regards Ingela Erlang/OTP team - Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140424/c9afd59a/attachment.html>

More information about the erlang-questions mailing list