Quantcast

OCSP stapling

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

OCSP stapling

Jeremy Harris
I'm working on an implementation of the client side of OCSP stapling.
To verify the stapled information I'm using the chain leading to the
server certificate, as presented in the (repeated) verify callbacks for
the server cert.

As far as I can see I need to do this because the client is only configured
with knowledge of the rootCA cert, not the signing cert for the server cert
(and OCSP stapling), and the signing chain is included in the server cert
info for the connection but not in the OCSP stapling.

Is this the correct overall approach?


The coding I have is:

   if (x509ctx->error_depth != 0)
     if (!X509_STORE_add_cert(x509ctx->ctx, x509ctx->current_cert))
       ERR_clear_error();   /* error expected for rootCA cert already in store */

Is this a legitimate thing to do?
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OCSP stapling

Jeremy Harris
On 02/09/2013 12:12 PM, Jeremy Harris wrote:
> I'm working on an implementation of the client side of OCSP stapling.
> To verify the stapled information I'm using the chain leading to the
> server certificate, as presented in the (repeated) verify callbacks for
> the server cert.

Despite the resounding lack of response I've moved to building
a fresh store, though still using the verify callbacks.  This is to
ensure that the exact CA chain used for the server cert is also
used for the stapling response verification.

Any screams of "you're doing it wrong" before this gets baked
in to a certain MTA?
--
Jeremy

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OCSP stapling

Dr. Stephen Henson
On Sat, Feb 16, 2013, Jeremy Harris wrote:

> On 02/09/2013 12:12 PM, Jeremy Harris wrote:
> >I'm working on an implementation of the client side of OCSP stapling.
> >To verify the stapled information I'm using the chain leading to the
> >server certificate, as presented in the (repeated) verify callbacks for
> >the server cert.
>
> Despite the resounding lack of response I've moved to building
> a fresh store, though still using the verify callbacks.  This is to
> ensure that the exact CA chain used for the server cert is also
> used for the stapling response verification.
>
> Any screams of "you're doing it wrong" before this gets baked
> in to a certain MTA?

There should be a way to get the verified chain back from the SSL structure
unfortunately you can't directly at present.

There are a couple of ways to handle this. If you look through
ssl_verify_cert_chain() you'll see you can pass a callback to handle the
complete verification operation and if this callback isn't defined it calls
X509_verify_cert() instead using similar arguments.

So you could supply an application defined callback that just calls
X509_verify_cert too which keeps the current behaviour. If that call is
successful you can then note the chain for future use using
X509_STORE_CTX_get1_chain().

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OCSP stapling

Jeremy Harris
On 02/16/2013 10:51 PM, Dr. Stephen Henson wrote:
> So you could supply an application defined callback that just calls
> X509_verify_cert too which keeps the current behaviour. If that call is
> successful you can then note the chain for future use using
> X509_STORE_CTX_get1_chain().

That's fine except that we're using SSL_CTX_set_verify() callback already
and the docs say it and SSL_CTX_set_cert_verify_callback() should not
be mixed.

Also, OCSP_basic_verify wants a store to verify using, it seems (by
experiment[1], given the lack of documentation).  So if I note the chain
from using X509_STORE_CTX_get1_chain() I'd have to unpack it
merely to build a store, which has little advantage...

[1] call it with a null store and it crashes.  Call it with the connection store
from SSL_CTX_get_cert_store(), and the chain as above for "certs", and it fails
with "unable to get local issuer certificate".
Call with null "certs" and a store built from the certs of the SSL_CTX_set_verify()
callbacks, it works.

--
Cheers,
     Jeremy
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OCSP stapling

Jeffrey Walton-3
On Sun, Feb 17, 2013 at 10:02 AM, Jeremy Harris <[hidden email]> wrote:

> On 02/16/2013 10:51 PM, Dr. Stephen Henson wrote:
>>
>> So you could supply an application defined callback that just calls
>> X509_verify_cert too which keeps the current behaviour. If that call is
>> successful you can then note the chain for future use using
>> X509_STORE_CTX_get1_chain().
>
>
> That's fine except that we're using SSL_CTX_set_verify() callback already
> and the docs say it and SSL_CTX_set_cert_verify_callback() should not
> be mixed.
Just my 2 cents, but I think that its language barrier confusion:

"Do not mix the verification callback described in this function with
the verify_callback function called during the verification process.
The latter is set using the SSL_CTX_set_verify(3) family of
functions."

