[erlang-questions] HTTPC doesn't do HTTPS validation
Ingela Andin
ingela.andin@REDACTED
Thu Apr 24 10:39:53 CEST 2014
Hi!
Here is my contribution to this discussion.
2014-04-22 0:07 GMT+02:00 Loïc Hoguin <essen@REDACTED>:
> 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 <alcosholik@REDACTED>
>> *Sent:* Monday, April 21, 2014 4:55 PM
>> *To:* Ransom Richardson
>> *Cc:* Benoit Chesneau; erlang-questions@REDACTED
>> *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}
end
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 <ransomr@REDACTED
>> <mailto:ransomr@REDACTED>> 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 <bchesneau@REDACTED
>> <mailto:bchesneau@REDACTED>>
>> *Sent:* Saturday, April 19, 2014 12:31 AM
>>
>> *To:* Ransom Richardson
>> *Cc:* erlang-questions@REDACTED <mailto:erlang-questions@REDACTED
>> >
>> *Subject:* Re: [erlang-questions] HTTPC doesn't do HTTPS validation
>>
>>
>>
>>
>> On Sat, Apr 19, 2014 at 6:17 AM, Ransom Richardson
>> <ransomr@REDACTED <mailto:ransomr@REDACTED>> 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<0.0.0.111>}|
>>
>> The same happens if I pass validate_peer and the rootCA file as
>> ssl_options.
>>
>>
>> curl correctly rejects the server:
>>
>>
>> |talko@REDACTED:~/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
>>
>> talko@REDACTED:~/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.htm>
More information about the erlang-questions
mailing list