[erlang-questions] SSL inconsistencies in expected return values of 'ssl:connect/2'

[Ingela Andin]

Hi!

The remaining issues I think comes down to that the server in your example
does not have access to all the CA-certificates so it can not build its on
chain
properly. CA certificates are both used to build the own chain and verify
the others chain. This will mean that the server will only send its own
cert to the client and not
the intermediate CA. TLS specifies that only the ROOT CA may be left out of
the chain. However PKIX standard does allow for the user to specify an
intermediate certificate to be the trusted anchor. So in the latest erlang
ssl application there is a new option partial_chain to handle this. In
older version however some partial chains where "accidentally" accepted by
default (if all intermediate CAs where specified in cacerts).

>From the documentation:
*{partial_chain, fun(Chain::[DerCert]) -> {trusted_ca, DerCert} |
unknown_ca * Claim an intermediat CA in the chain as trusted. TLS will then
perform the public_key:pkix_path_validation/3 with the selected CA as
trusted anchor and the rest of the chain.

Also your CRL-check does not really check everything specified by the RFC.
For now you need to call public_key:pkix_crls_validate/3  in your
verify_fun,  if you want a proper check. This is a little cumbersome and we
are working on creating a better integration of it in ssl.
Regards Ingela Erlang/OTP team - Ericsson AB


2014-10-08 10:55 GMT+02:00 Andre Graf <andre.graf@REDACTED>:

>  On 10/08/2014 10:47 AM, Ingela Andin wrote:
>
> Hi!
>
> 2014-10-08 0:22 GMT+02:00 Andre Graf <andre.graf@REDACTED>:
>
>> Hi there,
>>
>> today I wrote a EUnit test suite that should check the SSL connection
>> setup to an Erlang SSL server. Although the test cases are pretty simple
>> and standard I stumbled upon various inconsistencies when testing
>> against different OTP versions (R15B02, R16B03-1,OTP-17.3.1). I thought
>> I share my findings.
>>
>> The different test cases are:
>>
>> 1. Connect No Client Auth (SUCCESS)
>> 2. Connect No Client Auth (FAIL: wrong CA)
>> 3. Connect Client Auth (SUCCESS)
>> 4. Connect Client Auth (FAIL: no Client Cert provided)
>> 5. Connect Client Auth (FAIL: Client Cert expired)
>> 6. Connect Client Auth (FAIL: CRL check, Client Cert revoked)
>> 7. Connect Client Auth (SUCCESS, CRL check)
>>
>> Inconsistencies in expected return of 'ssl:connect/2' in test case 2:
>> - R15B02: {error,"unknown ca"}}
>> - R16B03-1: {error,{tls_alert,"unknown ca"}}
>> - OTP-17.3.1: {error,{tls_alert,"unknown ca"}}
>>
>>
>  This is part of the documented potential incompatibility that we choose
> to do to to improve the quality of the error messages.
>
>
>
>> Inconsistencies in expected return of 'ssl:connect/2' in test case 3:
>> - R15B02: {ok, Sock}
>> - R16B03-1: {ok, Sock}
>> - OTP-17.3.1: {error,closed}
>>
>>
>  Will try your test case when I get time. Seems strange.
>
>
>
>> Inconsistencies in expected return of 'ssl:connect/2' in test case 4:
>> - R15B02: {error,esslconnect}
>> - R16B03-1: {error,{tls_alert,"handshake failure"}}
>> - OTP-17.3.1: {error,{tls_alert,"handshake failure"}}
>>
>>
> This is also part of the documented potential incompatibility that we
> choose to do to to improve the quality of the error messages.
>
>
>  Inconsistencies in expected return of 'ssl:connect/2' in test case 5:
>> - R15B02: {error,"certificate expired"}
>> - R16B03-1: {error,{tls_alert,"certificate expired"}}
>> - OTP-17.3.1: {error,{tls_alert,"unknown ca"}}
>>
>>   Will try your test case when I get time. Seems strange.
>
>
>  Inconsistencies in expected return of 'ssl:connect/2' in test case 6:
>> - R15B02: SSL handshake process crashes
>> - R16B03-1: {error,{tls_alert,"certificate revoked"}}
>> - OTP-17.3.1: {error,closed}
>>
>>
>  Alas you can never depend on getting the correct error message an not
> {error,closed} as
>  tcp does note have a delivery guarantee on application level, only on
> transport level.
>  So ssl sends its alert and then closes the socket, and with bad timing
> the application may
>  receive the socket close before it receives the error message data.
>
>  Inconsistencies in expected return of 'ssl:connect/2' in test case 7:
>> - R15B02: {ok, Socket}
>> - R16B03-1: {ok, Socket}
>> - OTP-17.3.1: {error,{tls_alert,"unknown ca"}}
>>
>>
> Will try your test case when I get time. Seems strange.
>
>
>  Regards Ingela Erlang/OTP team - Ericsson AB
>
>
>  No inconsistencies in test case 1. :)
>>
>> The code is available on https://github.com/dergraf/erlang_ssl_tester.
>>
>> Cheers,
>> André
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>   Hello Ingela,
>
> Thanks for your reply. Please let me know if you need any help with the
> test case. The tests should pass on R16B03-1, just run 'rebar eunit'.
>
> Cheers,
> André
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141013/938ea167/attachment.htm>