[erlang-bugs] possible bug in ssl and/or public_key module (R13 and R14)

[Filipe David Manana]

Just a few more questions,

1) are the 'verify_fun' and 'cacertfile' options meant to be used together
or are they mutually exclusive?

2) Trying to do this on Ubuntu:

{cacertfile, "/etc/ssl/certs/ca-certificates.crt"}

That file, is a list o PEM encoded certificate:

$ file /etc/ssl/certs/ca-certificates.crt
/etc/ssl/certs/ca-certificates.crt: PEM certificate

However I get the following exception when I pass that option:

** exception error: no match of right hand side value {error,ecacertfile}
     in function  ssl_test:test/0

=ERROR REPORT==== 17-Sep-2010::18:33:04 ===
SSL: 1056: error:{error,
                  {badmatch,
                   {error,
                    {asn1,
                     {'Type not compatible with table constraint',
                      {{badmatch,{error,{asn1,{wrong_tag,{5,16}}}}},
                       [{'OTP-PUB-KEY','dec_Dss-Parms',2},
                        {'OTP-PUB-KEY',dec_SignatureAlgorithm,2},
                        {'OTP-PUB-KEY',dec_OTPTBSCertificate,2},
                        {'OTP-PUB-KEY',dec_OTPCertificate,2},
                        {'OTP-PUB-KEY',decode,2},
                        {pubkey_cert_records,decode_cert,1},
                        {public_key,pkix_decode_cert,2},
                        {ssl_certificate_db,add_certs,3}]}}}}}}
/etc/ssl/certs/ca-certificates.crt
  [{ssl_connection,init_certificates,2},
   {ssl_connection,ssl_init,2},
   {ssl_connection,init,1},
   {gen_fsm,init_it,6},
   {proc_lib,init_p_do_apply,3}]

Is this a bug? The ssl man page mentions the file is in the PEM format.
The file contents can be looked at:
http://friendpaste.com/4lQn7yihrUa4fE2Vs4u7JS

3) For the verify function, it receives {bad_cert, unknown_ca} when a
certificate is self-signed? I would like to distinguish between unknown CAs
and self-signed certificates (certificate signed by the target host).

cheers

On Fri, Sep 17, 2010 at 1:04 PM, Filipe David Manana <fdmanana@REDACTED>wrote:

