Re: FW: SSL OCSP Stapling

[Julien Vehent]

Firefox will most likely move to OCSP stapling only in the next 3 to 6 
months. Classic OCSP is too slow, and too error prone.


We've been working with Riverbed to deploy OCSP Stapling on Stingray 
(formally Zeus) load balancer. They have a solid implementation that can 
be used as a reference. I'd love to see OCSP Stapling in HAProxy, 
because that's a big performance win, but I don't know how hard it would 
be to implement. However, I know a few people in the Firefox security 
team who would be happy to help with design & QA (myself included).


Here's a sample OCSP response from one of our site:

$ openssl s_client -connect monitor.mozillalabs.com:443 -status

CONNECTED(0003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = "GeoTrust, Inc.", CN = GeoTrust SSL CA
verify return:1
depth=0 serialNumber = 8DZwltU1cw7OP-08XVgEwK/bh8Icw4zX, C = US, ST = 
California, L = Mountain View, O = Mozilla Corporation, OU = Mozilla 
Labs, CN = *.mozillalabs.com

verify return:1
OCSP response:
==
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: C = US, O = "GeoTrust, Inc.", CN = GeoTrust SSL 
OCSP-TGV Responder

Produced At: Feb 22 10:39:04 2014 GMT
Responses:
Certificate ID:
  Hash Algorithm: sha1
  Issuer Name Hash: 3F9B7E858F6044D7D54161744EEB6CEB808629D2
  Issuer Key Hash: 4279541B61CD552B3E63D53C4857F59FFB45CE4A
  Serial Number: 02567C
Cert Status: good
This Update: Feb 22 10:39:04 2014 GMT
Next Update: Mar  1 10:39:04 2014 GMT

Signature Algorithm: sha1WithRSAEncryption
 24:f6:68:ec:e9:f5:17:f9:4e:b6:f5:eb:92:4e:16:94:3e:38:
 5b:69:c8:24:85:28:71:0f:06:2d:03:a2:15:89:87:ca:e9:fb:
 91:9b:ca:9a:ca:b8:2f:f3:dc:a1:d3:e5:3c:53:ec:c7:5b:ac:
 ad:17:c0:0c:00:a1:8f:b6:85:b3:6d:a7:f2:f0:94:4f:e3:44:
 a2:01:59:f6:43:22:a5:f7:22:2d:dd:5e:ec:0f:9f:94:57:31:
 13:f3:f8:eb:62:42:89:12:93:59:83:b4:91:cb:4d:a3:b4:6e:
 04:09:13:89:0f:e2:b8:07:14:0c:49:d3:14:08:41:8c:01:49:
 a9:69:56:33:c7:d1:38:ba:2d:98:f8:82:79:98:a6:be:b5:77:
 90:2d:ca:53:41:7a:c1:14:69:42:99:cc:44:a2:3f:91:b9:c9:
 f9:ef:59:27:15:cf:82:c4:2f:da:e5:b2:94:fa:e6:e6:33:bf:
 73:97:8d:79:c6:25:54:93:22:ec:ad:2d:0e:43:6f:c3:e3:dc:
 8f:4e:2e:96:3f:9c:c3:fe:1b:db:d0:9f:f3:61:cc:6d:93:a8:
 70:93:6f:a7:d6:57:f3:3a:2b:5f:fb:03:01:cc:c3:14:62:04:
 b4:d6:35:bb:18:60:13:fc:cd:af:c4:34:8e:52:85:d6:1c:ca:
 57:9f:b9:bb
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 148819 (0x24553)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=GeoTrust, Inc., CN=GeoTrust SSL CA
Validity
Not Before: May 28 17:35:51 2013 GMT
Not After : May 27 17:35:51 2014 GMT
Subject: C=US, O=GeoTrust, Inc., CN=GeoTrust SSL OCSP-TGV 
Responder

Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b2:c0:91:c8:08:2b:a5:d8:17:2b:28:d3:bc:ef:
b7:2b:8d:ba:00:7e:40:e9:47:7c:30:81:9a:d3:3e:
0d:0f:70:a8:a8:ea:2e:2c:c9:69:6c:e4:1c:bd:cc:
b5:84:98:e6:f0:ae:01:2b:c1:75:96:00:83:96:70:
a4:43:3f:3c:06:fb:06:c1:d5:28:1f:1e:53:62:87:
26:2d:a1:96:c8:50:6d:17:ca:bc:fb:22:2c:ef:9b:
36:12:37:a0:ca:2a:12:03:12:52:eb:f7:fc:b6:88:
ee:d4:24:25:8b:98:80:0b:42:a1:01:c9:ec:a3:9c:
7b:d1:d1:63:10:43:86:db:a4:8b:0e:8e:d3:52:55:
55:9d:b2:e5:19:d5:0a:c2:23:52:51:6c:86:17:79:
c8:b2:39:99:d5:e3:70:40:f7:30:d2:27:ed:c6:7f:
82:95:8b:3e:d1:08:f1:4c:75:2c:3e:f4:9b:96:d5:
85:7d:c5:02:2f:21:a9:63:83:27:75:bd:e2:e3:28:
da:ae:a4:c0:6d:39:2e:92:3b:7a:b3:35:81:2d:37:
89:e4:6c:6d:53:2a:e0:63:b6:22:70:67:dd:6d:07:
93:48:50:62:06:4d:bb:47:0d:b2:b9:4b:6a:bd:1c:
28:b2:b0:a7:46:6b:f8:d7:74:a1:5d:2c:6b:41:95:
dc:75
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:

keyid:42:79:54:1B:61:CD:55:2B:3E:63:D5:3C:48:57:F5:9F:FB:45:CE:4A


OCSP No Check:

X509v3 Extended Key Usage:
OCSP Signing
X509v3 Key Usage: critical
Digital Signature
X509v3 Subject Alternative Name:
DirName:/CN=2048-TGV-333
Signature Algorithm: sha1WithRSAEncryption
 30:0c:30:4e:a2:e8:8d:68:88:f9:93:41:6c:3e:4b:19:ef:42:
 23:72:fe:64:81:21:ad:5c:1a:51:62:f7:9a:2c:f8:ad:85:b5:
 49:c3:ad:0f:b8:70:41:fd:1d:db:18:68:9c:8f:64:4e:f1:18:

Re: FW: SSL OCSP Stapling

[Hervé COMMOWICK]

Oh and Thawte released a whitepaper about that :
http://www.thawte.com/assets/documents/whitepaper/ocsp-stapling.pdf

Hervé.

On 01/31/2014 03:18 PM, Hervé COMMOWICK wrote:
> Hello,
> 
> Just to move this subject back up, 2 links about OCSP stapling :
> - https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
> -
> http://news.netcraft.com/archives/2013/07/19/microsoft-achieves-world-domination-in-ocsp-stapling.html
> 
> In short, support on client and server side is clearly increasing but
> the main goal is not reached, as OCSP remains necessary for intermediate
> certificate.
> 
> A new RFC has been wrote to handle those remaining case :
> http://tools.ietf.org/html/rfc6961
> 
> Hervé.
> 
> On 11/06/2012 11:08 PM, Willy Tarreau wrote:
>>> I would say the periodic-request aspect of it is pretty trivial; you add a
>>> timer to the event loop that expires in some configurable amount of time,
>>> e.g. a bit before the last OCSP response expires, and you cache the result
>>> until it expires or a more recent result overwrites it. Given that the
>>> overhead of making a single OCSP request for the cert inside HAProxy is very
>>> low, you can easily do this every few minutes with no perceivable overhead.
>>> Obviously some logic re: failing requests and retrying has to be 
>>> implemented,
>>> which amounts to nothing more than a formulation for how much time to wait
>>> until retrying again.
>>
>> I confirm that this part it clearly nothing.
>>
>>> The user should also be able to configure whether to
>>> deliver an expired OCSP response or none at all in the case that an upstream
>>> OCSP response cannot be received by the time the currently cached response
>>> expires.
>>
>> That's one of the points of attention, I agree.
>>
>>> A single timer and single cache slot are used for each certificate chain. 
>>> The
>>> timer is reset with a new value when:
>>> - a request fails; in this case we need
>>>   to use our retry/backoff algorithm to decide how long to wait before
>>>   retrying;
>>> - a request succeeds; in this case we need to use our expires algorithm,
>>>   which can be parameterized over the expiration time of the OCSP response, 
>>> to
>>>   decide how long to wait before trying to get a fresh response.
>>
>> Hmmm OK it's per certificate... Obviously in fact. So that probably means
>> some funny mechanisms to connect to various places depending on the cert
>> chain (eg: for those connecting via proxies, etc...).
>>
>>> One thing to keep in mind is that OCSP stapling in many libraries has (or
>>> had, at one point) buggy or nonexistent support for OCSP payloads containing
>>> multiple certificates,
>>
>> That's a very useful and interesting piece of information.
>>
>>> and a bit of research should be done prior to
>>> implementation to discover the current state of the world in this regard.
>>
>> I agree!
>>
>>> I believe the official word at one point was that OCSP stapling of chains
>>> should be accomplished by including the entire chain in the OCSP request,
>>> delivering that compound OCSP response via the TLS Certificate Status 
>>> Request
>>> extension.
>>
>> And do you know how large this could be for average web sites ? Maybe
>> there is a cross-over point where doing so has a more negative impact
>> than letting the client check by itself ?
>>
>> Thanks for your comments and suggestions!
>> Willy
>>
>>
> 

-- 
Hervé COMMOWICK
Ingénieur systèmes et réseaux.

http://www.rezulteo.com
by Lizeo Online Media Group 
42 quai Rambaud - 69002 Lyon (France) ⎮ ☎ +33 (0)4 26 99 03 77

Re: FW: SSL OCSP Stapling

[Hervé COMMOWICK]

Hello,

Just to move this subject back up, 2 links about OCSP stapling :
- https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
-
http://news.netcraft.com/archives/2013/07/19/microsoft-achieves-world-domination-in-ocsp-stapling.html

In short, support on client and server side is clearly increasing but
the main goal is not reached, as OCSP remains necessary for intermediate
certificate.

A new RFC has been wrote to handle those remaining case :
http://tools.ietf.org/html/rfc6961

Hervé.

On 11/06/2012 11:08 PM, Willy Tarreau wrote:
>> I would say the periodic-request aspect of it is pretty trivial; you add a
>> timer to the event loop that expires in some configurable amount of time,
>> e.g. a bit before the last OCSP response expires, and you cache the result
>> until it expires or a more recent result overwrites it. Given that the
>> overhead of making a single OCSP request for the cert inside HAProxy is very
>> low, you can easily do this every few minutes with no perceivable overhead.
>> Obviously some logic re: failing requests and retrying has to be implemented,
>> which amounts to nothing more than a formulation for how much time to wait
>> until retrying again.
> 
> I confirm that this part it clearly nothing.
> 
>> The user should also be able to configure whether to
>> deliver an expired OCSP response or none at all in the case that an upstream
>> OCSP response cannot be received by the time the currently cached response
>> expires.
> 
> That's one of the points of attention, I agree.
> 
>> A single timer and single cache slot are used for each certificate chain. The
>> timer is reset with a new value when:
>> - a request fails; in this case we need
>>   to use our retry/backoff algorithm to decide how long to wait before
>>   retrying;
>> - a request succeeds; in this case we need to use our expires algorithm,
>>   which can be parameterized over the expiration time of the OCSP response, 
>> to
>>   decide how long to wait before trying to get a fresh response.
> 
> Hmmm OK it's per certificate... Obviously in fact. So that probably means
> some funny mechanisms to connect to various places depending on the cert
> chain (eg: for those connecting via proxies, etc...).
> 
>> One thing to keep in mind is that OCSP stapling in many libraries has (or
>> had, at one point) buggy or nonexistent support for OCSP payloads containing
>> multiple certificates,
> 
> That's a very useful and interesting piece of information.
> 
>> and a bit of research should be done prior to
>> implementation to discover the current state of the world in this regard.
> 
> I agree!
> 
>> I believe the official word at one point was that OCSP stapling of chains
>> should be accomplished by including the entire chain in the OCSP request,
>> delivering that compound OCSP response via the TLS Certificate Status Request
>> extension.
> 
> And do you know how large this could be for average web sites ? Maybe
> there is a cross-over point where doing so has a more negative impact
> than letting the client check by itself ?
> 
> Thanks for your comments and suggestions!
> Willy
> 
> 

-- 
Hervé COMMOWICK
Ingénieur systèmes et réseaux.

http://www.rezulteo.com
by Lizeo Online Media Group 
42 quai Rambaud - 69002 Lyon (France) ⎮ ☎ +33 (0)4 26 99 03 77

Re: FW: SSL OCSP Stapling

[Karel Sedláček]

On Tue, Nov 6, 2012 at 11:08 PM, Willy Tarreau  wrote:
>
> > I would say the periodic-request aspect of it is pretty trivial; you add a
> > timer to the event loop that expires in some configurable amount of time,
> > e.g. a bit before the last OCSP response expires, and you cache the result
> > until it expires or a more recent result overwrites it. Given that the
> > overhead of making a single OCSP request for the cert inside HAProxy is very
> > low, you can easily do this every few minutes with no perceivable overhead.
> > Obviously some logic re: failing requests and retrying has to be 
> > implemented,
> > which amounts to nothing more than a formulation for how much time to wait
> > until retrying again.
>
> I confirm that this part it clearly nothing.
>
> > The user should also be able to configure whether to
> > deliver an expired OCSP response or none at all in the case that an upstream
> > OCSP response cannot be received by the time the currently cached response
> > expires.
>
> That's one of the points of attention, I agree.
>
> > A single timer and single cache slot are used for each certificate chain. 
> > The
> > timer is reset with a new value when:
> > - a request fails; in this case we need
> >   to use our retry/backoff algorithm to decide how long to wait before
> >   retrying;
> > - a request succeeds; in this case we need to use our expires algorithm,
> >   which can be parameterized over the expiration time of the OCSP response, 
> > to
> >   decide how long to wait before trying to get a fresh response.
>
> Hmmm OK it's per certificate... Obviously in fact. So that probably means
> some funny mechanisms to connect to various places depending on the cert
> chain (eg: for those connecting via proxies, etc...).
>
> > One thing to keep in mind is that OCSP stapling in many libraries has (or
> > had, at one point) buggy or nonexistent support for OCSP payloads containing
> > multiple certificates,
>
> That's a very useful and interesting piece of information.
>
> > and a bit of research should be done prior to
> > implementation to discover the current state of the world in this regard.
>
> I agree!
>
> > I believe the official word at one point was that OCSP stapling of chains
> > should be accomplished by including the entire chain in the OCSP request,
> > delivering that compound OCSP response via the TLS Certificate Status 
> > Request
> > extension.
>
> And do you know how large this could be for average web sites ? Maybe
> there is a cross-over point where doing so has a more negative impact
> than letting the client check by itself ?

There might be such a point, but arguably one could let the user
decide when it is reached simply by enabling/disabling OCSP stapling.
Note also that it's pretty easy to imagine that each certificate could
have its own OCSP stapling options, which override whatever the
specified global defaults are. Running OCSP against a 3-cert chain, I
get a DER-encoded response that is 1866 bytes. In a typical
configuration this represents a negligible amount of caching and
bandwidth overhead.

>
>
> Thanks for your comments and suggestions!
> Willy
>

Re: FW: SSL OCSP Stapling

[Alexandre Biancalana]

On Tue, Nov 6, 2012 at 8:08 PM, Willy Tarreau  wrote:

>
>> I believe the official word at one point was that OCSP stapling of chains
>> should be accomplished by including the entire chain in the OCSP request,
>> delivering that compound OCSP response via the TLS Certificate Status Request
>> extension.
>
> And do you know how large this could be for average web sites ? Maybe
> there is a cross-over point where doing so has a more negative impact
> than letting the client check by itself ?

CloudFlare´s announcement about OCSP (and a partnership with
GlobalSign) makes they https client sites 30% faster.

http://techcrunch.com/2012/11/01/cloudflare-globalsign-make-ssl-faster/

Re: FW: SSL OCSP Stapling

[Willy Tarreau]

> I would say the periodic-request aspect of it is pretty trivial; you add a
> timer to the event loop that expires in some configurable amount of time,
> e.g. a bit before the last OCSP response expires, and you cache the result
> until it expires or a more recent result overwrites it. Given that the
> overhead of making a single OCSP request for the cert inside HAProxy is very
> low, you can easily do this every few minutes with no perceivable overhead.
> Obviously some logic re: failing requests and retrying has to be implemented,
> which amounts to nothing more than a formulation for how much time to wait
> until retrying again.

I confirm that this part it clearly nothing.

> The user should also be able to configure whether to
> deliver an expired OCSP response or none at all in the case that an upstream
> OCSP response cannot be received by the time the currently cached response
> expires.

That's one of the points of attention, I agree.

> A single timer and single cache slot are used for each certificate chain. The
> timer is reset with a new value when:
> - a request fails; in this case we need
>   to use our retry/backoff algorithm to decide how long to wait before
>   retrying;
> - a request succeeds; in this case we need to use our expires algorithm,
>   which can be parameterized over the expiration time of the OCSP response, to
>   decide how long to wait before trying to get a fresh response.

Hmmm OK it's per certificate... Obviously in fact. So that probably means
some funny mechanisms to connect to various places depending on the cert
chain (eg: for those connecting via proxies, etc...).

> One thing to keep in mind is that OCSP stapling in many libraries has (or
> had, at one point) buggy or nonexistent support for OCSP payloads containing
> multiple certificates,

That's a very useful and interesting piece of information.

> and a bit of research should be done prior to
> implementation to discover the current state of the world in this regard.

I agree!

> I believe the official word at one point was that OCSP stapling of chains
> should be accomplished by including the entire chain in the OCSP request,
> delivering that compound OCSP response via the TLS Certificate Status Request
> extension.

And do you know how large this could be for average web sites ? Maybe
there is a cross-over point where doing so has a more negative impact
than letting the client check by itself ?

Thanks for your comments and suggestions!
Willy

FW: SSL OCSP Stapling

[Lukas Tribus]

forwarding your response to the list ...

Date: Tue, 6 Nov 2012 17:38:06 +0100
Subject: Re: SSL OCSP Stapling
From: k...@ksdlck.com
To: luky...@hotmail.com

I would say the periodic-request aspect of it is pretty trivial; you add a 
timer to the event loop that expires in some configurable amount of time, e.g. 
a bit before the last OCSP response expires, and you cache the result until it 
expires or a more recent result overwrites it. Given that the overhead of 
making a single OCSP request for the cert inside HAProxy is very low, you can 
easily do this every few minutes with no perceivable overhead. Obviously some 
logic re: failing requests and retrying has to be implemented, which amounts to 
nothing more than a formulation for how much time to wait until retrying again. 
The user should also be able to configure whether to deliver an expired OCSP 
response or none at all in the case that an upstream OCSP response cannot be 
received by the time the currently cached response expires.

A single timer and single cache slot are used for each certificate chain. The 
timer is reset with a new value when:- a request fails; in this case we need to 
use our retry/backoff algorithm to decide how long to wait before retrying;
- a request succeeds; in this case we need to use our expires algorithm, which 
can be parameterized over the expiration time of the OCSP response, to decide 
how long to wait before trying to get a fresh response.

One thing to keep in mind is that OCSP stapling in many libraries has (or had, 
at one point) buggy or nonexistent support for OCSP payloads containing 
multiple certificates, and a bit of research should be done prior to 
implementation to discover the current state of the world in this regard. I 
believe the official word at one point was that OCSP stapling of chains should 
be accomplished by including the entire chain in the OCSP request, delivering 
that compound OCSP response via the TLS Certificate Status Request extension.

k

On Tue, Nov 6, 2012 at 4:57 PM, Lukas Tribus  wrote:



Don't know if it helps without some knowledge of the nginx source code, but 
here [1] you can find the patches applied to nginx to introduce ocsp support.



Its doesn't seem to be trivial to implement though, because you also need to 
run (at regular intervals) an OCSP query towards the CA's OCSP server...







[1] http://nginx.org/patches/ocsp-stapling/









> Date: Wed, 31 Oct 2012 22:52:55 +0100

> From: w...@1wt.eu

> To: bed...@gmail.com

> CC: cont...@davidberard.fr; haproxy@formilux.org

> Subject: Re: SSL OCSP Stapling

>

> On Tue, Oct 30, 2012 at 03:26:21PM +0100, Baptiste wrote:

> > Hi,

> >

> > I discussed about it a few weeks ago with @emericbr @exceliance, but

> > he was a bit doubtful about it.

> > As far as I'm concerned, I think this would be a nice new feature.

> >

> > so let's wait for Willy's response.

>

> well, after having checked the RFC on this, I must confess that what it

> provides and the way it's supposed to work are still cryptic to me :-/

>

> If someone could explain in a simple way (assuming that something in TLS

> can be explained that way), and provide some real world use case, it would

> be nice.

>

> Regards,

> Willy

>

>