[openssl-dev] [openssl.org #4602] Missing accessors

[Richard Levitte via RT]

I guess having a more restrictive accessor that only sets the
EXFLAG_PROXY bit could work. I suggested the more general solution
of
having set/clear accessors for arbitrary flags since it was - well
more
general.

So let me ask this in a different manner, does OpenSSL 1.1 still not
set the
EXFLAG_PROXY flag correctly? In what situations does that happen?
That may be
worth a bug report of its own.
--
Richard Levitte

The answer to this is related to Mischa's reply, which unfortunately
was only sent to the Debian BTS and not the the OpenSSL RT. I quote it
below. As indicated in the answer, setting the EXFLAG_PROXY allows
handling non-RFC proxies in OpenSSL.

Hi Richard, Mattias, others,
I agree with you that it would be nice if OpenSSL could figure out
itself whether a cert needs to be treated as a proxy, but currently
that
doesn't work reliably as far as I know.
The flag is certainly needed in the case of non-RFC3820 proxies, also
known as legacy proxies. Unfortunately these are still very widely
used
(majority of the proxies actually) and hence our code must be able to
handle them correctly.
Best wishes,
Mischa Sallé

Ok... From looking at the voms code that was linked to earlier, I can see that
legacy proxy certs are recognised by an older OID (called PROXYCERTINFO_V3 in
the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions in that
version, whether they are critical or not and so on, that I can reach? Or is
the OID the only actual difference? If it's easy enough (and it currently does
look quite easy), I can certainly see adding some code in OpenSSL to recognise
those...

--
Richard Levitte
***@openssl.org

[David Woodhouse]

(Dropping the Debian bug from Cc)

I was using store.get_issuer() in OpenConnect too, because I need to
manually build the trust chain to include it on the wire — because
even today the server might *still* suffer RT#1942 and fail to trust
our client cert unless we help it by providing the *right* chain.

Is this still true with OpenSSL 1.1? If so, please file a report.

No, I fixed it years ago in OpenSSL. But it took many years for Cisco
to actually start *using* a fixed version of OpenSSL.

So we still try really hard, on the client side, to put the *right*
intermediate CAs on the wire if we can find them. Because that way it
doesn't matter so much if the server can't.

I've worked around the lack of access to get_issuer() by doing a dummy
call to X509_verify_cert(), throwing away its result and then hoping
that we have something useful in store.chain (which we *can* still
access). That seems to work but I'm not stunningly happy with it; if
we
can have an accessor I'd much rather go back to doing it the old way.
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
(in workaround_openssl_certchain_bug() in the hunk around line 1306)

https://github.com/openssl/openssl/pull/1294 currently provides a setter for
get_issuer in X509_STORE.

OK, thanks. Once it lands, I may go back to using that.

[David Woodhouse via RT]

(Dropping the Debian bug from Cc)

I was using store.get_issuer() in OpenConnect too, because I need to
manually build the trust chain to include it on the wire — because
even today the server might *still* suffer RT#1942 and fail to trust
our client cert unless we help it by providing the *right* chain.

Is this still true with OpenSSL 1.1? If so, please file a report.

No, I fixed it years ago in OpenSSL. But it took many years for Cisco
to actually start *using* a fixed version of OpenSSL.

So we still try really hard, on the client side, to put the *right*
intermediate CAs on the wire if we can find them. Because that way it
doesn't matter so much if the server can't.

I've worked around the lack of access to get_issuer() by doing a dummy
call to X509_verify_cert(), throwing away its result and then hoping
that we have something useful in store.chain (which we *can* still
access). That seems to work but I'm not stunningly happy with it; if
we
can have an accessor I'd much rather go back to doing it the old way.
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/0d635a0
(in workaround_openssl_certchain_bug() in the hunk around line 1306)

https://github.com/openssl/openssl/pull/1294 currently provides a setter for
get_issuer in X509_STORE.

OK, thanks. Once it lands, I may go back to using that.

[Mattias Ellert via RT]

Post by Richard Levitte via RT

I guess having a more restrictive accessor that only sets the
EXFLAG_PROXY bit could work. I suggested the more general
solution
of
having set/clear accessors for arbitrary flags since it was -
well
more
general.

So let me ask this in a different manner, does OpenSSL 1.1 still
not
set the
EXFLAG_PROXY flag correctly? In what situations does that happen?
That may be
worth a bug report of its own.
--
Richard Levitte

The answer to this is related to Mischa's reply, which
unfortunately
was only sent to the Debian BTS and not the the OpenSSL RT. I quote
it
below. As indicated in the answer, setting the EXFLAG_PROXY allows
handling non-RFC proxies in OpenSSL.

Hi Richard, Mattias, others,
I agree with you that it would be nice if OpenSSL could figure
out
itself whether a cert needs to be treated as a proxy, but
currently
that
doesn't work reliably as far as I know.
The flag is certainly needed in the case of non-RFC3820 proxies,
also
known as legacy proxies. Unfortunately these are still very
widely
used
(majority of the proxies actually) and hence our code must be
able to
handle them correctly.
Best wishes,
Mischa Sallé

Ok... From looking at the voms code that was linked to earlier, I can
see that
legacy proxy certs are recognised by an older OID (called
PROXYCERTINFO_V3 in
the code), 1.3.6.1.4.1.3536.1.222. Is there a spec for the extensions
in that
version, whether they are critical or not and so on, that I can
reach? Or is
the OID the only actual difference? If it's easy enough (and it
currently does
look quite easy), I can certainly see adding some code in OpenSSL to
recognise
those...
--
Richard Levitte

As far as I know there are three different kinds of proxies, usually
called "legacy", "draft" and "rfc", or sometimes version 2, 3 and 4
respectively.

For example see "grid-proxy-init -help":

    -draft                    Creates a draft (GSI-3) proxy
    -old                      Creates a legacy globus proxy
    -rfc                      Creates a RFC 3820 compliant proxy

The really tricky one is the old legacy version 2 proxy I think.

Mattias