[erlang-questions] Fwd: Figuring out proper ssl certificate settings with 17.3

[Ingela Andin]

Hi!

To answer a previous question, in the thread. The X509 certificate path
validation is done identical on the server and the client side, however
that does not mean that the CA inputs are used only for this reason. The
Server will always send a cert, but the client will only send one if it was
requested by the server. Also the server may send information in its
request to inform the client of which certs it supports.

2015-02-20 13:44 GMT+01:00 Vincent de Phily <
vincent.dephily@REDACTED>:

> On Thursday 19 February 2015 18:43:26 Vincent de Phily wrote:
> > On Thursday 22 January 2015 21:45:08 Ingela Andin wrote:
> > > If you want to handle
> > > incorrect clients  by building the chain to the client certificate on
> the
> > > server side , if possible, you need to do that in the verify_fun when
> it
> > > fails and then call public_key:pkix_path_validation again with the
> chain
> > > that you built.
> >
> > I didn't try this yet, but I verified that
> >
> > > {partial_chain, fun(CAs) -> {trusted_ca,hd(CAs)} end}
> >
> > "solves" my issue but is basically a verify_none. It seems there's some
> > functionality overlap between partial_chain and verify_fun, but I'm not
> 100%
> > sure when to use which.
>
> FWIW, I managed to get the behaviour I expect (can you spot a bug ?) using
> either verify_fun or partial_chain:
>
> Verif = fun(Cert,{bad_cert, _}, _) ->
>                 case public_key:pkix_path_validation(TrustedCA,[Cert],[])
> of
>                     {ok, _} -> {valid, P};
>                     {error, Reason} -> {fail, Reason}
>                 end;
>            (_, {extension, Ex}, _) ->
>                 {unknown, []};
>            (_, valid, _) ->
>                 {valid, []};
>            (_, valid_peer, _) ->
>                 {valid, []}
>        end,
>


I would match on the unknown_ca atom  too.



> Partial = fun(Chain) ->
>                   case public_key:pkix_path_validation(TrustedCA,Chain,[])
> of
>                   {ok, _} -> {trusted_ca,hd(Chain)};
>                   {error, Reason} -> Reason
>                   end
>           end,
>
> Connecting with
>    {fail_if_no_peer_cert, true},
>    {verify,               verify_peer},
>    {cert,                 MyCert},
>    {key,                  MyKey},
>    {cacerts,              [TrustedCA]}
> and either
>    {verify_fun,           {Verif,[]}}
> or
>    {partial_chain,        Partial}
> Same config for both the client and the server, only the values of
> TrustedCA
> and MyCert/MyKey change.
>
> At this stage, I'm still unsure wether using verify_fun or partial_chain
> makes
> more sense (or is faster).
>
>

There is a semantical difference, the verify_fun is for customising the
 X509-certificate path validation,
the partial chain option is for disregarding certs higher up in the chain,
see also below.



> > I'd like OTP to do the "peer-sent cert chain is signed by one of the
> localy-
> > trusted CAs" step for me. I realize that I could do it myself using the
> > public_key module, but I find it very surprising that my usecase would be
> > so unusual that it isn't supported out of the box. A peer that sends the
> > smallest chain that can be verified by the other peer isn't "incorrect".
>
>
Sending only the peer certificate and not sending intermediate CAs
breaks the TLS protocol, I would not call it correct.

The partial chain option was introduced to let you skip validation steps of
CAs that you do not care about. If you get a chain Root --> A -> B ->  C ->
Peer
and you for some reason have decided that you trust B you can run the
path_validation algorithm with B as trusted ( B becomes the root in
practice).  In the partial chain
fun you are responsible to check that the cert you select as root is one
that you trust.



> These concerns are still valid. If feels strange that my version of
> verify_fun
> does something different than OTP's version.
>
>
Why is that strange? The verify_fun is there so that you can customise your
verification. This of course gives you some responsibility too, of getting
it right!
You can both add application specific checks and change the default
behaviour any way you like, and of course take the  consequences of doing
so.


Regards Ingela Erlang/OTP Team - Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150314/e181f7d2/attachment.htm>