security.OCSP.require in Firefox
Alexander Konovalenko
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.
Boris Zbarsky
> 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....
-Boris
Rob Stradling
> 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....
>
> -Boris
> _______________________________________________
> dev-security mailing list
> dev-se...@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.
Rob Stradling
> On 12/10/2009 12:13, Rob Stradling wrote:
<snip>
> > That CA clearly fell short of this requirement.
>
> 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?
> iang
Eddy Nigg
> 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.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Rob Stradling
<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.
--
Eddy Nigg
> 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.
Ian G
> On Monday 12 October 2009 12:12:22 Ian G wrote:
> <snip>
>>> That CA clearly fell short of this requirement.
>>
>> 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.
Daniel Veditz
> 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.
Daniel Veditz
> 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.)
Eddy Nigg
>
> 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.
Adam Barth
> 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.
Adam
Ian G
> On Mon, Oct 12, 2009 at 8:29 AM, Daniel Veditz<dve...@mozilla.com> wrote:
>> put up a scary red bar when we can't validate OCSP.
>
> 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?
;-)
iang
Rob Stradling
> 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.)
Johnathan Nightingale
>> 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.
>
> 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
joh...@mozilla.com
Eddy Nigg
> 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.
Ian G
> On 13-Oct-09, at 2:04 AM, Rob Stradling wrote:
>>> to put up a scary red bar when we can't validate OCSP.
>>
>> useability.
>
> Sorry I missed this thread - Canadian thanksgiving wreaks havoc on an
> inbox.
>
> This piece of this conversation sounds an awful lot like:
> 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.
iang
Daniel Veditz
> 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.
-Dan
Lucas Adamski
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 Oct 13, 2009, at 11:04 AM, Ian G wrote:
> 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.
>
>
Daniel Veditz
> #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.
Ian G
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.
iang
Eddy Nigg
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.
Nelson Bolyard
> 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.
Daniel Veditz
> 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.
-Dan
Rob Stradling
<snip>
> NXDOMAIN on an OCSP server that appears in issued certs is a bigger problem
> 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.
> 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."
Gervase Markham
> 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.
Right. The intended effect is on the site owner, not on their customers.
The site owner won't know what percentage of his customers have been
scared away by the uglybar - and that's what makes it so worrying.
Regarding mixed content, doesn't IE 8 just block the insecure content by
default, and silently? If so, can't we now switch to doing the same?
Gerv
Johnathan Nightingale
bug 62178 wants you.