I believe the warning is trying to tell you there are two callbacks,
and you should ensure you really want SSL_CTX_set_cert_verify_callback
rather than SSL_CTX_set_verify. I also don't read that they are
mutually exclusive.

Jeff
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OCSP stapling

Dr. Stephen Henson
In reply to this post by Jeremy Harris
On Sun, Feb 17, 2013, Jeremy Harris wrote:

> On 02/16/2013 10:51 PM, Dr. Stephen Henson wrote:
> >So you could supply an application defined callback that just calls
> >X509_verify_cert too which keeps the current behaviour. If that call is
> >successful you can then note the chain for future use using
> >X509_STORE_CTX_get1_chain().
>
> That's fine except that we're using SSL_CTX_set_verify() callback already
> and the docs say it and SSL_CTX_set_cert_verify_callback() should not
> be mixed.
>

That explanation could be clearer. In this case it's fine to mix the two.

In more detail...

If you set a callback with SSL_CTX_set_verify() it can completely take over
the whole verification operation and do things in a completely different way.
It has no obligation to honour the way the verify callback for the standard
verification routine X509_verify_cert() works so an application which replaces
both cani't rely on it behaving as they might expect.

In this specific example though the replacement for X509_verify_cert would
actually call X509_verify_cert and process the certificate chain after that
call. So it would retain the functionality of the original.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OCSP stapling

Jeremy Harris
On 18/02/2013 22:32, Dr. Stephen Henson wrote:
>> That's fine except that we're using SSL_CTX_set_verify() callback already
>> and the docs say it and SSL_CTX_set_cert_verify_callback() should not
>> be mixed.
>>
>
> That explanation could be clearer. In this case it's fine to mix the two.

OK, thankyou.  Now, about the need for a store for the OCSP verify?
--
Jeremy

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OCSP stapling

Dr. Stephen Henson
On Tue, Feb 19, 2013, Jeremy Harris wrote:

> On 18/02/2013 22:32, Dr. Stephen Henson wrote:
> >>That's fine except that we're using SSL_CTX_set_verify() callback already
> >>and the docs say it and SSL_CTX_set_cert_verify_callback() should not
> >>be mixed.
> >>
> >
> >That explanation could be clearer. In this case it's fine to mix the two.
>
> OK, thankyou.  Now, about the need for a store for the OCSP verify?

You can disable verification altogether with the OCSP_NOVERIFY flag to
OCSP_basic_verify, it should then never reference the passed store and it can
be NULL.

That's fine if the OCSP response has been signed by a CA in the
server certificate chain as that chain has already been verified. If you have
a delegated signing certificate, or one from a different chain that is trusted
implicitly then you still need to verify the chain.

This is a bit messy but one way I can think of to handle this is something
like this:

Retrieve the server certificate chain (i.e. the unverified one received by
client) using SSL_get_peer_cert_chain.

Add each certificate in the peer chain to the OCSP_BASICRESP structure using
OCSP_basic_add1_cert().

Pass the same X509_STORE you used to verify the server chain to
OCSP_basic_resp().

What that should then do is attempt to verify the responder certificate using
all the certificates sent by the server and in the OCSP response as untrusted
CAs.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: OCSP stapling

Jeremy Harris
On 02/19/2013 02:33 PM, Dr. Stephen Henson wrote:

> On Tue, Feb 19, 2013, Jeremy Harris wrote:
>
>> On 18/02/2013 22:32, Dr. Stephen Henson wrote:
>>>> That's fine except that we're using SSL_CTX_set_verify() callback already
>>>> and the docs say it and SSL_CTX_set_cert_verify_callback() should not
>>>> be mixed.
>>>>
>>>
>>> That explanation could be clearer. In this case it's fine to mix the two.
>>
>> OK, thankyou.  Now, about the need for a store for the OCSP verify?
>
> You can disable verification altogether with the OCSP_NOVERIFY flag to
> OCSP_basic_verify, it should then never reference the passed store and it can
> be NULL.
>
> That's fine if the OCSP response has been signed by a CA in the
> server certificate chain as that chain has already been verified.

(which last is a requirement of the Stapling RFC, if I understand)

So I'm still confused.   What does OCSP_NOVERIFY disable and what
remains?   If it stops the checking of the signing chain of the stapling,
how is the case of a subverted server, which has a valid-but-revoked certificate,
handled?   It would seem that my client would successfully verify the
original server certificate and the content of stapling (invented by the now
malicious server to claim that the server certificate is still valid).

--
Thanks,
     Jeremy

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Loading...