Feature request: OCSP Must Staple (RFC 7633)

[osiris...@gmail.com]

In 2014 Adam Langley already told us the current way of revocation checking is broken: https://www.imperialviolet.org/2014/04/19/revchecking.html

At that time, OCSP Must-Staple, the major goal of `TLS Feature Extension`, now RFC 7633, was only a draft. But it's an RFC now :)

Already, Firefox has implemented OCSP Must-Staple in their development version (Fx 45): https://wiki.mozilla.org/CA:ImprovingRevocation#OCSP_Must-Staple

The new kid on the block of CA's, promising to be a big star, Let's Encrypt, already has support for OCSP Must-Staple in its code base: https://github.com/letsencrypt/boulder/pull/1224 It's just a matter of time before they'll support issuing Must-Staple certificates.

Unfurtunately, the issue on bugs.chromium.org hasn't got much attention: https://bugs.chromium.org/p/chromium/issues/detail?id=572734 Chromestatus.com doesn't mention `ocsp` altogether: https://www.google.com/search?q=ocsp+site%3Awww.chromestatus.com

So, my question to you all is: what's holding Chromium back in implementing this big step in certificate revocation checking?

[Ryan Sleevi]

On Sun, Mar 6, 2016 at 10:50 AM, <osiris...@gmail.com> wrote:

So, my question to you all is: what's holding Chromium back in implementing this big step in certificate revocation checking?

The state of the world for OCSP code is bad. Real bad. Unless you're running IIS, or running a home-grown OCSP daemon, you're going to staple bad responses. That is, if you turn on stapling in Apache or nginx, you're going to serve junk to a portion of your users. When you serve junk, in a must-staple world, everything goes badly.

Further, the world assumes clients are well-behaved - they have good clocks, good caching logic, and good OCSP implementations. Unfortunately, those assumptions can all be wrong - and when something's wrong on the client, it could brick sites. We already see this with HSTS and a variety of otherwise fixable errors (such as clock skew) contributing significantly to warning fatigue or user frustration - and it's actually rather surprisingly hard to quantify, on the client, the ways in which the client could have screwed up.

To that end, our focus has been on quantifying the OCSP ecosystem - both in terms of what the CAs are sending (... frequently, horribly bloated responses that often fail basic DER encoding rules), and what servers are doing. We're also exploring how to allow server operators to participate in that virtuous feedback cycle, by providing something akin to 'expect-staple' - that is, a signifier that the server *should* always be sending valid stapled responses, and a means of getting feedback when this is not the case. This will allow sites to further debug and investigate, both client errors and the fact that, again, most of the OCSP fetching code on servers is bad.

[osiris...@gmail.com]

Op maandag 7 maart 2016 14:25:58 UTC+1 schreef Ryan Sleevi:

It's not really up to the browser to decide this, is it? It's up to the server sysop who is implementing a Must-Staple certificate to weigh the pros and cons of Must-Staple and the chance of bad stapling.

The only thing a browser should do is honor the request of the certificates Must-Staple-feature. I don't see why it's up to Chromium to decide these things. Mozilla has enabled Must-Staple by default in its products; they don't see the problem you guys apparently see.. Got any proof of those statements?

[Ryan Sleevi]

On Sun, Mar 13, 2016 at 1:50 PM, <osiris...@gmail.com> wrote:

It's not really up to the browser to decide this, is it? It's up to the server sysop who is implementing a Must-Staple certificate to weigh the pros and cons of Must-Staple and the chance of bad stapling.

Respectfully, there's a balance tradeoff between the ecosystem risk of conditioning users to failures and to a user-experience risk when failures happen.

Must-Staple, as a feature, has a poor feedback loop for server sysops to know that implementing Must-Staple is coming with tradeoffs or causing poor user experiences.

 

The only thing a browser should do is honor the request of the certificates Must-Staple-feature. I don't see why it's up to Chromium to decide these things. Mozilla has enabled Must-Staple by default in its products; they don't see the problem you guys apparently see.. Got any proof of those statements?

Mozilla simply didn't measure it, as you can speak to the Mozilla engineers responsible for this. It's reasonable for people to disagree, but at this time, implementing Must-Staple is not on the roadmap. Not because the feature is fundamentally flawed (although it does suffer from issues), but really because our experience and user metrics show it's not quite ready for prime time.

[osiris...@gmail.com]

Op zondag 13 maart 2016 22:04:59 UTC+1 schreef Ryan Sleevi:

> On Sun, Mar 13, 2016 at 1:50 PM, <osiris...@gmail.com> wrote:
> It's not really up to the browser to decide this, is it? It's up to the server sysop who is implementing a Must-Staple certificate to weigh the pros and cons of Must-Staple and the chance of bad stapling.
>
>
>
> Respectfully, there's a balance tradeoff between the ecosystem risk of conditioning users to failures and to a user-experience risk when failures happen.
>
>
> Must-Staple, as a feature, has a poor feedback loop for server sysops to know that implementing Must-Staple is coming with tradeoffs or causing poor user experiences.

