<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Sorry, my bad. The reported
inconsistency with the expired certificate is gone. This was an
error in the test suite.<br>
<br>
On 10/21/2014 10:10 AM, Andre Graf wrote:<br>
</div>
<blockquote cite="mid:54461506.1080905@erl.io" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<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>
</blockquote>
<br>
</body>
</html>