[openssl.org #4602] Missing accessors

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[openssl.org #4602] Missing accessors

Rich Salz via RT
On Sat Jul 02 10:59:38 2016, [hidden email] wrote:

> /* Add to include/openssl/x509v3.h */
>
> void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
>
>
> /* Add to crypto/x509v3/v3_purp.c */
>
> void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> {
> x->ex_flags |= ex_flags;
> }
>
> void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> {
> x->ex_flags &= ~ex_flags;
> }

This gives me the heebie jeebies. ex_flags is used a lot internally, and I
can't begin to imagine the consequences of letting external code manipulate
this. I understand that in some cases, it seems easy and quick, but...

So, if someone else wants to have a go at this and can make something sensible,
please be my guest. Me, I'm backing off from this particular idea.

Cheers,
Richard

--
Richard Levitte
[hidden email]

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

Rich Salz via RT
I think we should ask kurt to ask the original reporter what they need to do.


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

Kurt Roeckx
In reply to this post by Rich Salz via RT
On Thu, Jul 07, 2016 at 09:40:24PM +0000, Richard Levitte via RT wrote:

> On Sat Jul 02 10:59:38 2016, [hidden email] wrote:
> > /* Add to include/openssl/x509v3.h */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> >
> >
> > /* Add to crypto/x509v3/v3_purp.c */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags |= ex_flags;
> > }
> >
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags &= ~ex_flags;
> > }
>
> This gives me the heebie jeebies. ex_flags is used a lot internally, and I
> can't begin to imagine the consequences of letting external code manipulate
> this. I understand that in some cases, it seems easy and quick, but...
>
> So, if someone else wants to have a go at this and can make something sensible,
> please be my guest. Me, I'm backing off from this particular idea.

Mattias,

Can you explain why this is needed, what the code is trying to do?


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

Rich Salz via RT
On Thu, Jul 07, 2016 at 09:40:24PM +0000, Richard Levitte via RT wrote:

> On Sat Jul 02 10:59:38 2016, [hidden email] wrote:
> > /* Add to include/openssl/x509v3.h */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> >
> >
> > /* Add to crypto/x509v3/v3_purp.c */
> >
> > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags |= ex_flags;
> > }
> >
> > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > {
> > x->ex_flags &= ~ex_flags;
> > }
>
> This gives me the heebie jeebies. ex_flags is used a lot internally, and I
> can't begin to imagine the consequences of letting external code manipulate
> this. I understand that in some cases, it seems easy and quick, but...
>
> So, if someone else wants to have a go at this and can make something sensible,
> please be my guest. Me, I'm backing off from this particular idea.

Mattias,

Can you explain why this is needed, what the code is trying to do?


Kurt


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

Rich Salz via RT
In reply to this post by Kurt Roeckx
fre 2016-07-08 klockan 00:42 +0200 skrev Kurt Roeckx:

> On Thu, Jul 07, 2016 at 09:40:24PM +0000, Richard Levitte via RT
> wrote:
> > On Sat Jul 02 10:59:38 2016, [hidden email] wrote:
> > > /* Add to include/openssl/x509v3.h */
> > >
> > > void X509_set_extension_flags(X509 *x, uint32_t ex_flags);
> > > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags);
> > >
> > >
> > > /* Add to crypto/x509v3/v3_purp.c */
> > >
> > > void X509_set_extension_flags(X509 *x, uint32_t ex_flags)
> > > {
> > > x->ex_flags |= ex_flags;
> > > }
> > >
> > > void X509_clear_extension_flags(X509 *x, uint32_t ex_flags)
> > > {
> > > x->ex_flags &= ~ex_flags;
> > > }
> >
> > This gives me the heebie jeebies. ex_flags is used a lot
> > internally, and I
> > can't begin to imagine the consequences of letting external code
> > manipulate
> > this. I understand that in some cases, it seems easy and quick,
> > but...
> >
> > So, if someone else wants to have a go at this and can make
> > something sensible,
> > please be my guest. Me, I'm backing off from this particular idea.
>
> Mattias,
>
> Can you explain why this is needed, what the code is trying to do?
>
>
> Kurt
>
Hi!

The modification of the extension flags happens in at least four
different packages. The modification they do is to add the EXFLAG_PROXY
bit to the flags.

https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L692