It doesn't have the reporting capabilities like the HSTS header no, true.. Then again, server ops could monitor their OCSP responses. If they're OK, must-staple shouldn't be a problem. And then, in my opinion, it's up to the server op to use a must-staple cert if they are satisfied their OCSP responses are fine.

 
> The only thing a browser should do is honor the request of the certificates Must-Staple-feature. I don't see why it's up to Chromium to decide these things. Mozilla has enabled Must-Staple by default in its products; they don't see the problem you guys apparently see.. Got any proof of those statements?
>
> Mozilla simply didn't measure it, as you can speak to the Mozilla engineers responsible for this. It's reasonable for people to disagree, but at this time, implementing Must-Staple is not on the roadmap. Not because the feature is fundamentally flawed (although it does suffer from issues), but really because our experience and user metrics show it's not quite ready for prime time.

Are these metrics public? Because I've never heard about this problem before and can't find anything about it with Google.

[Emily Stark]

Hi there,

I suspect the data/metrics that Ryan is referencing come from a few places:

- data about HTTPS errors as a whole (which shows that complex problems on clients and networks are rampant, meaning that a server operator might not even be able to gauge whether a particular TLS configuration is actually working or not) [1]

- experience with sites bricking themselves via HPKP [2]

- lots of published research about warning fatigue and habituation [3]

Basically, I think what Ryan is saying boils down to wanting to do a bit more research (via projects like Expect-Staple), to make sure that we don't start supporting something that ends up harming the web as a whole. I don't think the fact that Mozilla already implemented it means that Chrome needs to do it right away; different browsers have different priorities, goals, and user populations. Plus, hopefully we'll be able to learn from how the feature works out for Firefox which will help us figure out where it should go on our roadmap.

Emily

[1] https://docs.google.com/presentation/d/1Qmpl-5epx0B5C2t4XsUTyjgbwab_rXfK_4iHqX3IC30/pub?start=false&loop=false&delayms=3000&slide=id.gf44795496_0_1 has a good summary

[2] e.g. https://crbug.com/445821

[3] e.g. https://books.google.com/books?id=lxwLVy16wqoC&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false

[zglo...@beame.io]

i would like to raise this feature as probably the only line of defense in a context of a man in the middle attack.

We are living in a world were it takes almost nothing to set
Up that attack in less that a day with like literary no network expirence.

So I think the world of secure web applications needs a way to know that may cert matches the expected cert.

However from what I understand that even if ocsp must staple was implemented, it would not reject a staple provided by a fake provided the fake CA, because the current ca ties it to the certificate Id and not the common name.

[Chris Palmer]

On Mon, May 23, 2016 at 6:01 PM, <zglo...@beame.io> wrote:

So I think the world of secure web applications needs a way to know that may cert matches the expected cert.

That feature is key pinning, not OCSP (must-staple or old-style), and it is shipped and working in Chrome now.

[Zeev Glozman]

Chris 

So how would as a web developer take advantage of this feature for my own certs ? Is there a document somewhere?

[Chris Palmer]

On Tue, May 24, 2016 at 11:37 AM, Zeev Glozman <zglo...@beame.io> wrote:

So how would as a web developer take advantage of this feature for my own certs ? Is there a document somewhere?

A web search for [ how to use public key pinning ] turns up some good results, and also I wrote a blog post about it: https://noncombatant.org/2015/05/01/about-http-public-key-pinning/

HOWEVER:

Key pinning poses a significant risk that the site operator might accidentally lock people out of the site (such as by rotating the server key to a non-pinned key). If you haven't already read and understood https://tools.ietf.org/html/rfc7469, I would suggest you rely on plain vanilla HTTPS, and the much safer mechanism of Certificate Transparency. That is, use a CA that uses CT, and monitor the CT logs for misissued certificates for your site. See the https://crt.sh/ site for an example CT query system.

[Zeev Glozman]

Chris and team this is truly a great feature. I personally worry less about the potential lockout then a MITM. 

Thank u so much this is great.

[Eric Mill]

Emily Stark also has a great walkthrough of the less dangerous form of HPKP, which is to use its report-only mode:

https://developers.google.com/web/updates/2015/09/HPKP-reporting-with-chrome-46

-- Eric

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

--

konklone.com | @konklone

[evan...@gmail.com]

It's now 3 years later and improvements have been made all around but still no way to force Chrome to perform revocation checking. No Must-Staple support and Expect-Staple is report only. The bug https://bugs.chromium.org/p/chromium/issues/detail?id=572734
is closed as Won't Fix....have we really just given up on trying to fix this problem?