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

Andre Graf andre.graf@REDACTED
Tue Oct 21 10:10:46 CEST 2014


Hello Ingela,

Thanks for your response! Indeed, adding the partial_chain (just a very
dump one, always returning {trusted_ca, DerCert}) option as advised
solves most of the mentioned problems. However, one new inconsistency
appeared as well as one question regarding CRLs remain.

The test checking SSL client auth with an expired certificate fails, it
happily accepts a connection {ok, Socket} with the expired certificate
on 17, whereas R16B03 returns {error, {tls_alert, "certificate expired"}}.

Is it possible to use public_key:pkix_crls_validate with CRLs not using
the Distribution Point extension?

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
> <mailto: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
>>     <mailto: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 <mailto: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/3ffc0079/attachment.htm>


More information about the erlang-questions mailing list