https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1665
https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1740

https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1655
https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1719

https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L184

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.

        Mattias Ellert

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[openssl.org #4602] Missing accessors

Rich Salz via RT
In reply to this post by Kurt Roeckx
On Mon Jul 11 11:34:35 2016, [hidden email] wrote:

> fre 2016-07-08 klockan 00:42 +0200 skrev Kurt Roeckx:
> > Mattias,
> >
> > Can you explain why this is needed, what the code is trying to do?
> >
> >
> > Kurt
> >
>
> Hi!
>
> The modification of the extension flags happens in at least four
> different packages. The modification they do is to add the
> EXFLAG_PROXY
> bit to the flags.

Ok, I just had a look:

>
https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L692

This looks like an old workaround, and I wonder if it's really needed any more.
If it's still needed, I'd say this may uncover a bug within OpenSSL, but in
that case, I'd rather fix that in 1.1

> https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1665
> https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1740

I see what this code does, it makes a name constraint check that should have
been present in OpenSSL but wasn't... until 1.1. However, there's other stuff
in that function that looks odd..

> https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1655
> https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1719

This is the same code as the voms you pointed at above.

>
https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L184

This is the same code as the globus-gsi-callback pointer above.

> 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.

Mm, I'm really unsure about this one. ex_flags is part of a cache of
information that OpenSSL fiddles with whenever it checks the extensions for a
certificate. Calling anything that ends up calling X509_check_issued(),
X509_check_ca() or X509_check_purpose() will cause values to be checked and
cached for the certificates involved in the call of those functions. In the
proxy certificate case, EXFLAG_PROXY will be set for a certificate any time the
proxyCertInfo is found among its extensions.

To be blunt, I would much rather see a bug report that shows when that cache
isn't being built properly, and possibly a fix for it.

Cheers,
Richard

--
Richard Levitte
[hidden email]

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

Rich Salz via RT
fre 2016-07-08 klockan 06:08 +0000 skrev Richard Levitte via RT:

> On Thu Jul 07 21:29:09 2016, levitte wrote:
> > On Sat Jul 02 10:59:38 2016, [hidden email] wrote:
> > > /* Add to include/openssl/x509_vfy.h : */
> > >
> > > typedef int (*X509_STORE_CTX_get_issuer)(X509 **issuer,
> > > X509_STORE_CTX
> > > *ctx, X509 *x);
> > > typedef int (*X509_STORE_CTX_check_issued)(X509_STORE_CTX *ctx,
> > > X509
> > > *x, X509 *issuer);
> > >
> > > void X509_STORE_CTX_set_get_issuer(X509_STORE_CTX *ctx,
> > > X509_STORE_CTX_get_issuer
> > > get_issuer);
> > > X509_STORE_CTX_get_issuer
> > > X509_STORE_CTX_get_get_issuer(X509_STORE_CTX
> > > *ctx);
> > > void X509_STORE_CTX_set_check_issued(X509_STORE_CTX *ctx,
> > > X509_STORE_CTX_check_issued
> > > check_issued);
> > > X509_STORE_CTX_check_issued
> > > X509_STORE_CTX_get_check_issued(X509_STORE_CTX *ctx);
> >
> > For this part, https://github.com/openssl/openssl/pull/1294
>
> So, looking at this again after some sleep, there's a part of this
> solution
> that I'm unsure of, and it all comes back to X509_STORE_CTX_init(),
> where the
> X509_STORE context gets initialised from the X509_STORE, including
> all the
> function pointers. This has me wonder if the X509_STORE_CTX setters
> should
> really be made available (perhaps with the exception of the verify
> and
> verify_cb ones). Doesn't it make more sense to set those function
> pointers when
> creating the X509_STORE itself? Why would those functions need to be
> changed in
> the context?
>
> Cheers,
> Richard
>
> --
> Richard Levitte
> [hidden email]
>
Looking at the various places in the code where get_issuer
and check_issued are accessed, they mostly use the context rather than
the store. Here are the places I have found:

https://sources.debian.net/src/nordugrid-arc/5.1.2-1/src/hed/libs/credential/CertUtil.cpp/#L71

https://sources.debian.net/src/canl-c/2.1.6-2/src/proxy/sslutils.c/#L1581

https://sources.debian.net/src/voms/2.0.13-1/src/sslutils/sslutils.c/#L1588

https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L367

https://sources.debian.net/src/globus-gsi-callback/5.8-2/library/globus_gsi_callback.c/#L1059

https://sources.debian.net/src/globus-gsi-credential/7.9-2/library/globus_gsi_cred_handle.c/#L1997

And the following one actually uses the store and not the context:

https://sources.debian.net/src/globus-gssapi-gsi/12.1-1/library/globus_i_gsi_gss_utils.c/#L448

        Mattias


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

David Woodhouse-7
On Mon, 2016-07-11 at 13:08 +0000, Mattias Ellert via RT wrote:
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.

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)