> Both approaches worked for me:
>
> 1) adding {depth, 3}   (weird that it's necessary when {verify,
> verify_none} is passed)
>
> 2) adding the verify_fun option that Ingela wrote
>
> thank you both
>
>
> On Fri, Sep 17, 2010 at 9:19 AM, Ingela Anderton Andin <
> ingela@REDACTED> wrote:
>
>> Hi!
>>
>> Humm ...
>>
>> I get this result running your program:
>>
>> Erlang R14B (erts-5.8.1) [source] [smp:4:4] [rq:4] [async-threads:0]
>> [kernel-poll:false]
>>
>>
>> Eshell V5.8.1  (abort with ^G)
>> 1> c(ssl_test).
>> {ok,ssl_test}
>> 2> ssl_test:test().
>>
>> =ERROR REPORT==== 17-Sep-2010::09:22:46 ===
>> SSL: certify_certificate: ./ssl_handshake.erl:570:Fatal error: certificate
>> expired
>> ** exception error: no match of right hand side value {error,"certificate
>> expired"}
>>    in function  ssl_test:test/0
>>
>>
>> Did you run your test on a github version of a R14B to be? I do not see
>> how you could get
>> a completely different error.
>>
>> If I do
>>
>> FunAndState = {fun(_,{bad_cert, unknown_ca}, UserState) -> {valid,
>> UserState}; (_,{bad_cert, cert_expired}, UserState) -> {valid, UserState};
>> (_,{bad_cert, _} = Reason, _) -> {fail, Reason}; (_,{extension, _},
>> UserState) -> {unknown, UserState}; (_, valid, UserState) -> {valid,
>> UserState} end, []}.
>>
>> ssl:connect(couchdb.staging.one.ubuntu.com, 443, [{verify, verify_peer},
>> {verify_fun, FunAndState}]).
>>
>> I get a connection. (I.e I accept that the certificate has expired)
>>
>> However  ssl:connect(couchdb.staging.one.ubuntu.com, 443,  [{verify, 0},
>> {ssl_imp, old}]).
>>
>> will give a connection so it seems {verify, 0} is  more forgiving than
>> {verify, verify_none} that only allows the path error unkonwn_ca
>> at the moment, maybe we have to rethink that for backwards compatibility
>> reasons.
>>
>> Regards Ingela Erlang/OTP team - Ericsson AB
>>
>>
>> Filipe David Manana wrote:
>>
>>> When connecting to particular server, though an ssl socket, I always get
>>> the
>>> error:
>>>
>>> Erlang R14B (erts-5.8.1) [source] [smp:2:2] [rq:2] [async-threads:0]
>>> [hipe]
>>> [kernel-poll:false]
>>>
>>> Eshell V5.8.1  (abort with ^G)
>>> 1> c(test_ssl).
>>> {ok,test_ssl}
>>> 2> test_ssl:test().
>>>
>>> =ERROR REPORT==== 17-Sep-2010::02:07:25 ===
>>> SSL: certify_certificate: ./ssl_handshake.erl:502:Fatal error: handshake
>>> failure
>>> ** exception error: no match of right hand side value {error,esslconnect}
>>>     in function  test_ssl:test/0
>>> 3>
>>>
>>> However, if I pick up another server, like www.cia.gov:443 or
>>> www.facebook.com:443 for example, it succeeds (with exactly the same ssl
>>> options passed to ssl:connect/3).
>>> Also tested with R13B03 and R13B04 and got the same results (only
>>> modified
>>> value of option verify from verify_none to 0).
>>>
>>> The code to test this eventual bug is:
>>>
>>> -module(test_ssl).
>>> -compile(export_all).
>>>
>>> -define(HOST, "couchdb.staging.one.ubuntu.com").
>>> % -define(HOST, "www.cia.gov").
>>>
>>> test() ->
>>>    Body = iolist_to_binary([
>>>        "GET / HTTP/1.1\r\n",
>>>        "Host: ", ?HOST, "\r\n",
>>>        "Accept: */*\r\n",
>>>        "Connection: close\r\n", "\r\n"
>>>    ]),
>>>    application:start(crypto),
>>>    application:start(public_key),
>>>    application:start(ssl),
>>>    Options = [
>>>                {ssl_imp, new},
>>>                binary,
>>>                {nodelay, true},
>>>                {active, false},
>>>                {verify, verify_none}
>>>                % {verify_fun, fun(_) -> true end},
>>>    ],
>>>    {ok, S} = ssl:connect(?HOST, 443, Options),
>>>    ok = ssl:send(S, Body),
>>>    loop(S),
>>>    ssl:close(S).
>>>
>>> loop(S) ->
>>>    ssl:setopts(S, [{active, once}]),
>>>    receive
>>>    {ssl, S, Data} ->
>>>        io:format("received data:  ~p~n", [Data]),
>>>        loop(S);
>>>    {ssl_closed, S} ->
>>>        io:format("socket closed", []);
>>>    {ssl_error, S, Error} ->
>>>        io:format("socket error:  ~p", [Error])
>>>    end.
>>>
>>>
>>> cheers
>>>
>>>
>>>
>>
>>
>> ________________________________________________________________
>> erlang-bugs (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED
>>
>>
>
>
> --
> Filipe David Manana,
> fdmanana@REDACTED, fdmanana@REDACTED
>
> "Reasonable men adapt themselves to the world.
>  Unreasonable men adapt the world to themselves.
>  That's why all progress depends on unreasonable men."
>
>


-- 
Filipe David Manana,
fdmanana@REDACTED, fdmanana@REDACTED

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."