[openssl-dev] [openssl.org #4602] Missing accessors
Richard Levitte
levitte at openssl.org
Wed Aug 3 13:41:55 UTC 2016
In message <20160803131344.GB2380 at nikhef.nl> on Wed, 3 Aug 2016 15:13:44 +0200, Mischa Salle <msalle at nikhef.nl> said:
msalle> Hi Richard,
msalle>
msalle> apologies for the delayed answer, I was caught up in work...
msalle>
msalle> On Tue, Jul 26, 2016 at 05:50:14PM +0200, Richard Levitte wrote:
msalle> > msalle> Just for completeness, there are a number of things we need to verify or
msalle> > msalle> adapt by hand:
msalle> > msalle> - for non-RFC proxies, we need to be able to verify the issuer by hand
msalle> > msalle> and override the X509_check_issued(). For GT3 it could be that this is
msalle> > msalle> automatically solved by setting the EXFLAG_PROXY, I will need to check
msalle> > msalle> that, for legacy /GT2 it cannot be since we need to check for the
msalle> > msalle> /CN=proxy or /CN=limited proxy.
msalle> >
msalle> > You need to set the proxy path length as well for GT3. For GT2, the
msalle> > initial value -1 is exactly right.
msalle> >
msalle> > msalle> - for GT3 proxies we need to verify the pathlength constraint. If your
msalle> > msalle> pullrequest https://github.com/openssl/openssl/pull/1348 allows me to
msalle> > msalle> set a proxy pathlength constraint for a GT3 proxy which combined with
msalle> > msalle> the EXFLAG_PROXY would allow using standard verification, then that
msalle> > msalle> would probably indeed solve that problem too.
msalle> >
msalle> > That's what I'm hoping. Please try it out, for example by disabling
msalle> > these lines and seeing if what should verify does verify:
msalle> >
msalle> > https://github.com/globus/globus-toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L876-L884
msalle>
msalle> The problem with these two points is that I will still have to go
msalle> through the chain and set both the pathlength and the proxy flag for
msalle> each cert in case of GT3 proxies. In the end I've decided to leave this
msalle> part of at least my code as much as it is for now. At some point I will
msalle> try to rewrite it.
The better idea is to have globus_gsi_callback_check_issued() check
for GT2 and GT3 proxies and set the flag and pathlen accordingly.
Insert such code before calling X509_check_issued(), i.e. here:
https://github.com/globus/globus-toolkit/blob/globus_6_branch/gsi/callback/source/library/globus_gsi_callback.c#L582
That would be a much better use of CPU cycles and already existing
OpenSSL code. (also should work for pre-1.1 OpenSSLs)
msalle> By the way, even for RFC proxies I still have the problem that setting
msalle> the flag X509_V_FLAG_CRL_CHECK (and X509_V_FLAG_CRL_CHECK_ALL) to do CRL
msalle> checking results in a failure. I haven't looked yet what causes it, but
msalle> that flag should be ignored for proxy certificates in my opinion.
msalle> Perhaps I'm doing something wrong...?
I believe you've found a bug! Thanks.
msalle> > msalle> - for GT3 proxies we also need to be able to set (as you mention) the
msalle> > msalle> policy. I need to check that we have the necessary getters/setters for
msalle> > msalle> that now. I'll check with your new example.
msalle> >
msalle> > I've updated the example, it compiles. We don't have that in the ssl
msalle> > test any more (or well, we have it in pre-1.1 source), I'm thinking I
msalle> > should create a demo...
msalle>
msalle> I've managed to fix all *my* (that's not VOMS or Globus) code. That also
msalle> compiles and works again!
msalle>
msalle> > msalle> - The errata of the RFC specify actually 3 OIDs, also the
msalle> > msalle> id-ppl-anyLanguage / 1.3.6.1.5.5.7.21.0 which is not understood by
msalle> > msalle> OpenSSL. I don't think they are used in practice, but I like to have
msalle> > msalle> code to verify them.
msalle> >
msalle> > You can easily do that in verify_cb, per certificate. I think you
msalle> > already do? Also, I'm not sure what you mean with "not understood by
msalle> > OpenSSL", what is OpenSSL itself supposed to do with it?
msalle> Actually, upon looking again at the master branch, I agree that the
msalle> id-ppl-anyLanguage is there. I think I accidentally looked at your
msalle> example code, which doesn't have it in the switch(). Sorry for the noise.
Maybe the example should be expanded, although I've no idea why it
must care...
msalle> > msalle> More importantly however, in Grid, the so-called limited proxies with
msalle> > msalle> globus-owned OID 1.3.6.1.4.1.3536.1.1.1.9 are widely used, they
msalle> > msalle> indicate that the proxy may not be used for job submission, only for
msalle> > msalle> data access. So we need to have ways to verify that. For legacy/GT2
msalle> > msalle> this is indicated using /CN=limited proxy instead.
msalle> >
msalle> > 1.3.6.1.4.1.3536.1.1.1.9? That's a policy OID, right? OpenSSL leaves
msalle> > it entirely up to verify_cb to check these policies. That would
msalle> > correspond to the check_needed_rights() call at the bottom of
msalle> > doc/HOWTO/proxy_certificates.txt, right?
msalle>
msalle> Yes, it's a policy OID, same level as the other three.
msalle> I agree we can check them ourselves, but in order to check them, one
msalle> needs to go through the whole chain (a non-limited proxy is not allowed
msalle> to follow a limited proxy) and that's a tricky thing. In principle one
msalle> can do that with cert plus issuer-cert, which is available in the
msalle> callback, but that's not very efficient, which was my next point below.
I truly don't understand why you need to walk the chain every time
verify_cb is called.
msalle> > msalle> - Related to the previous point, the chain may not be built up from
msalle> > msalle> arbitrary language proxies: for example after a limited proxy, only
msalle> > msalle> limited proxies are allowed.
msalle> >
msalle> > That corresponds to the "rights" idea in
msalle> > doc/HOWTO/proxy_certificates.txt
msalle> >
msalle> > msalle> Also, we need to make sure that the chain is something like
msalle> > msalle> CA -> [ subCA ... -> ] EEC -> proxy [ -> proxy ... ]
msalle> > msalle> This can of course be done in a chain-local callback (cert+issuer).
msalle> >
msalle> > The OpenSSL code already ensures that, and works as long as the proxy
msalle> > certs are appropriately marked with X509_set_proxy_flag() beforehand
msalle> > (for example via the check_issued X509_STORE function for non-RFC
msalle> > proxies). If you look in crypto/x509/x509_vfy.c, check
msalle> > check_chain_extensions(). You may notice the variable 'must_be_ca',
msalle> > which is a tri-state, and controls what kind of cert is expected the
msalle> > next step "up".
msalle> >
msalle> > If you find a bug in that mechanism, we're interested!
msalle>
msalle> This indeed looks like the right way to go. I guess it would also be the
msalle> right place to make sure the proxy pathlength for GT3 proxies is being
msalle> set.
msalle>
msalle> I'm currently rather out of time, but will try to have a look at some
msalle> point how we can improve and simplify our code.
msalle>
msalle> Many thanks for the detailed instructions!
msalle>
msalle> Mischa
msalle>
msalle>
msalle> >
msalle> > msalle> > current_cert, current_issuer, etc are meant as input for verify_cb,
msalle> > msalle> > indicating which certificate in the chain the call of the callback is
msalle> > msalle> > about. Why one would need to tamper with them from inside the
msalle> > msalle> > verify_cb function escapes me...
msalle> > msalle> It's true that it's not really what you want to do *if* you can do
msalle> > msalle> local-only checks, but that's not possible for the pathlength constraint
msalle> > msalle> check (without keeping some global state or by manually setting the
msalle> > msalle> effective pathlength inside each cert), hence a renewed walking the
msalle> > msalle> chain is typically done upon reaching the last cert.
msalle> >
msalle> > Like I said, please check what OpenSSL does. There was a bug, so I
msalle> > perfectly understand why you needed to override that check. I've
msalle> > fixed what I found. If you find a bug in that mechanism, we're
msalle> > interested!
msalle> >
msalle> > --
msalle> > Richard Levitte levitte at openssl.org
msalle> > OpenSSL Project http://www.openssl.org/~levitte/
msalle>
msalle> --
msalle> Nikhef Room H155
msalle> Science Park 105 Tel. +31-20-592 5102
msalle> 1098 XG Amsterdam Fax +31-20-592 5155
msalle> The Netherlands Email msalle at nikhef.nl
msalle> __ .. ... _._. .... ._ ... ._ ._.. ._.. .._..
msalle>
More information about the openssl-dev
mailing list