--
dwmw2
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

Rich Salz via RT
On Mon, 2016-07-11 at 13:08 +0000, Mattias Ellert via RT wrote:
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.

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)


--
dwmw2


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

[openssl.org #4602] Missing accessors

Rich Salz via RT
In reply to this post by David Woodhouse-7
On Mon Jul 11 14:04:22 2016, [hidden email] wrote:
> 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.

> 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.

--
Richard Levitte
[hidden email]

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

[openssl.org #4602] Missing accessors

Rich Salz via RT
In reply to this post by Kurt Roeckx
On Mon Jul 11 11:34:35 2016, [hidden email] wrote:
> 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
[hidden email]

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

Jan Just Keijser-2
Hi Richard,

On 20/07/16 17:14, Richard Levitte via RT wrote:

> On Mon Jul 11 11:34:35 2016, [hidden email] wrote:
>> 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.
>
this ties into my earlier question and example of verifying proxy
certificates. What if I want to explicitly *set* the EXFLAG_PROXY for a
stack of certificates? how would I do that? how can I ensure that
OpenSSL 1.1 will automagically trigger this flag for me? Is there a
'get_*' function to determine which flags were set during certificate
verification?

thanks for any pointers or advice,

JJK / Jan Just Keijser


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

Rich Salz via RT
Hi Richard,

On 20/07/16 17:14, Richard Levitte via RT wrote:

> On Mon Jul 11 11:34:35 2016, [hidden email] wrote:
>> 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.
>
this ties into my earlier question and example of verifying proxy
certificates. What if I want to explicitly *set* the EXFLAG_PROXY for a
stack of certificates? how would I do that? how can I ensure that
OpenSSL 1.1 will automagically trigger this flag for me? Is there a
'get_*' function to determine which flags were set during certificate
verification?

thanks for any pointers or advice,

JJK / Jan Just Keijser



--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

[openssl.org #4602] Missing accessors

Rich Salz via RT
In reply to this post by Jan Just Keijser-2
On Wed Jul 20 16:58:20 2016, [hidden email] wrote:

> Hi Richard,
>
> On 20/07/16 17:14, Richard Levitte via RT wrote:
> > On Mon Jul 11 11:34:35 2016, [hidden email] wrote:
> >> 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.
> >
> this ties into my earlier question and example of verifying proxy
> certificates. What if I want to explicitly *set* the EXFLAG_PROXY for
> a
> stack of certificates?

I assume you only want that flag set for actual proxy certs a no other. If you
simply want to make sure the certs in a stack are properly flagged by OpenSSL,
call X509_check_purpose for each of them.

> how would I do that? how can I ensure that
> OpenSSL 1.1 will automagically trigger this flag for me? Is there a
> 'get_*' function to determine which flags were set during certificate
> verification?
>
> thanks for any pointers or advice,

The function to retrieve the extension flags is X509_get_extension_flags(). You
call that for each X509*.
Incidently, this function calls X509_check_purpose to make sure the caches are
properly built up...

--
Richard Levitte
[hidden email]

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

Rich Salz via RT
In reply to this post by Rich Salz via RT
ons 2016-07-20 klockan 15:14 +0000 skrev Richard Levitte via RT:

> On Mon Jul 11 11:34:35 2016, [hidden email] wrote:
> >
> > 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
> [hidden email]
>
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.

mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:

> 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é
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[openssl.org #4602] Missing accessors

Rich Salz via RT
In reply to this post by Rich Salz via RT
On Thu Jul 21 08:18:30 2016, [hidden email] wrote:

> ons 2016-07-20 klockan 15:14 +0000 skrev Richard Levitte via RT:
> > On Mon Jul 11 11:34:35 2016, [hidden email] wrote:
> > >
> > > 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
> > [hidden email]
> >
>
> 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.
>
> mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > 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
[hidden email]

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

David Woodhouse-7
In reply to this post by Rich Salz via RT
(Dropping the Debian bug from Cc)

On Wed, 2016-07-20 at 15:11 +0000, Richard Levitte via RT wrote:
> On Mon Jul 11 14:04:22 2016, [hidden email] wrote:
> > 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.

--
dwmw2
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

Rich Salz via RT
(Dropping the Debian bug from Cc)

On Wed, 2016-07-20 at 15:11 +0000, Richard Levitte via RT wrote:
> On Mon Jul 11 14:04:22 2016, [hidden email] wrote:
> > 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.

--
dwmw2
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

Rich Salz via RT
In reply to this post by Rich Salz via RT
tor 2016-07-21 klockan 09:51 +0000 skrev Richard Levitte via RT:

> On Thu Jul 21 08:18:30 2016, [hidden email] wrote:
> >
> > ons 2016-07-20 klockan 15:14 +0000 skrev Richard Levitte via RT:
> > >
> > > On Mon Jul 11 11:34:35 2016, [hidden email] wrote:
> > > >
> > > >
> > > > 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
> > > [hidden email]
> > >
> >
> > 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.
> >
> > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > >
> > > 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
> [hidden email]
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

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #4602] Missing accessors

Rich Salz via RT
In reply to this post by Rich Salz via RT
On Fri, Jul 22, 2016 at 09:38:13AM +0200, Mattias Ellert wrote:

> tor 2016-07-21 klockan 09:51 +0000 skrev Richard Levitte via RT:
> > On Thu Jul 21 08:18:30 2016, [hidden email] wrote:
> > >
> > > ons 2016-07-20 klockan 15:14 +0000 skrev Richard Levitte via RT:
> > > >
> > > > On Mon Jul 11 11:34:35 2016, [hidden email] wrote:
> > > > >
> > > > >
> > > > > 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
> > > > [hidden email]
> > > >
> > >
> > > 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.
> > >
> > > mån 2016-07-11 klockan 14:53 +0200 skrev Mischa Salle:
> > > >
> > > > 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
> > [hidden email]
>
> 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.
Hi,

there are 3 types of proxies, in chronological order:

- so called legacy proxies, which voms-proxy-init will call old and are
  also known as GT2 proxies.
  They have no special (critical) extension and can be recognized by:
    1) being signed by an end-entity cert (i.e. a non-CA)
    2) have the same subjectDN as the issuer with one extra CN RDN
       added, which can be either
        a) "CN=proxy" for a 'inherit all' proxy
        b) "CN=limited proxy" for a limited proxy (as in OID
           1.3.6.1.4.1.3536.1.1.1.9)
  These are widely used and we have therefore code in many places to
  handle them.

