Hello.

On Mon, Mar 18, 2019 at 07:29:38PM +0300, Maxim Dounin wrote:
> > > Since nginx does not call X509_verify_cert() directly, the only
> > > documented approach is to use the OPENSSL_ALLOW_PROXY_CERTS
> > > environment variable.
> >
> > I think they simply forgot to change the documentation.
>
> Well, this is likely what indeed happened. But either way there
> is a bug in OpenSSL: either the code or the documentation is
> wrong. And, given the number of recent cases with OpenSSL
> changes, I really want them to decide it themselves where the bug
> is.

Agreed. I'll comment in the issue you mentioned asking for
clarification.

I also think that when they say "if the application directly calls
X509_verify_cert()", they don't mean "directly" literally; I think
they rather mean "if the application has control over the SSL context
used to verify the cert".

> Note well that the documentation never mentions that the
> environment variable is a hack and properly written programs which
> simply use client certificate authentication as with
> SSL_CTX_set_verify(SSL_VERIFY_PEER) should use
> X509_STORE_CTX_set_flags(X509_V_FLAG_ALLOW_PROXY_CERTS) instead.
> Instead, it specifically mentions that OPENSSL_ALLOW_PROXY_CERTS
> should be used in this case, providing no other alternatives.
> This makes removing the OPENSSL_ALLOW_PROXY_CERTS environment
> variable support highly questionable from compatibility point of
> view, since no application could foresee it will be removed.

The definition of "hack" was in the code and in the commit that
removed it

https://github.com/openssl/openssl/commit/8e21938ce3a5306df753eb40a20fe30d17cf4a68

> > As far as I know, proxy certificates were introduced as the basic
> > mechanism for authN and authZ in Grid computing, where they are still
> > widely used. It may well be that's the only field though. Indeed also
> > the submitter of that issue is in that field.
>
> Thanks for the details. Indeed it looks like these are only used
> in Grid computing. It would be interesting to hear how nginx is
> used in such workloads.

Very little. The module I mentioned enables nginx to read the contents
of these proxy certificates -- they contain an extension in the form
of an attribute certificate with authZ information -- because we want
to use it as a reverse proxy. We'll see how it goes.

> This approach may have problems with further nginx changes, but
> likely it will work good enough.

Good, thanks.

> For maximum compatibility, my recommendation would be to ask
> OpenSSL to introduce an openssl.cnf option, so you will be able to
> configure things via openssl.cnf.

I'll check that option as well.

Thanks again.

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