Looks like Scott Rea of DigiCert did a lightening talk on the workshop he and I participated in this last April, it was recorded and gives you a glimpse into the conversations that took place during this event; it is worth taking a look.
Work just published the transcript from my panel discussion on Third-Party Trust Providers and SSL Best Practices last month at InfoSec Europe 2012, it also looks like Ivan has put his notes up also.
It was a good discussion, thanks again to David Holmes and Ivan Ristic.
Did you know about 1% of the traffic on the internet is protected with SSL (see the Sandyvine Report)?
Or than many of the sites responsible for this traffic do not require SSL, they instead just make it available as an option?
This unfortunately this means users are exposed to risks that are otherwise would not be present.
There is a trend to move to protecting all site content with SSL, this effort has been dubbed Always On SSL; the OTA has just recently published a whitepaper on this topic that I had a chance to contribute to.
I have been asked a few times recently what my largest issues are with Firefox and it’s PKI/TLS implementations, here is the short-list:
725351 – Support enforcing nested EKU constraints, do so by default.
579606 – Multiple OCSP requests should be performed in parallel
565047 – Implement TLS 1.1 (RFC 4346)
436414 – OCSP client should be able to use HTTP GET as well as POST
360420 – Implement OCSP Stapling in libSSL
399324 – Fetch missing intermediate certs (use AIA extension for incomplete cert chains)
378098 – Do not expire OCSP responses that say “revoked”
48597 – OCSP needs offline cache (persistent on-disk)
Kathleen at Mozilla has recently set up a page to track revocation related issues here.
At the most recent CA/Browser Forum folks from DigiCert and I both made presentations on what’s needed to improve the current state of revocation in X.509.
There were really two different themes in these presentations:
It was not really possible to go into any details about these proposals given the time slots allocated were more presentation oriented and since the DigiCert guys had already engaged with Maximiliano Palla of NYU Polytechnic University (the founder of the OpenCA project) they agreed to work with him to arrange this workshop.
The session is April 16th (I leave tomorrow) and I am looking forward to the chance to talk about this topic, my goals for the session are we get to agreements on:
There are lots of other potentially interesting topics I am sure will come up:
Should be an interesting day for sure.
Today the best behaving client for revocation behavior is that of Windows, in the case of browsers that means IE and Chrome.
With that said it has a very fundamental problem, if it reaches a CA’s OCSP responder and it provides an authoritative “that’s not mine” (aka Unknown) clients built on this platform treat the certificate as good.
You got that right; it treats a certificate that is clearly invalid as good! This unfortunately is a common behavior that all the browsers implement today.
The other browsers are even worse, Firefox for example:
These each seem like fairly small items but when you look at all these issues as a whole they significantly contribute the reality we face today – Revocation Checking isn’t working.
There are other problems as well, for example:
In some cases browsers do support GET as a means to do a OCSP request but if they receive a “stale” or “expired” response from an intermediary cache (such as a corporate proxy server) they do not retry the request bypassing the proxy.
All browsers today do synchronous revocation checking, imagine if your browser only downloaded one image at a time in series; that’s in-essence what the browsers are doing today.
These and other client behaviors contribute to reliability and performance problems that are preventing Hard Revocation Checking from being deployed. These issues need to be addressed and the browser vendors need to start publishing metrics on what the failure rates are as well as under what conditions they fail so that any remaining issues on the responder side can be resolved.
Recently I set up a PingDom monitor to track the overall performance of the various OCSP responders out there, PingDom is limited to doing GETs and cannot parse the responses from the responders but it’s a fair mechanism to look at response time.
These tests run from a number of different global locations and are averaged together, the locations change but the same locations are used for each set of tests so again this seems fair.
I decided to use the Google logo as my control test, as it is about the same size as a larger OCSP response, after about a month of monitoring this is what I saw:
| Test | Avg. Response time |
| Google Logo (3972 bytes) |
44 ms |
| GoDaddy OCSP |
186 ms |
| GlobalSign OCSP |
228 ms |
| Digicert OCSP |
266 ms |
| Comodo OCSP |
268 ms |
| TrustCenter OCSP |
273 ms |
| TrustWave OCSP |
315 ms |
| Startcom OCSP |
364 ms |
| Entrust OCSP |
371 ms |
| Geotrust OCSP |
432 ms |
| VeriSign OCSP |
510 ms |
| CyberTrust OCSP |
604 ms |
| Certum OCSP |
776 ms |
As you can see the fastest responder is over four times slower than the Google logo, far from acceptable.
When looking at the individual responses and their responses this is what I saw:
These are all fairly easy things to address and I believe it’s reasonable for responders to get down to response times that are consistent with the control test above.
It pretty easy, the OpenSSL and CURL manuals make it fairly easy but I thought I would put it all here in a single post for you.
First in these examples I used the certificates from the http://www.globalsign.com site, I saved the www certificate to globalsignssl.crt and its issuer to globalsignssl.crt.
Next you will find a series of commands used to generate both POSTs and GETs for OCSP:
1. Create a OCSP request to work with, this also will produce a POST to the OCSP responder
openssl ocsp -noverify -no_nonce -respout ocspglobalsignca.resp -reqout ocspglobalsignca.req -issuer globalsigng2.cer -cert globalsign.com.cer -url "http://ocsp2.globalsign.com/gsextendvalg2" -header "HOST" "ocsp2.globalsign.com" -text
2. Base64 encode the DER encoded OCSP request
openssl enc -in ocspglobalsignca.req -out ocspglobalsignca.req.b64 -a
3. URL Encode the Base64 blob after removing any line breaks (see: http://meyerweb.com/eric/tools/dencoder/ for a decoder)
4. Copy the Base64 into the URL you will use in your GET
http://ocsp2.globalsign.com/gsextendvalg2/{URL encoded Base64 Here}
5. Do your GET:
curl --verbose --url http://ocsp2.globalsign.com/gsextendvalg2/MFMwUTBPME0wSzAJBgUrDgMCGgUABBSgcg6ganxiAlTyqPWd0nuk87cvpAQUsLBK%2FRx1KPgcYaoT9vrBkD1rFqMCEhEhD0Xjo%2FV7lgq3ziGoWG69rA%3D%3D
If you like you can also re-play the request that was generated with OpenSSL as a POST:
curl --verbose --data-binary @ocspglobalsignca.req -H "Content-Type:application/ocsp-request" --url http://ocsp2.globalsign.com/gsextendvalg2
If you follow discussions around x.509 and SSL you have likely heard that “Revocation Checking is Broken”, you might even hear it will never work therefore we should start over with a technology that isn’t dependent on this concept.
There are some merits to these arguments but I don’t agree with the conclusion, I thought I would summarize what the problems are in this post.
Fundamentally the largest problem is that, as-deployed, all x.509 revocation technologies introduce a communication with a third-party (the Certificate Authority).
This isn’t necessarily a deal breaker but it does have consequences, for example in the case of SSL:
These issues can be mitigated through intelligent deployments and engineering but unfortunately this really has not happened, as a result Browsers have implemented what is called “Soft-fail revocation checking”.
With soft-fail revocation checking browsers ignore all conditions other than an authoritative “revoked” message, in the case of OCSP that means if they reach the responder and it says “I don’t know the status” or if it fails to reach the responder it assumes it is “good”.
This behavior is of course fundamentally flawed, the Browsers say they have no choice (I disagree with this conclusion but that’s a topic for another post) other than to behave this way, but why?
The rational is as follows:
These are all legitimate concerns, ones that are unfortunately as true today as they were almost a decade ago.
They are not however insurmountable and I think it’s time we as an industry did something about it.
The other day posted about “Least Privilege and Subordinate Certificate Authorities”, this post talked about how you can delegate only a limited set of rights to a subordinate CA. I thought you might find a set of configuration files and batch files I put together to test these scenarios useful, here you go.
I threw this together on a Windows machine that had the Shinning Light OpenSSL distribution on it, it has several batch files:
Then there is the OpenSSL configuration files, most of this is straight forward but for the stuff that is not check out the OpenSSL documentation.