I don't know much about TLS and HTTPS, so any corrections would be appreciated.
Why is security.OCSP.require option set to false by default?
If I understand correctly, it means that when Firefox fails to reach the OCSP server, it will silently assume that the certificate it got hasn't been revoked.
A man-in-the-middle attacker sitting close to the client can easily arrange for the OCSP server to be inaccessible. So with regard to MITM any rogue certificate becomes irrevocable. Obtaining a rogue certificate for existing website turns out to be surprisingly easy due to poor verification procedures of some CAs. Also, attackers can obtain valid certificates using vulnerabilities such as the recent MD5 collision and null prefix attacks. Being able to use a certificate for long after it was revoked substantially changes the economics of these attacks.
On 10/10/09 10:47 AM, Alexander Konovalenko wrote:
> Why is security.OCSP.require option set to false by default?
Because in practice the OCSP servers most CAs run are completely dysfunctional at worst (e.g. always return HTTP 500) and woefully underpowered at best. Some of them can handle something on the order of 1-2 OCSP requests per second, last it was tested (when AMO ended up down because the CA couldn't handle the OCSP requests for it). So requiring it would actually mean that sites that use OCSP would just stop working (due to the browser effectively executing a DDOS on severs not set up to handle it).
> A man-in-the-middle attacker sitting close to the client can easily > arrange for the OCSP server to be inaccessible.
Yes, this is a problem. There's no good solution without CAs updating their OCSP setup, or Firefox implementing OCSP stapling, or likely both....
On Saturday 10 October 2009 16:05:32 Boris Zbarsky wrote:
> On 10/10/09 10:47 AM, Alexander Konovalenko wrote: > > Why is security.OCSP.require option set to false by default?
> Because in practice the OCSP servers most CAs run are completely > dysfunctional at worst (e.g. always return HTTP 500) and woefully > underpowered at best.
Boris, what you've described is certainly true of some CAs. However, I disagree with your claim that "most CAs" are that incompetent.
Comodo's OCSP Responder infrastructure handles many hundreds of OCSP requests per second. We are confident that our current servers could easily handle several times as much traffic, and we can easily add more servers when we need to increase the capacity still further.
VeriSign claim to handle over one billion OCSP requests per day. If their servers are "woefully underpowered", surely we'd have heard about it by now!?
Perhaps the time has come for the browsers to "force" all of the other CAs to take their OCSP responsibility seriously, by requiring OCSP by default.
> Some of them can handle something on the order of > 1-2 OCSP requests per second, last it was tested (when AMO ended up down > because the CA couldn't handle the OCSP requests for it).
The EV Guidelines say that "The CA MUST operate and maintain its CRL and/or OCSP capability with resources sufficient to provide a commercially-reasonable response time for the number of queries generated by all of the EV Certificates issued by the CA".
That CA clearly fell short of this requirement.
> So requiring it would actually mean that sites that use OCSP would just stop > working (due to the browser effectively executing a DDOS on severs not set > up to handle it).
> > A man-in-the-middle attacker sitting close to the client can easily > > arrange for the OCSP server to be inaccessible.
> Yes, this is a problem. There's no good solution without CAs updating > their OCSP setup, or Firefox implementing OCSP stapling, or likely both....
-- Rob Stradling Senior Research & Development Scientist C·O·M·O·D·O - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com
Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
> On 12/10/2009 12:13, Rob Stradling wrote: <snip> > > That CA clearly fell short of this requirement.
> It is ... surely a thing of customer <--> CA relationship. If there are > insufficient resources, the customer experience will be crap.
Which "customer" are you referring to?
It's the relying party (i.e. a human using a browser) who are most likely to suffer when a CA's OCSP Responder isn't working well. And that relying party will probably either blame their browser or the operator of the website which is experiencing the problem.
I think the AMO case is likely to be the exception rather than the rule. The operator of the website (Mozilla) was technically knowledgeable enough to spot the source of the problem (GlobalSign's OCSP Responder).
> If the market isn't working here, then there is something wrong with the > market, and creating a requirement in a dry dusty document
I'm not sure how a PDF file can gather dust. ;-)
> is pretty close to the worst thing to do.
Ian, what do you think would be the best thing to do?
-- Rob Stradling Senior Research & Development Scientist C·O·M·O·D·O - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com
Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
> Comodo's OCSP Responder infrastructure handles many hundreds of OCSP requests > per second. We are confident that our current servers could easily handle > several times as much traffic, and we can easily add more servers when we > need to increase the capacity still further.
I think StartCom is in a similar situation. As increase in demand doesn't happen usually over night, correct assessments should guaranty proper functioning and adequate allocation of the resources. Obviously it's a far cry compared to a non-working, non-accessible and non-existing advertised OCSP URI.
> VeriSign claim to handle over one billion OCSP requests per day. If their > servers are "woefully underpowered", surely we'd have heard about it by now!?
> Perhaps the time has come for the browsers to "force" all of the other CAs to > take their OCSP responsibility seriously, by requiring OCSP by default.
Amen!
> That CA clearly fell short of this requirement.
I don't think this CA issues EV certificates. Which is perhaps we one can draw a difference also regarding regular certificates as well.
On Monday 12 October 2009 14:46:28 Eddy Nigg wrote: <snip>
> > That CA clearly fell short of this requirement.
> I don't think this CA issues EV certificates.
Boris and I were referring to the GlobalSign EV cert for AMO.
> Which is perhaps we one can draw a difference also regarding regular > certificates as well.
-- Rob Stradling Senior Research & Development Scientist C·O·M·O·D·O - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com
Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
> On Monday 12 October 2009 14:46:28 Eddy Nigg wrote: > <snip>
>>> That CA clearly fell short of this requirement.
>> I don't think this CA issues EV certificates.
> Boris and I were referring to the GlobalSign EV cert for AMO.
Oh, I meant ipsCA. GlobalSign at least has some OCSP responder capability, right? It's not something which can't be correct...some more knowledge and horsepower can help with that.
> On Monday 12 October 2009 12:12:22 Ian G wrote: >> On 12/10/2009 12:13, Rob Stradling wrote: > <snip> >>> That CA clearly fell short of this requirement.
>> It is ... surely a thing of customer<--> CA relationship. If there are >> insufficient resources, the customer experience will be crap.
> Which "customer" are you referring to?
> It's the relying party (i.e. a human using a browser) who are most likely to > suffer when a CA's OCSP Responder isn't working well. And that relying party > will probably either blame their browser or the operator of the website which > is experiencing the problem.
Right, in this case, the customer's customer suffers. No problem, the customer should learn about the quality of the user experience delivered to its customer. The market, business as usual.
> I think the AMO case is likely to be the exception rather than the rule. The > operator of the website (Mozilla) was technically knowledgeable enough to > spot the source of the problem (GlobalSign's OCSP Responder).
Yeah, I'm simply commenting on the relationship to the EV guidelines.
>> If the market isn't working here, then there is something wrong with the >> market, and creating a requirement in a dry dusty document
> I'm not sure how a PDF file can gather dust. ;-)
>> is pretty close to the worst thing to do.
> Ian, what do you think would be the best thing to do?
Well, assuming a context of the EV guidelines, it should be re-written to strip out all business and competitive stuff. Anything that seems to be related to the customer experience (whatever that means).
Of course this won't happen :) so there isn't a lot of point in worrying about it for those guys [0]. But here, we should know the difference and keep it out.
If an OCSP request takes 10 seconds, that's something the customer's customer can grumble about, and the customer can go and get another cert. Plain and simple.
iang
[0] of course, we know *why* it's in there, but we don't want to spoil someone's party.
> Why is security.OCSP.require option set to false by default?
Currently there is no requirement that CA's support OCSP for non-EV certificates, so some CA's don't. It would be nice if they then didn't put OCSP URLs into their certs, but some do anyway (aspirational OCSP?). The end result was that in our testing too many sites were unreachable with this setting set to true. However the site owners and our users complained that since it "worked in IE" the blame must lie with Firefox.
It's getting much better since most of the largest CA's now offer EV certs and have beefed up their infrastructure. We are working with the CA/Browser forum to make OCSP support a requirement for non-EV certs
> Obtaining a rogue certificate for existing website turns out to be > surprisingly easy due to poor verification procedures of some CAs.
The surprise is that it is occasionally possible. I wouldn't characterize it as "easy" or it wouldn't be such a big deal each time someone finds a way to do it. If you know of a bad CA please let us know so we can investigate and remove them from the product if necessary.
> Perhaps the time has come for the browsers to "force" all of the other CAs to > take their OCSP responsibility seriously, by requiring OCSP by default.
Firefox cannot take that step unilaterally, otherwise _we_ are the broken one in users eyes.
An alternate approach I'd like to lobby our front-end guys on would be to put up a scary red bar when we can't validate OCSP. Users can still get to their sites so they won't ditch us for another browser, site owners are still getting traffic so they won't be breathing down _our_ neck (too much), but the site will look a little scary and link to an explanation so site owners can take the issue up with their CA and users have the opportunity to decide not to submit sensitive data over the connection.
In the longer term we're working with browser vendors and CAs to make OCSP support an understood requirement so that at some point in the future we can block connections when we don't get a positive OCSP response. (We do, of course, block connections when we get an explicit OCSP revocation.)
> The surprise is that it is occasionally possible. I wouldn't > characterize it as "easy" or it wouldn't be such a big deal each time > someone finds a way to do it. If you know of a bad CA please let us > know so we can investigate and remove them from the product if necessary.
It must be understood that some issues can happen, nobody knows that better than our dear developers of the Mozilla software. I think nobody taunts that CA for their null bug, things like that can happen.
It's however total negligence on part of that CA to advertise OCSP in the certificates and not having any means to live up to that promise. Revocation is one of the last defenses CAs have and that's what it's here for. It's also a critical part of any WebTrust audit. This is where the big failure is and I think it requires further investigation.
Besides that, I think despite some wrangling and shuffling, OCSP will be a requirement for any CA pretty soon, the unified standard requirement will make it easier for browser vendors to hard fail.
On Mon, Oct 12, 2009 at 8:29 AM, Daniel Veditz <dved...@mozilla.com> wrote: > An alternate approach I'd like to lobby our front-end guys on would be to > put up a scary red bar when we can't validate OCSP.
Chrome puts up a yellow bar in this case. I see this bar most commonly when at coffee shops before I've agreed to their terms of service for accessing their wireless networks. We decide make this case a hard block, we'll have to make sure we support that use case.
> On Mon, Oct 12, 2009 at 8:29 AM, Daniel Veditz<dved...@mozilla.com> wrote: >> An alternate approach I'd like to lobby our front-end guys on would be to >> put up a scary red bar when we can't validate OCSP.
> Chrome puts up a yellow bar in this case. I see this bar most > commonly when at coffee shops before I've agreed to their terms of > service for accessing their wireless networks. We decide make this > case a hard block, we'll have to make sure we support that use case.
Any chance of a big scary red bar when the browser can't validate HTTP?
On Monday 12 October 2009 16:29:23 Daniel Veditz wrote:
> On 10/12/09 3:13 AM, Rob Stradling wrote: > > Perhaps the time has come for the browsers to "force" all of the other > > CAs to take their OCSP responsibility seriously, by requiring OCSP by > > default.
> Firefox cannot take that step unilaterally, otherwise _we_ are the > broken one in users eyes.
Indeed.
> An alternate approach I'd like to lobby our front-end guys on would be > to put up a scary red bar when we can't validate OCSP. Users can still > get to their sites so they won't ditch us for another browser, site > owners are still getting traffic so they won't be breathing down _our_ > neck (too much), but the site will look a little scary and link to an > explanation so site owners can take the issue up with their CA and users > have the opportunity to decide not to submit sensitive data over the > connection.
I think that your suggestion strikes a good balance between security and useability.
Currently PSM's "When an OCSP server connection fails, treat the certificate as invalid" checkbox option can be i) checked, for a hard failure on any OCSP protocol error, or ii) unchecked, to ignore all OCSP protocol errors. I suggest retaining both of these options as well as adding your new one, which I suppose would mean changing the current checkbox into 3 radio buttons...
"When an OCSP server connection fails: o ignore the problem o show a warning (the new default) o treat the certificate as invalid"
> In the longer term we're working with browser vendors and CAs to make > OCSP support an understood requirement so that at some point in the > future we can block connections when we don't get a positive OCSP > response. (We do, of course, block connections when we get an explicit > OCSP revocation.) > _______________________________________________ > dev-security mailing list > dev-secur...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security
-- Rob Stradling Senior Research & Development Scientist C·O·M·O·D·O - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com
Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
>> An alternate approach I'd like to lobby our front-end guys on would >> be >> to put up a scary red bar when we can't validate OCSP.
> I think that your suggestion strikes a good balance between security > and > useability.
Sorry I missed this thread - Canadian thanksgiving wreaks havoc on an inbox.
This piece of this conversation sounds an awful lot like: https://bugzilla.mozilla.org/show_bug.cgi?id=496661 , and in comment 8, I outline my own thinking on the constraints under which that kind of UI would need to operate. I'm not sure I agree with Nelson in comment 11, characterizing my reply as a de facto WONTFIX, but I do feel like it's a hard line to walk. The temptation to attach UI to this problem sets off "blame the user" alarms for me - do we think that uses will make better decisions with this information? Like I say, I don't think we're at WONTFIX on this question, but I don't think it's an easy problem to solve correctly, either.
As for ipsCA, I find myself agreeing with Eddy's point: that the null bytes are a regrettable validation error that we should work with ipsCA to ensure they fix; but NXDOMAIN on an OCSP server that appears in issued certs is a bigger problem. I'm talking with Frank and Kathleen about options there. I think contacting the CA and understanding their situation is certain to be part of it. I think suspension of their trust bits is a possible outcome, but it's premature to talk about that before giving ipsCA a full chance to explain things. We break 6k cert holders if we do that, which I'll support if we don't have better options, but I don't see that we're there yet.
Do others really feel like we've exhausted other options or that attempts to communicate with the CA are fruitless?
Johnathan
--- Johnathan Nightingale Human Shield john...@mozilla.com
> As for ipsCA, I find myself agreeing with Eddy's point: that the null > bytes are a regrettable validation error that we should work with > ipsCA to ensure they fix; but NXDOMAIN on an OCSP server that appears > in issued certs is a bigger problem. I'm talking with Frank and > Kathleen about options there. I think contacting the CA and > understanding their situation is certain to be part of it. I think > suspension of their trust bits is a possible outcome, but it's > premature to talk about that before giving ipsCA a full chance to > explain things. We break 6k cert holders if we do that, which I'll > support if we don't have better options, but I don't see that we're > there yet.
> Do others really feel like we've exhausted other options or that > attempts to communicate with the CA are fruitless?
I'd like to make two practical suggestions:
A) Follow up with CRLDP finally at Firefox and implement a fail-over mechanism in case OCSP is down. For example StartCom has multiple CRLDP's at different locations for such cases. That's also important for us in case of a disaster (and recovery). Obviously it's of little help in case the software ignores it. Also obviously this doesn't allow for the current situation, it's primarily for unfortunate cases which can happen for a short time. This leads me to the second suggestion...
B) File a bug for tracking ipsCA's conduct including the \0 bug and its resolution, request follow-up with the next audit which covers the period July-October 2009 (e.g. audit of the year 2009). Perform a review discussion as we do for including a CA as soon as the audit report is available. This should be processed at a higher priority than regular inclusion requests.
#B is important because we are already month after the alleged bug happened, plenty of time to get the act together. I think this warrants some actions, a review and renewed confirmation of compliance might be a good thing to do in this case.
> On 13-Oct-09, at 2:04 AM, Rob Stradling wrote: >>> An alternate approach I'd like to lobby our front-end guys on would be >>> to put up a scary red bar when we can't validate OCSP.
>> I think that your suggestion strikes a good balance between security and >> useability.
> Sorry I missed this thread - Canadian thanksgiving wreaks havoc on an > inbox.
> This piece of this conversation sounds an awful lot like: > https://bugzilla.mozilla.org/show_bug.cgi?id=496661, and in comment 8, I > outline my own thinking on the constraints under which that kind of UI > would need to operate. I'm not sure I agree with Nelson in comment 11, > characterizing my reply as a de facto WONTFIX, but I do feel like it's a > hard line to walk. The temptation to attach UI to this problem sets off > "blame the user" alarms for me - do we think that uses will make better > decisions with this information? Like I say, I don't think we're at > WONTFIX on this question, but I don't think it's an easy problem to > solve correctly, either.
I think I agree with Nelson's comments there. If there is no revocation info in the cert, it is a CA problem, not a browser problem. It would be nice if the browser could invent a resolution here, but unfortunately, the CA made a statement, and once we start re-interpreting those statements because they upset our worldview ... then we're likely confusing the situation.
Also, while I don't see the "blame the user" aspect quite here ... it does seem as though a big scary warning for a failure of determining accurate revocation info (as opposed to an actual revocation) is likely to just lead to more click-thru syndrome.
So it still seems to point to ... patience. Not a particularly notable skill it seems :)
> As for ipsCA, I find myself agreeing with Eddy's point: that the null > bytes are a regrettable validation error that we should work with ipsCA > to ensure they fix; but NXDOMAIN on an OCSP server that appears in > issued certs is a bigger problem. I'm talking with Frank and Kathleen > about options there. I think contacting the CA and understanding their > situation is certain to be part of it. I think suspension of their trust > bits is a possible outcome, but it's premature to talk about that before > giving ipsCA a full chance to explain things. We break 6k cert holders > if we do that, which I'll support if we don't have better options, but I > don't see that we're there yet.
> Do others really feel like we've exhausted other options or that > attempts to communicate with the CA are fruitless?
The question of how to deal with apparent failures with CAs / issuances has been brought up many times, but without a conclusion or enough forward movement. As far as I can see, it lands in your lap (where here I mean the mozilla foundation CA desk, so Frank & Kathleen, including you if you're close enough).
So more patience demanded of us, I'm afraid.
But to be honest, I'm not following the ipsCA issue in detail, and probably won't until some policy question is raised.
> The temptation to attach UI to this problem sets off > "blame the user" alarms for me - do we think that uses will make better > decisions with this information? Like I say, I don't think we're at > WONTFIX on this question, but I don't think it's an easy problem to > solve correctly, either.
For the user this is merely informational (and therefore fully open to the charge of clutter). The idea is to enlist site authors/owners in pressuring CA's to step up their support so the uglybar on their site goes away. As opposed to completely blocking the site at which point the pressure is on _us_ for the CA's failure.
FWIW I'm not a big believer in trying to communicate finely graduated tiers of risk to end users either. Its already a battle trying to get users to understand the difference between a clearly valid vs invalid certificate. I use the "grandmother rule" for security dialogs... if you can't create a user experience that would result in your grandmother making the right decision, you're doing it wrong.
For the small percentage of (power) users that can really understand the implications of a question like "the OCSP URL provided by this certificate does not appear to be valid at this moment, would you like to continue", I think they are better served by flipping the Encryption->Validation setting to require a valid OCSP response for certs that provide a URL. The reason here is I think this is a choice the user should make once and its not really relevant on a per-request basis. In the end, it seems like either you are ok with the lack of an OCSP response or you are not?
That said, the way we now handle mixed content might be an option... we don't provide the blue/green domain/org info bar, so the user just gets a plain white bar (like HTTP). Maybe we could do the same thing for a broken OCSP link? Lucas.
> On 13/10/2009 18:23, Johnathan Nightingale wrote: >> On 13-Oct-09, at 2:04 AM, Rob Stradling wrote: >>>> An alternate approach I'd like to lobby our front-end guys on >>>> would be >>>> to put up a scary red bar when we can't validate OCSP.
>>> I think that your suggestion strikes a good balance between >>> security and >>> useability.
>> Sorry I missed this thread - Canadian thanksgiving wreaks havoc on an >> inbox.
>> This piece of this conversation sounds an awful lot like: >> https://bugzilla.mozilla.org/show_bug.cgi?id=496661, and in comment >> 8, I >> outline my own thinking on the constraints under which that kind of >> UI >> would need to operate. I'm not sure I agree with Nelson in comment >> 11, >> characterizing my reply as a de facto WONTFIX, but I do feel like >> it's a >> hard line to walk. The temptation to attach UI to this problem sets >> off >> "blame the user" alarms for me - do we think that uses will make >> better >> decisions with this information? Like I say, I don't think we're at >> WONTFIX on this question, but I don't think it's an easy problem to >> solve correctly, either.
> I think I agree with Nelson's comments there. If there is no > revocation info in the cert, it is a CA problem, not a browser > problem. It would be nice if the browser could invent a resolution > here, but unfortunately, the CA made a statement, and once we start > re-interpreting those statements because they upset our > worldview ... then we're likely confusing the situation.
> Also, while I don't see the "blame the user" aspect quite here ... > it does seem as though a big scary warning for a failure of > determining accurate revocation info (as opposed to an actual > revocation) is likely to just lead to more click-thru syndrome.
> So it still seems to point to ... patience. Not a particularly > notable skill it seems :)
>> As for ipsCA, I find myself agreeing with Eddy's point: that the null >> bytes are a regrettable validation error that we should work with >> ipsCA >> to ensure they fix; but NXDOMAIN on an OCSP server that appears in >> issued certs is a bigger problem. I'm talking with Frank and Kathleen >> about options there. I think contacting the CA and understanding >> their >> situation is certain to be part of it. I think suspension of their >> trust >> bits is a possible outcome, but it's premature to talk about that >> before >> giving ipsCA a full chance to explain things. We break 6k cert >> holders >> if we do that, which I'll support if we don't have better options, >> but I >> don't see that we're there yet.
>> Do others really feel like we've exhausted other options or that >> attempts to communicate with the CA are fruitless?
> The question of how to deal with apparent failures with CAs / > issuances has been brought up many times, but without a conclusion > or enough forward movement. As far as I can see, it lands in your > lap (where here I mean the mozilla foundation CA desk, so Frank & > Kathleen, including you if you're close enough).
> So more patience demanded of us, I'm afraid.
> But to be honest, I'm not following the ipsCA issue in detail, and > probably won't until some policy question is raised.
> #B is important because we are already month after the alleged bug > happened, plenty of time to get the act together. I think this warrants > some actions, a review and renewed confirmation of compliance might be a > good thing to do in this case.
These certs were revoked within days of the BlackHat talk. The leaked cert is an old cert, we are not talking about a CA clueless for the past ten weeks. IPSCA mailed us on Aug 3 that they had identified and revoked nine bogus certs and had stopped issuing any certs until they fixed their process to detect these attempts. From the domains involved we pretty much know who bought the certs, Moxie of course, and two other speakers we know about on the hacker-conference speaking circuit.
What we didn't know is that any of those three were irresponsibly handing out the private keys to the certs.
> On 10/13/09 9:23 AM, Johnathan Nightingale wrote: >> The temptation to attach UI to this problem sets off >> "blame the user" alarms for me - do we think that uses will make better >> decisions with this information? Like I say, I don't think we're at >> WONTFIX on this question, but I don't think it's an easy problem to >> solve correctly, either.
> For the user this is merely informational (and therefore fully open to > the charge of clutter). The idea is to enlist site authors/owners in > pressuring CA's to step up their support so the uglybar on their site > goes away. As opposed to completely blocking the site at which point the > pressure is on _us_ for the CA's failure.
Every CA that is engaged in EV is already under pressure.
Every CA that does standard certs is also under some pressure.
Is this really the best use of resources? Of the patience of a few million secured website users?
If you want to put CAs under pressure, ask Frank to send them all a letter outlining the OCSP situation ... and letting them know that in the future, OCSP is a popular option. Simple. One page, 100 emails.
Alternatively, if you want to do this, in order to avoid the bayesian nightmare, you're going to have to code it up, test it, then do user testing, then push it through the upgrade procedure, then deal with a flood of false positives. Then potentially unroll the lot because you got it wrong. Which is statistically likely.
If you want something more proactive, publish a list of who does great OCSP. The CA gets its logo published if it passes the test. Elsewise the red thumb, down.
> On 10/13/09 10:12 AM, Eddy Nigg wrote: >> #B is important because we are already month after the alleged bug >> happened, plenty of time to get the act together. I think this warrants >> some actions, a review and renewed confirmation of compliance might be a >> good thing to do in this case.
> These certs were revoked within days of the BlackHat talk. The leaked > cert is an old cert, we are not talking about a CA clueless for the > past ten weeks. IPSCA mailed us on Aug 3 that they had identified and > revoked nine bogus certs and had stopped issuing any certs until they > fixed their process to detect these attempts. From the domains > involved we pretty much know who bought the certs, Moxie of course, > and two other speakers we know about on the hacker-conference speaking > circuit.
> What we didn't know is that any of those three were irresponsibly > handing out the private keys to the certs.
So? I mean we are lucky that they gave us two month ahead warning before actually doing so (we can question the wisdom that they decided to release those keys, but they are grey or black hats, not white hats). That's plenty of time to fix the software and get the revocation mechanism's working. Mozilla IS aware that Firefox doesn't support CRLDP and Mozilla MUST have been also aware which CA was affected (some here knew). The CA also MUST have been aware that their OCSP responder DOES NOT WORK, it should have invested its resources in fixing that with the HIGHEST PRIORITY. Certainly into this more than two month with no resolution in sight borders on (gross) negligence.
Daniel Veditz wrote: > On 10/13/09 10:12 AM, Eddy Nigg wrote: >> #B is important because we are already month after the alleged bug >> happened, plenty of time to get the act together. I think this warrants >> some actions, a review and renewed confirmation of compliance might be a >> good thing to do in this case.
> These certs were revoked within days of the BlackHat talk.
Only because you and I separately reported the problem to them.
> The leaked cert is an old cert, we are not talking about a CA clueless for > the past ten weeks. IPSCA mailed us on Aug 3 that they had identified and > revoked nine bogus certs and had stopped issuing any certs until they fixed > their process to detect these attempts.
Yes, that is what their emails to you and me said. I believe the part about them adding 9 certs to their CRL, and them stopping the issuance of certs until they made some changes to their software that examines CSRs.
But adding certs to the CRL doesn't fully satisfy the CA's revocation duty. The certs they had issued contained OCSP extensions. Those extensions constitute a written promise to all relying parties that, if the cert is revoked, information about that revocation will be available at the given OCSP URI until the expiration date of the certificate. And that part of the promise was not, and is not now being, kept.
> From the domains involved we pretty much know who bought the certs, Moxie of > course, and two other speakers we know about on the hacker-conference > speaking circuit.
> What we didn't know is that any of those three were irresponsibly handing out > the private keys to the certs.
I submit that knowledge of who the attacker was and what his intentions were do not excuse a CA for failure to fulfill its duties to the relying parties.
> For the small percentage of (power) users that can really understand the > implications of a question like "the OCSP URL provided by this > certificate does not appear to be valid at this moment, would you like > to continue",
Just to be clear at no point did I propose a modal click-through type UI. Just a visible UI notification like an info bar, door hanger notification, a lock with a question-mark over it... something visible but not interfering. I was envisioning an info bar because that leaves us space to put some explanatory text in it, but I didn't want to get specific.
Like the slashed-lock that indicates mixed mode (and is far too subtle for my tastes) I expect a lot of users wouldn't even notice, but hope that enough will to nudge things in the right direction.
In the longer run we can get some decent non-EV CA guidelines and then switch on the hard-fail. Given Johnath's lack of love for the suggestion the longer run might be the short path.
On Tuesday 13 October 2009 17:23:12 Johnathan Nightingale wrote: <snip>
> NXDOMAIN on an OCSP server that appears in issued certs is a bigger problem <snip> > I think suspension of their trust bits is a possible outcome, but it's > premature to talk about that before giving ipsCA a full chance to explain > things. <snip> > Do others really feel like...attempts to communicate with the CA are > fruitless?
An ipsCA representative told the CABForum yesterday... "We have had some troubles with OCSP server itself. In order to avoid any misunderstanding, we have decide to remove from DNS until it is recovered. We hope OCSP service will be alive again at the end of this week."
-- Rob Stradling Senior Research & Development Scientist C·O·M·O·D·O - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com
Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
