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(00000003)
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:
ff:90:a8:9c:57:ac:cc:f1:96:4a:cb:e3:7a:fd:6c:77:61:9b:
86:59:8a:4c:d7:00:64:43:96:0d:13:cb:f8:0b:88:29:2c:2c:
f1:8e:53:8f:01:af:87:c5:40:7f:54:fd:c0:2d:de:3a:c5:02:
0f:42:10:42:59:c3:f6:da:dd:52:d1:e4:92:af:66:21:98:45:
c3:2c:02:83:6a:7a:63:e9:cf:3d:09:77:78:1f:a2:89:e0:b1:
d8:01:d7:78:c0:4c:fc:24:d5:1f:0a:5b:fb:25:cd:45:24:bb:
98:fb:67:cb:a8:a8:de:f0:72:04:33:33:75:ec:9f:28:28:98:
a2:b8:5d:9d:fd:e0:9c:2d:0b:4c:ee:4b:d5:b2:b1:73:21:09:
d9:d8:65:d9:5f:41:5e:15:09:54:46:f4:00:0a:f6:b3:34:0e:
50:cb:4f:7a:9d:d2:7b:11:36:7e:f7:75:76:a3:e9:2f:50:c1:
34:1c:c7:4a:9a:2c:19:0b:5c:4c:b2:40:93:3b:c0:f6:29:2e:
2c:dc:50:04
-----BEGIN CERTIFICATE-----
MIIDjDCCAnSgAwIBAgIDAkVTMA0GCSqGSIb3DQEBBQUAMEAxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEYMBYGA1UEAxMPR2VvVHJ1c3QgU1NM
IENBMB4XDTEzMDUyODE3MzU1MVoXDTE0MDUyNzE3MzU1MVowUDELMAkGA1UEBhMC
VVMxFzAVBgNVBAoTDkdlb1RydXN0LCBJbmMuMSgwJgYDVQQDEx9HZW9UcnVzdCBT
U0wgT0NTUC1UR1YgUmVzcG9uZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAssCRyAgrpdgXKyjTvO+3K426AH5A6Ud8MIGa0z4ND3CoqOouLMlpbOQc
vcy1hJjm8K4BK8F1lgCDlnCkQz88BvsGwdUoHx5TYocmLaGWyFBtF8q8+yIs75s2
EjegyioSAxJS6/f8toju1CQli5iAC0KhAcnso5x70dFjEEOG26SLDo7TUlVVnbLl
GdUKwiNSUWyGF3nIsjmZ1eNwQPcw0iftxn+ClYs+0QjxTHUsPvSbltWFfcUCLyGp
Y4Mndb3i4yjarqTAbTkukjt6szWBLTeJ5GxtUyrgY7YicGfdbQeTSFBiBk27Rw2y
uUtqvRwosrCnRmv413ShXSxrQZXcdQIDAQABo38wfTAfBgNVHSMEGDAWgBRCeVQb
Yc1VKz5j1TxIV/Wf+0XOSjAPBgkrBgEFBQcwAQUEAgUAMBMGA1UdJQQMMAoGCCsG
AQUFBwMJMA4GA1UdDwEB/wQEAwIHgDAkBgNVHREEHTAbpBkwFzEVMBMGA1UEAxMM
MjA0OC1UR1YtMzMzMA0GCSqGSIb3DQEBBQUAA4IBAQAwDDBOouiNaIj5k0FsPksZ
70Ijcv5kgSGtXBpRYveaLPithbVJw60PuHBB/R3bGGicj2RO8Rj/kKicV6zM8ZZK
y+N6/Wx3YZuGWYpM1wBkQ5YNE8v4C4gpLCzxjlOPAa+HxUB/VP3ALd46xQIPQhBC
WcP22t1S0eSSr2YhmEXDLAKDanpj6c89CXd4H6KJ4LHYAdd4wEz8JNUfClv7Jc1F
JLuY+2fLqKje8HIEMzN17J8oKJiiuF2d/eCcLQtM7kvVsrFzIQnZ2GXZX0FeFQlU
RvQACvazNA5Qy096ndJ7ETZ+93V2o+kvUME0HMdKmiwZC1xMskCTO8D2KS4s3FAE
-----END CERTIFICATE-----
======================================
---
Certificate chain
0
s:/serialNumber=8DZwltU1cw7OP-08XVgEwK/bh8Icw4zX/C=US/ST=California/L=Mountain
View/O=Mozilla Corporation/OU=Mozilla Labs/CN=*.mozillalabs.com
i:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
1 s:/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFJDCCBAygAwIBAgIDAlZ8MA0GCSqGSIb3DQEBBQUAMEAxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEYMBYGA1UEAxMPR2VvVHJ1c3QgU1NM
IENBMB4XDTEzMDYyNDE5NTcwNFoXDTE1MDgyNjIxMjQ1OVowgbYxKTAnBgNVBAUT
IDhEWndsdFUxY3c3T1AtMDhYVmdFd0svYmg4SWN3NHpYMQswCQYDVQQGEwJVUzET
MBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNTW91bnRhaW4gVmlldzEcMBoG
A1UEChMTTW96aWxsYSBDb3Jwb3JhdGlvbjEVMBMGA1UECxMMTW96aWxsYSBMYWJz
MRowGAYDVQQDDBEqLm1vemlsbGFsYWJzLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAKOEx5OkbsLNrPPw2bk4EwSoNB8ipfraF0TQNnZ2sTgvg2Rl
So1ae+2z2gmDRBSI6a4ZhpX6STgfSbQe28E36kYfRbGJxMC6eoF7CQNNDsLeu523
CxihCA3NgVTti7t4lrdXqWHC2w0cUDXL+n0OZ1KQVOoP9znY4sz6wFLV1Avl8z1O
yaSbKQ+Zpn+dHj3fuV717cgsMJ/C71+keS+WzgH01IH4Y3hNI9o/ZEc/YI4I9A/x
pyyZ0iegKj28oAHOvQRmk9rbhAiL1U+zFP302TGrYTX0y3LthUyYfOh0+l2YAPxG
koEMXye3F1cfxu4w5iDdeoLxzqYjq6y4K5ZD9eMCAwEAAaOCAa4wggGqMB8GA1Ud
IwQYMBaAFEJ5VBthzVUrPmPVPEhX9Z/7Rc5KMA4GA1UdDwEB/wQEAwIEsDAdBgNV
HSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwLQYDVR0RBCYwJIIRKi5tb3ppbGxh
bGFicy5jb22CD21vemlsbGFsYWJzLmNvbTA9BgNVHR8ENjA0MDKgMKAuhixodHRw
Oi8vZ3Rzc2wtY3JsLmdlb3RydXN0LmNvbS9jcmxzL2d0c3NsLmNybDAdBgNVHQ4E
FgQUTkcuGymAWcUoTQP5JuX3a5pvMb8wDAYDVR0TAQH/BAIwADBvBggrBgEFBQcB
AQRjMGEwKgYIKwYBBQUHMAGGHmh0dHA6Ly9ndHNzbC1vY3NwLmdlb3RydXN0LmNv
bTAzBggrBgEFBQcwAoYnaHR0cDovL2d0c3NsLWFpYS5nZW90cnVzdC5jb20vZ3Rz
c2wuY3J0MEwGA1UdIARFMEMwQQYKYIZIAYb4RQEHNjAzMDEGCCsGAQUFBwIBFiVo
dHRwOi8vd3d3Lmdlb3RydXN0LmNvbS9yZXNvdXJjZXMvY3BzMA0GCSqGSIb3DQEB
BQUAA4IBAQAjh/Y8xua0lQINGQBYZX/OADEbJSCoMy5r+gt5Jb+Efpa44xuG/SM7
LLT+Nz0CD7bipfyRjJsyOeTkyyZdIjplHd87XrjH8SOTzENZ04AJLro7oYnRSkOO
4zNF1lGBvO6/wt2U1Yci3orfw3hFeZLGVqGVdryE6K0arrQ3MAkEUaoK3oKUm96+
tEbS/vXoaq8aG5f8usvjV+DLzeRsZTII917Fsvv9KBj3SYcJUxlv0rZohltlK7As
hA7hjwoJbhMgFfPKU2C36Vy01MXgab+QSVRIkEez5wnXlwzFJ7uhNUT94BBZiaAx
sUfvA5B9jjrsKc229dWAOtiNIYQZOPeB
-----END CERTIFICATE-----
subject=/serialNumber=8DZwltU1cw7OP-08XVgEwK/bh8Icw4zX/C=US/ST=California/L=Mountain
View/O=Mozilla Corporation/OU=Mozilla Labs/CN=*.mozillalabs.com
issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
---
No client certificate CA names sent
---
SSL handshake has read 4487 bytes and written 472 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.1
Cipher : DHE-RSA-AES128-SHA
Session-ID:
E4CEFF7A2175B4E2FA14C44C40E053E12F48B23E9821D992875097EB06670C04
Session-ID-ctx:
Master-Key:
0C5CB7BA878E96FAADEBE7DF5104F39DEDF885E4E40EE8C51710DD386C65A35E99CA025B35C4E12424D7C3151256A318
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1393604231
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
DONE
On 2014-01-31 09:48, Hervé COMMOWICK wrote:
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
