<div dir="ltr"><div class="gmail_extra"><div>Hi!<br><br>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<br></div><div>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<br>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). <br><br><div>From the documentation:<br></div><div><dl><dt><b>{partial_chain, fun(Chain::[DerCert]) -> {trusted_ca, DerCert} | unknown_ca </b></dt><dd>
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.
</dd></dl><p>Also your CRL-check does not really check everything specified by the RFC. For now you need to call <a name="14908e47ce70bf81_pkix_crls_validate-3"><span>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.<br></span></a></p></div><div>Regards Ingela Erlang/OTP team - Ericsson AB<br></div><br></div><br><div class="gmail_quote">2014-10-08 10:55 GMT+02:00 Andre Graf <span dir="ltr"><<a href="mailto:andre.graf@erl.io" target="_blank">andre.graf@erl.io</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div>
<div>On 10/08/2014 10:47 AM, Ingela Andin
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi!<br>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">2014-10-08 0:22 GMT+02:00 Andre
Graf <span dir="ltr"><<a href="mailto:andre.graf@erl.io" target="_blank">andre.graf@erl.io</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi there,<br>
<br>
today I wrote a EUnit test suite that should check the
SSL connection<br>
setup to an Erlang SSL server. Although the test cases
are pretty simple<br>
and standard I stumbled upon various inconsistencies
when testing<br>
against different OTP versions (R15B02,
R16B03-1,OTP-17.3.1). I thought<br>
I share my findings.<br>
<br>
The different test cases are:<br>
<br>
1. Connect No Client Auth (SUCCESS)<br>
2. Connect No Client Auth (FAIL: wrong CA)<br>
3. Connect Client Auth (SUCCESS)<br>
4. Connect Client Auth (FAIL: no Client Cert provided)<br>
5. Connect Client Auth (FAIL: Client Cert expired)<br>
6. Connect Client Auth (FAIL: CRL check, Client Cert
revoked)<br>
7. Connect Client Auth (SUCCESS, CRL check)<br>
<br>
Inconsistencies in expected return of 'ssl:connect/2' in
test case 2:<br>
- R15B02: {error,"unknown ca"}}<br>
- R16B03-1: {error,{tls_alert,"unknown ca"}}<br>
- OTP-17.3.1: {error,{tls_alert,"unknown ca"}}<br>
<br>
</blockquote>
<div><br>
</div>
<div>This is part of the documented potential
incompatibility that we choose to do to to improve the
quality of the error messages.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Inconsistencies in expected return of 'ssl:connect/2' in
test case 3:<br>
- R15B02: {ok, Sock}<br>
- R16B03-1: {ok, Sock}<br>
- OTP-17.3.1: {error,closed}<br>
<br>
</blockquote>
<div><br>
</div>
<div>Will try your test case when I get time. Seems
strange.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Inconsistencies in expected return of 'ssl:connect/2' in
test case 4:<br>
- R15B02: {error,esslconnect}<br>
- R16B03-1: {error,{tls_alert,"handshake failure"}}<br>
- OTP-17.3.1: {error,{tls_alert,"handshake failure"}}<br>
<br>
</blockquote>
<div> <br>
This is also part of the documented potential
incompatibility that we choose to do to to improve the
quality of the error messages.<br>
<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Inconsistencies in expected return of 'ssl:connect/2' in
test case 5:<br>
- R15B02: {error,"certificate expired"}<br>
- R16B03-1: {error,{tls_alert,"certificate expired"}}<br>
- OTP-17.3.1: {error,{tls_alert,"unknown ca"}}<br>
<br>
</blockquote>
<div> Will try your test case when I get time. Seems
strange.<br>
<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Inconsistencies in expected return of 'ssl:connect/2' in
test case 6:<br>
- R15B02: SSL handshake process crashes<br>
- R16B03-1: {error,{tls_alert,"certificate revoked"}}<br>
- OTP-17.3.1: {error,closed}<br>
<br>
</blockquote>
<div> <br>
</div>
<div>Alas you can never depend on getting the correct
error message an not {error,closed} as<br>
</div>
<div>tcp does note have a delivery guarantee on
application level, only on transport level. <br>
</div>
<div>So ssl sends its alert and then closes the socket,
and with bad timing the application may<br>
</div>
<div>receive the socket close before it receives the error
message data.<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Inconsistencies in expected return of 'ssl:connect/2' in
test case 7:<br>
- R15B02: {ok, Socket}<br>
- R16B03-1: {ok, Socket}<br>
- OTP-17.3.1: {error,{tls_alert,"unknown ca"}}<br>
<br>
</blockquote>
<div> <br>
Will try your test case when I get time. Seems strange.<br>
<br>
<br>
</div>
<div>Regards Ingela Erlang/OTP team - Ericsson AB<br>
</div>
<div><br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
No inconsistencies in test case 1. :)<br>
<br>
The code is available on <a href="https://github.com/dergraf/erlang_ssl_tester" target="_blank">https://github.com/dergraf/erlang_ssl_tester</a>.<br>
<br>
Cheers,<br>
André<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote></div></div>
Hello Ingela,<br>
<br>
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'. <br>
<br>
Cheers,<br>
André<br>
</div>
</blockquote></div><br></div></div>