<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hello Ingela,<br>
<br>
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.<br>
<br>
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"}}.<br>
<br>
Is it possible to use public_key:pkix_crls_validate with CRLs not
using the Distribution Point extension?<br>
<br>
All the best,<br>
André<br>
<br>
On 10/13/2014 11:48 AM, Ingela Andin wrote:<br>
</div>
<blockquote
cite="mid:CAFj9NSR5XUgQiaqQqVYVxicuMy7vUY_KbEz_5BaHHjjp0hLRgw@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org"
target="_blank">erlang-questions@erlang.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>