Hello!

On Wed, Oct 23, 2013 at 02:48:38PM -0700, Piotr Sikora wrote:

> Hey,
>
> > Just drop the backwards-compatibility and require OpenSSL 1.0.2 or
> > later for that feature, just like a particular version of OpenSSL is
> > needed for TLS-SNI.
>
> I kind of agree with that.
>
> While OpenSSL-1.0.2 is still unreleased, it seems that all options for
> existing releases are a bit hacky, to say at least... The trusted
> certificate store sounds like the only way to do it right now, but it
> effectively makes SSL client verification useless and creates a
> security issue.
>
> What do you think, Maxim?

I strongly disagree with automatic adding certificates from a
certificate chain to a trusted store, it's just not an option.
Otherwise, I don't think that use of a trusted certificate store is
a major problem.

The same problem is already here if one want to use OCSP Stapling
and verify signatures (and one probably want to, given the fact
that an incorrect OCSP Staple can be easily used to DoS a server
if a client follows RFC6066, and e.g. Firefox folks seems to try
to do so and fail a connection on an incorrect OCSP Staple, see
http://trac.nginx.org/nginx/ticket/425). And the same happens if
a complex PKI is used, and only some users should be allowed to
login.

In a long term I think that our client verification code should be
complemented by some access control functionality (as of now, one
can use rewrite module for checks, and some do use them anyway,
but it's not very convenient).

As for multiple certs per se, I don't think it should be limited
to recent OpenSSL versions only. As far as I can tell, current
versions of OpenSSL will work just fine (well, mostly) as long as
both ECDSA and RSA certs use the same certificate chain. I
believe at least some CAs issue ECDSA certs this way, and this
should work.

Limiting support for multiple certs with separate certificate
chains to only recent OpenSSL versions seems reasonable for me,
but if Rob wants to try to make it work with older versions - I
don't really object. If it won't be too hacky it might worth
supporting.

--
Maxim Dounin
http://nginx.org/en/donation.html

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel