[erlang-questions] SSL inconsistencies in expected return values of 'ssl:connect/2'
Andre Graf
andre@REDACTED
Tue Oct 21 10:30:35 CEST 2014
Sorry, my bad. The reported inconsistency with the expired certificate
is gone. This was an error in the test suite.
On 10/21/2014 10:10 AM, Andre Graf wrote:
> 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/9f751c89/attachment.htm>
More information about the erlang-questions
mailing list