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

Tue Oct 21 11:58:56 CEST 2014

Hi!

Is it possible to use public_key:pkix_crls_validate with CRLs not using the
> Distribution Point extension?
>
>
You can create a DP for the input.  Outlned  from the RFC:

The CRLs that should be considerd in CRL processing are:

 "For each distribution point (DP) in the certificate's CRL
 distribution points extension, for each corresponding CRL in the
   local CRL cache"

run algorithm in public_key and

 "if the revocation status has not been determined, repeat the process
   above with any available CRLs not specified in a distribution point
   but issued by the certificate issuer.  For the processing of such a
   CRL, assume a DP with both the reasons and the cRLIssuer fields
   omitted and a distribution point name of the certificate issuer.
   That is, the sequence of names in fullName is generated from the
   certificate issuer field as well as the certificate issuerAltName
   extension."

Regards Ingela Erlang/OTP team - Ericsson AB

All the best,
> André
>
>
> On 10/13/2014 11:48 AM, Ingela Andin wrote:
>
>  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/20141021/6bee314d/attachment.htm>