- the draft RFC proxies, also known as GT3 proxies.
  They contain an extension 1.3.6.1.4.1.3536.1.222
  At least voms-proxy-init does not mark it as critical. They are
  rarely used. The ordering in the extension is different in the sense
  that they usually put the proxyPolicy before the proxyPathlength (when
  finite, i.e. present) inside the extension, but RFC-style extensions
  also occur. In openssl.cnf style a GT3 extension would be something
  like this:
    [ gt3_proxy ]
    keyUsage = critical,digitalSignature,keyEncipherment
    1.3.6.1.4.1.3536.1.222=critical,ASN1:SEQUENCE:gt3_seq_sect

    # For a proxy pathlength of 42, leave out field2 for inf.
    [ gt3_seq_sect ]
    field1 = SEQUENCE:normal_policy
    field2 = EXPLICIT:1C,INTEGER:42

    # similarly for limited policy
    [ normal_policy ]
    p1 = OID:1.3.6.1.5.5.7.21.1

- RFC3820 compliant proxies, also known as GT4 proxies.
  They contain the standard critical extension 1.3.6.1.5.5.7.1.14

The default for at least voms-proxy-init (both from the voms-clients2
and voms-clients3) is to make the GT2 proxies, and this is why they are
still very-widely used (I think vast majority of proxies).

    Mischa
--
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email [hidden email]
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4602
Please log in as guest with password guest if prompted


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

smime.p7s (4K) Download Attachment