Re: Firefox security too strict (HSTS?)?

[beboyabella.kallfly--- via dev-security-policy]

its been a whole day to search for a resolution. some of them i research in 
google entails with servers and stand alon computers.

and i found a solution for this issue and its works like a charm.
Solution No.2 and 3 from this website 
https://www.errorsolutions.tech/error/firefox-error-code-sec_error_unknown_issuer/

Before doing a complex troubleshooting i perform the basic first like clear 
cache, clean boot, and deleting some of my addons and i Run an malwarebytes and 
i found threats on my computer so once i remove it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Andy]

It might for you but maybe something between you're system and hers is 
different so it works for you but not for her
as my sig line says iam a computer tech i build sell service and consult.
sometimes you can have to 2 identical systems side by side and one will work 
fine and the other has problems as odd as it seems i see it daily.


-- 
AL'S COMPUTERS
"Eric Mill"  wrote in message 
news:mailman.5785.1446677903.18043.dev-security-pol...@lists.mozilla.org...
> These URLs both work in Firefox 41 and Firefox 42 (the latest, released
> yesterday) for me.
>
> -- Eric
>
> On Wed, Nov 4, 2015 at 5:20 PM, Anil G  wrote:
>
>> Yes, Eric, the issue continues, though I'm not antagonistic as you seem 
>> to
>> think, and I've never claimed to understand this space but out here in 
>> the
>> real world the issue continues and Firefox is therefore depreciated here.
>>
>> This URL https://www.anymeeting.com/Free-Web-Conferencing-Features.aspx
>> works in Firefox but this one https://www.anymeeting.com/ways-to-use/
>> doesn't. They both work in Chrome, of course.
>> Later all the anymeeting URLs stopped working in Firefox, even though I
>> was browsing around before.
>>
>> Secure Connection Failed
>> The connection to www.anymeeting.com was interrupted while the page was
>> loading.
>> The page you are trying to view cannot be shown because the authenticity
>> of the received data could not be verified.
>> Please contact the web site owners to inform them of this problem.
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
>
> -- 
> konklone.com | @konklone  


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Anil G]

Yes, Eric, the issue continues, though I'm not antagonistic as you seem to 
think, and I've never claimed to understand this space but out here in the real 
world the issue continues and Firefox is therefore depreciated here.

This URL https://www.anymeeting.com/Free-Web-Conferencing-Features.aspx works 
in Firefox but this one https://www.anymeeting.com/ways-to-use/ doesn't. They 
both work in Chrome, of course.
Later all the anymeeting URLs stopped working in Firefox, even though I was 
browsing around before.

Secure Connection Failed
The connection to www.anymeeting.com was interrupted while the page was loading.
The page you are trying to view cannot be shown because the authenticity of the 
received data could not be verified.
Please contact the web site owners to inform them of this problem.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Eric Mill]

On Wed, Sep 23, 2015 at 5:35 PM, Anil G  wrote:

> And finally, regrettably, Eric Mill: ". . . you should channel your
> passion in the direction of the enterprise IT group -- or its political
> overlords -- that are inconveniencing you and driving their users away from
> secure browsers." - mate, what can I say, you've got to switch off that
> paranoid psychotic movie you love playing to support your political bias
> and start thinking of solutions that will actually work. It may be news to
> you but my IT department didn't call the President to send teams of
> military police in riot gear through the building to move us off Firefox.
> They just answered frustrated users' phone calls with "Try Chrome".
>

My organization, a significant government agency, just told people to stop
using Chrome and Firefox (and to use Internet Explorer) for major internal
applications because of their mutual decision to drop TLS version
negotiation support for 1.0.

I channeled my passion in the direction of my IT group, explained the
security issue, and the issue is being resolved. They're fixing their
servers. It helps that "use IE" is a less viable strategy than it used to
be, and that Firefox is not -- as you've implied many times in this thread
-- taking this action alone.

Spend your energy more usefully than this thread.

-- Eric
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Anil G]

> My organization, a significant government agency, just told people to stop
> using Chrome and Firefox (and to use Internet Explorer) for major internal
> applications because of their mutual decision to drop TLS version
> negotiation support for 1.0.
> 
> I channeled my passion in the direction of my IT group, explained the
> security issue, and the issue is being resolved. They're fixing their
> servers. It helps that "use IE" is a less viable strategy than it used to
> be, and that Firefox is not -- as you've implied many times in this thread
> -- taking this action alone.
> 
> Spend your energy more usefully than this thread.
> 
> -- Eric

I will, Eric, now that I see that, I will.

I have never implied that Firefox acted alone. I just said it's harder to get 
it working. You seem to be interpreting my comments within your world view, 
possibly due to a defensive reaction to protect against a perceived criticism, 
possibly of past decisions.

I have no bone in this fight. You guys are the ones doing the hard work. I'm 
just trying to protect it from going to waste. Firefox will never be a waste in 
itself. It's been a global icon. I just want to keep it that way.

Are there two sides in Mozilla that need to forget the past and renew their 
vows and start respecting their positions? Technical guys need to do technical 
stuff and trust the strategy guys to be good at their stuff. Strategy guys need 
to be informed by tech guys so they need to listen, but everyone needs to share 
the same vision and goals. If one guy has a goal to lift security practices 
globally and another guy has a goal to get market share these goals need to be 
prioritised and managed and agreed to prevent destructive conflict. Maybe we 
need market share first and then lift practices second? Someone might have to 
wait, but better late than never.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Firefox security too strict (HSTS?)?

[Yuhong Bao]

What is also fun is that they released it two weeks before Oracle released it's 
own patch for paid Java 6/7 customers, before which the 768-bit DHE was 
hardcoded.


> Subject: Re: Firefox security too strict (HSTS?)?
> From: k...@caspia.com
> Date: Wed, 23 Sep 2015 12:17:18 -0700
> To: mozilla-dev-security-pol...@lists.mozilla.org
>
> On 9/16/2015 3:01 PM, AnilG wrote:
>> Yes, I agree. From my limited perspective and knowledge I trust you as an 
>> authority that that's probably completely correct.
>>
>> But that's not the issue. I've got a concern that security management in 
>> Firefox is too hard for enterprise and may additionally have problems for 
>> domestic users that is stopping Firefox from "working" from their 
>> perspective and significantly affecting market share.
>
> I have other concrete technical examples of where Firefox security
> management made a stricter security decision than other vendors, with no
> obvious workaround, that caused grief for users relative to other
> possible decisions.
>
> In the fix to the LOGJAM security vulnerability, one technical decision
> was the length of the accepted DH key. Mozilla decided to reject sites
> with DH key length shorter than 1023 bits. I made this comment on the
> private tb-drivers email list:
>
> "According to
> https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/:
>
> "'To protect OpenSSL-based clients, we’re increasing the minimum
> accepted DH key size to 768 bits immediately in the next release, and to
> 1024 bits soon after." and 'OpenSSL clients will reject connections with
> DH parameters shorter than 768 bits. As an unfortunately large number of
> servers use 768-bit parameters still, we’ll be giving them a short grace
> period to upgrade, with a keen eye out to raising the limit to 1024 bits
> soon. ' and 'A February TLS survey of top Alexa sites discovered 3 sites
> that prefer 512-bit DH, and 420 sites that prefer 768-bit DH. The
> 512-bit connections will now break; the 768-bit sites should urgently
> upgrade.'
>
> I don't see anyone here really engaging with AnilG about the actual
> question, which in my version of the same question was (continuing to
> quote from my tb-drivers posting) "Mozilla seems to have this habit of
> being really aggressive about these security updates, thereby making
> lots of users unhappy. We have a lot of unhappy users right now. OpenSSL
> is being slower than we are, and in general their updates are not pushed
> as aggressively as ours."
>
> Later in the same email thread I said: "Unfortunately Firefox (and as a
> result also Thunderbird) is getting a reputation for being inconsiderate
> of the needs of users in some of their security updates. In 31 there was
> the inability to override certificate problems, which ultimately was
> allowed in a dot update. Now in 38, we have Mozilla's aggressive
> approach to the DHE Logjam issue, with the 1023 bit limit hitting users
> with very little warning (while OpenSSL AFAIUI is giving admins more
> grace time to upgrade servers) ... Shutting down email access to
> hundreds of thousands of our users is a pretty severe remedy compared to
> the threat, at least in the opinion of the vast majority of our users
>  It would be better if Mozilla would learn to give a realistic
> estimate of the likely impact of new restrictions, and prepare a
> mitigation strategy, rather than just hitting users with an update that
> causes massive pain for their users to prevent some theoretical threat
> from state-level actors."
>
> My two examples (security certificate overrides in 31, DH bit length in
> 38) are other examples of historical cases where Firefox security
> policies were either reversed due to problems, or stricter than other
> vendors, resulting in user dissatisfaction.
>
> Is it possible that there is a culture issue in Mozilla security policy
> that needs addressing of a willingness to break things in the interest
> of security, beyond what users or other vendors accept as reasonable? If
> not, and we are proud of our record in all of these cases, what can be
> done to better educate the world about why all of this user grief was in
> fact for the greater good?
>
> :rkent
>
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
  
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[R Kent James]

On 9/16/2015 3:01 PM, AnilG wrote:

Yes, I agree. From my limited perspective and knowledge I trust you as an 
authority that that's probably completely correct.

But that's not the issue. I've got a concern that security management in Firefox is too 
hard for enterprise and may additionally have problems for domestic users that is 
stopping Firefox from "working" from their perspective and significantly 
affecting market share.


I have other concrete technical examples of where Firefox security 
management made a stricter security decision than other vendors, with no 
obvious workaround, that caused grief for users relative to other 
possible decisions.


In the fix to the LOGJAM security vulnerability, one technical decision 
was the length of the accepted DH key. Mozilla decided to reject sites 
with DH key length shorter than 1023 bits. I made this comment on the 
private tb-drivers email list:


"According to 
https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/:


"'To protect OpenSSL-based clients, we’re increasing the minimum 
accepted DH key size to 768 bits immediately in the next release, and to 
1024 bits soon after." and 'OpenSSL clients will reject connections with 
DH parameters shorter than 768 bits. As an unfortunately large number of 
servers use 768-bit parameters still, we’ll be giving them a short grace 
period to upgrade, with a keen eye out to raising the limit to 1024 bits 
soon. ' and 'A February TLS survey of top Alexa sites discovered 3 sites 
that prefer 512-bit DH, and 420 sites that prefer 768-bit DH. The 
512-bit connections will now break; the 768-bit sites should urgently 
upgrade.'


I don't see anyone here really engaging with AnilG about the actual 
question, which in my version of the same question was (continuing to 
quote from my tb-drivers posting) "Mozilla seems to have this habit of 
being really aggressive about these security updates, thereby making 
lots of users unhappy. We have a lot of unhappy users right now. OpenSSL 
is being slower than we are, and in general their updates are not pushed 
as aggressively as ours."


Later in the same email thread I said: "Unfortunately Firefox (and as a 
result also Thunderbird) is getting a reputation for being inconsiderate 
of the needs of users in some of their security updates. In 31 there was 
the inability to override certificate problems, which ultimately was 
allowed in a dot update. Now in 38, we have Mozilla's aggressive 
approach to the DHE Logjam issue, with the 1023 bit limit hitting users 
with very little warning (while OpenSSL AFAIUI is giving admins more 
grace time to upgrade servers) ... Shutting down email access to 
hundreds of thousands of our users is a pretty severe remedy compared to 
the threat, at least in the opinion of the vast majority of our users 
 It would be better if Mozilla would learn to give a realistic 
estimate of the likely impact of new restrictions, and prepare a 
mitigation strategy, rather than just hitting users with an update that 
causes massive pain for their users to prevent some theoretical threat 
from state-level actors."


My two examples (security certificate overrides in 31, DH bit length in 
38) are other examples of historical cases where Firefox security 
policies were either reversed due to problems, or stricter than other 
vendors, resulting in user dissatisfaction.


Is it possible that there is a culture issue in Mozilla security policy 
that needs addressing of a willingness to break things in the interest 
of security, beyond what users or other vendors accept as reasonable? If 
not, and we are proud of our record in all of these cases, what can be 
done to better educate the world about why all of this user grief was in 
fact for the greater good?


:rkent



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Eric Mill]

On Wed, Sep 23, 2015 at 3:17 PM, R Kent James  wrote:

> On 9/23/2015 1:57 PM, Eric Mill wrote:
>
>> I'd phrase it instead as: what can be done to educate people responsible
>> for deploying/buying enterprise software deployment that a rapid update
>> path for all software/protocols/ciphers/certificates is a critical
>> prerequisite for performing their job responsibly?
>>
>>
> So then what do we tell the users, who are frequently caught in the
> middle? It seems like this is what we are saying (though I am sure you will
> reword it).
>
> "I'm sorry that we broke you with our security update today so that you
> cannot do your job, but breaking you so that you complain to your web (or
> email) hosts is the only way we can get the attention of the people who
> have the power to fix this. Thank you for suffering for the greater good."
>
> Might there be some alternative, like a big red popup that appears for a
> couple of weeks with a warning and an option to continue?
>
> "Chrome does it" is no better defense against user pain than "IE doesn't
> do it" is an excuse to accept garbage security. We are supposed to be user
> focused, our users suffer in this, and perhaps we could be innovative in
> reducing the pain and still accomplish our goals.


It may be less satisfying, but I think you should channel your passion in
the direction of the enterprise IT group -- or its political overlords --
that are inconveniencing you and driving their users away from secure
browsers.

-- Eric


>
>
> :rkent
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[R Kent James]

On 9/23/2015 1:57 PM, Eric Mill wrote:

I'd phrase it instead as: what can be done to educate people responsible
for deploying/buying enterprise software deployment that a rapid update
path for all software/protocols/ciphers/certificates is a critical
prerequisite for performing their job responsibly?



So then what do we tell the users, who are frequently caught in the 
middle? It seems like this is what we are saying (though I am sure you 
will reword it).


"I'm sorry that we broke you with our security update today so that you 
cannot do your job, but breaking you so that you complain to your web 
(or email) hosts is the only way we can get the attention of the people 
who have the power to fix this. Thank you for suffering for the greater 
good."


Might there be some alternative, like a big red popup that appears for a 
couple of weeks with a warning and an option to continue?


"Chrome does it" is no better defense against user pain than "IE doesn't 
do it" is an excuse to accept garbage security. We are supposed to be 
user focused, our users suffer in this, and perhaps we could be 
innovative in reducing the pain and still accomplish our goals.


:rkent
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Eric Mill]

Except in both of these cases -- removing TLS fallback to v1.0, and raising
DH parameter minimums -- Chrome joined Firefox in doing so. Firefox went
out first, and so that was the first impression people got, but Chrome's
policies are no less strict. In at least some enterprises, "everyone use
IE" is no longer a viable long-term recommendation, and I get the strong
sense that Chrome and Firefox's positions will force positive change. I
definitely see it happening around me.

-- Eric

On Wed, Sep 23, 2015 at 1:17 PM, R Kent James  wrote:

> On 9/16/2015 3:01 PM, AnilG wrote:
>
>> Yes, I agree. From my limited perspective and knowledge I trust you as an
>> authority that that's probably completely correct.
>>
>> But that's not the issue. I've got a concern that security management in
>> Firefox is too hard for enterprise and may additionally have problems for
>> domestic users that is stopping Firefox from "working" from their
>> perspective and significantly affecting market share.
>>
>
> I have other concrete technical examples of where Firefox security
> management made a stricter security decision than other vendors, with no
> obvious workaround, that caused grief for users relative to other possible
> decisions.
>
> In the fix to the LOGJAM security vulnerability, one technical decision
> was the length of the accepted DH key. Mozilla decided to reject sites with
> DH key length shorter than 1023 bits. I made this comment on the private
> tb-drivers email list:
>
> "According to
> https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/
> :
>
> "'To protect OpenSSL-based clients, we’re increasing the minimum accepted
> DH key size to 768 bits immediately in the next release, and to 1024 bits
> soon after." and 'OpenSSL clients will reject connections with DH
> parameters shorter than 768 bits. As an unfortunately large number of
> servers use 768-bit parameters still, we’ll be giving them a short grace
> period to upgrade, with a keen eye out to raising the limit to 1024 bits
> soon. ' and 'A February TLS survey of top Alexa sites discovered 3 sites
> that prefer 512-bit DH, and 420 sites that prefer 768-bit DH. The 512-bit
> connections will now break; the 768-bit sites should urgently upgrade.'
>
> I don't see anyone here really engaging with AnilG about the actual
> question, which in my version of the same question was (continuing to quote
> from my tb-drivers posting) "Mozilla seems to have this habit of being
> really aggressive about these security updates, thereby making lots of
> users unhappy. We have a lot of unhappy users right now. OpenSSL is being
> slower than we are, and in general their updates are not pushed as
> aggressively as ours."
>
> Later in the same email thread I said: "Unfortunately Firefox (and as a
> result also Thunderbird) is getting a reputation for being inconsiderate of
> the needs of users in some of their security updates. In 31 there was the
> inability to override certificate problems, which ultimately was allowed in
> a dot update. Now in 38, we have Mozilla's aggressive approach to the DHE
> Logjam issue, with the 1023 bit limit hitting users with very little
> warning (while OpenSSL AFAIUI is giving admins more grace time to upgrade
> servers) ... Shutting down email access to hundreds of thousands of our
> users is a pretty severe remedy compared to the threat, at least in the
> opinion of the vast majority of our users  It would be better if
> Mozilla would learn to give a realistic estimate of the likely impact of
> new restrictions, and prepare a mitigation strategy, rather than just
> hitting users with an update that causes massive pain for their users to
> prevent some theoretical threat from state-level actors."
>
> My two examples (security certificate overrides in 31, DH bit length in
> 38) are other examples of historical cases where Firefox security policies
> were either reversed due to problems, or stricter than other vendors,
> resulting in user dissatisfaction.
>
> Is it possible that there is a culture issue in Mozilla security policy
> that needs addressing of a willingness to break things in the interest of
> security, beyond what users or other vendors accept as reasonable? If not,
> and we are proud of our record in all of these cases, what can be done to
> better educate the world about why all of this user grief was in fact for
> the greater good?
>
> :rkent
>
>
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Eric Mill]

On Wed, Sep 23, 2015 at 2:55 PM, R Kent James  wrote:

> On 9/23/2015 1:25 PM, Eric Mill wrote:
>
>> Except in both of these cases -- removing TLS fallback to v1.0, and
>> raising
>> DH parameter minimums -- Chrome joined Firefox in doing so. Firefox went
>> out first, and so that was the first impression people got, but Chrome's
>> policies are no less strict. In at least some enterprises, "everyone use
>> IE" is no longer a viable long-term recommendation, and I get the strong
>> sense that Chrome and Firefox's positions will force positive change. I
>> definitely see it happening around me.
>>
>> -- Eric
>>
>>
> So then perhaps you can address the second half of my question, since that
> seems to be the position that you take:
>
> "If not, and we are proud of our record in all of these cases, what can be
> done to better educate the world about why all of this user grief was in
> fact for the greater good?"
>

I'd phrase it instead as: what can be done to educate people responsible
for deploying/buying enterprise software deployment that a rapid update
path for all software/protocols/ciphers/certificates is a critical
prerequisite for performing their job responsibly?


>
> :rkent
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[R Kent James]

On 9/23/2015 1:25 PM, Eric Mill wrote:

Except in both of these cases -- removing TLS fallback to v1.0, and raising
DH parameter minimums -- Chrome joined Firefox in doing so. Firefox went
out first, and so that was the first impression people got, but Chrome's
policies are no less strict. In at least some enterprises, "everyone use
IE" is no longer a viable long-term recommendation, and I get the strong
sense that Chrome and Firefox's positions will force positive change. I
definitely see it happening around me.

-- Eric



So then perhaps you can address the second half of my question, since 
that seems to be the position that you take:


"If not, and we are proud of our record in all of these cases, what can 
be done to better educate the world about why all of this user grief was 
in fact for the greater good?"


:rkent


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Anil G]

How happy am I that R Kent James finally recognises my issue? After more than 
30 posts we're finally talking about it. Does the resistance showing here 
indicate the cultural problem that R Kent James refers to?

I don't know if I'm reading these posts right but, kindly:

Michael Stroder: "within Mozilla every security code is regarded as obstacle" - 
maybe there *are* too many security obstacles?

R Kent James: "causes massive pain for their users" - no pain for our users, 
they just moved onto Chrome.

R Kent James: "We have a lot of unhappy users right now" - we have no users 
right now, in my organisation.

Michael Stroder: "frustrating . . . a waste of time . . . within Mozilla" - 
does this indicate an internal split / disfunction which is preventing 
co-operation between strategy and technical to solve the problems in 
user-viable way? I think this may be the solution: Mozilla team need to work 
together.

Eric Mill, I think this is the problem I'm identifying: "what can be done to 
educate people responsible for deploying/buying enterprise software deployment 
that a rapid update path for all software/ protocols/ ciphers/ certificates is 
a critical prerequisite for performing their job responsibly?" - network 
engineers are users too, and in a busy work environment when faced with complex 
security issues that they're not familiar with and late nights every day of the 
week solving user tickets that are back-logging while they try to rush the 
roll-out to please management instead of going home to their kids they do the 
responsible thing: switch users to Chrome and go home (or test it in IE because 
that's what the boss uses and call it a night?).

I'm talking about "user viable" here. It's not a matter of "user friendly" 
anymore. If Firefox is coded to deliberately not work unless something is 
fixed, and no-one knows how to fix it (in the time they've been allocated - 
like minus 30 minutes), then Firefox *will* deliberately not work.

And when Firefox *does not work* then the user does what the network guys did 
last year: switch to Chrome. He doesn't sit there "in pain" because he'll lose 
his job. I don't know about you but I can't go 24 hours without a working 
browser. I can go 24 minutes by having a coffee and a leak. At one point I was 
submitting these posts with Chrome. Many users just won't go back.

And, finally, R Kent James: "culture issue in Mozilla security policy . . . 
willingness to break things in the interest . . . what can be done to better 
educate the world about why all of this user grief was in fact for the greater 
good?" -

The movie that's playing in my world is a slow motion train wreck.
It's no longer a matter of educating others, as if Mozilla was being lauded and 
followed for their leadership (Mozilla doesn't rule at least not yet), it's a 
matter of survival.
The Chrome trajectory is up. The Mozilla trajectory is a steady reliable down. 
They crossed in the middle. It's a big X!
Mozilla needs decisive and significant steering input and, sorry to put it this 
way but, stop harping on about security of the web and start getting the 
browser to function with real world web sites and network engineers as a 
priority, first.

And finally, regrettably, Eric Mill: ". . . you should channel your passion in 
the direction of the enterprise IT group -- or its political overlords -- that 
are inconveniencing you and driving their users away from secure browsers." - 
mate, what can I say, you've got to switch off that paranoid psychotic movie 
you love playing to support your political bias and start thinking of solutions 
that will actually work. It may be news to you but my IT department didn't call 
the President to send teams of military police in riot gear through the 
building to move us off Firefox. They just answered frustrated users' phone 
calls with "Try Chrome".

Thanks Ryan Sleevi for your gentle encouragement.

The one thing I'd like to say is that this may be a dual problem and the 
current discussion just addresses the first part: deliberate non-function. I'm 
not clear (but you guys should be) but the second part looks to me like there 
may be ways in which Firefox is harder to administer or fiddle into operability 
which is disadvantaging it. That's another aspect where Mozilla team would 
presumably need to work as a tight, cohesive, respectful and loyal team and dig 
deep to find ways to make Firefox a complete breeze to administer or work with. 
The Firefox internal cert store issue I presented with comes into this category.

God help you guys and thanks for your responses.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Anil G]

> > To make my point again, I can't access https://input.mozilla.org/en-US/ 
> > from Firefox, I have to use Chrome.
> In Chrome, navigate to https://input.mozilla.org/en-US/ 
>  and then click the green lock.  Click on 
> the "Connection" tab then cut and paste the first couple of sentences.
> Thanks,
> Peter

With thanks to Yuhong Bao and Peter Gutman, yes, I am behind enterprise network 
behaving like MITM, but that's my point. I've only recently just supported IT 
to correct MITM cert distribution and we still have issues like this. But none 
of these issues affected Chrome. Chrome works for enterprise out of the box.

With thanks to Peter Bowen, answers below, but please note I'm not asking this 
forum to fix my Firefox. I'm suggesting that there may be a long term problem 
for Firefox not operating easily enough to prevent it getting excluded from 
enterprises and homes just on this basis alone.

At https://input.mozilla.org/en-US/ Chrome says "The identity of Mozilla 
Foundation at Mountain View, California US has been verified by DigiCert SHA2 
Extended Validation Server CA. Valid Certificate Transparency information was 
supplied by the server." and "Your connection to input.mozilla.org is encrypted 
using a modern cipher suite. The connection uses TLS 1.2. The connection is 
encrypted and authenticated using AES_128_GCM and uses ECDHE_RSA as the key 
exchange mechanism."

After I re-tried in Firefox, after a delay of a few minutes, it eventually 
shows the page. Firefox is showing the page now. But originally attempting the 
URI gives the message I shared, and continuous to give it even when pushing 
hard refreshes a few times.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Eric Mill]

Small note, to correct a misunderstanding from earlier in the thread --
even if *.mozilla.org were doing key pinning, Chromium/Chrome will ignore
key pins if the observed cert chains up to a user/enterprise-installed
root. So that wouldn't cause any issues.

-- Eric

On Fri, Sep 18, 2015 at 12:06 AM, Yuhong Bao 
wrote:

> >> On Sep 17, 2015, at 8:29 PM, AnilG  wrote:
> >>
> >> On Friday, 18 September 2015 12:29:46 UTC+10, Peter Gutmann wrote:
> >>> base. If you look at Mozilla's own figures at
> >>> https://input.mozilla.org/en-US/, they have a 90% dissatisfaction
> rating from
> >>
> >> To make my point again, I can't access https://input.mozilla.org/en-US/
> from Firefox, I have to use Chrome.
> >
> > Can you do a quick test to help understand the likely root cause of your
> issue?
> >
> > In Chrome, navigate to https://input.mozilla.org/en-US/ <
> https://input.mozilla.org/en-US/> and then click the green lock. Click on
> the “Connection” tab then cut and paste the first couple of sentences.
> >
> > It should say something like “The identity of […] has been verified by
> […]. […] information was supplied by the server.”
> >
> > That will help determine what is causing your problem.
>
> Also see if it has something about TLS version fallback. Chrome is still
> doing TLS 1.1 version fallback and it might be hiding the problem at the
> MITM.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[AnilG]

On Thursday, 17 September 2015 10:11:06 UTC+10, Daniel Micay  wrote:
> Chrome has pinning too . . . I don't think lack of support
> for MITM attacks is a bug that should be addressed. It's a security
> liability even when used internally by an organization.

Thanks for your contribution, Daniel.

I recognise that I don't fully understand the significance of everything you've 
said, but because it's not that clear from my original post, I just wanted to 
comment that this request is not really about fixing my firefox.

My main concern here is to check with or raise with the Mozilla management - 
have you evaluated how hard it is to use Firefox in some situations probably 
due to particular ways or implementations of security management in Firefox?

This is really big picture here: I've looked up and suddenly seen Firefox 
market share trajectory looking like we need some steering input fast. This is 
a 3 to 6 year picture of decline so it will take as long to correct.

There are circumstantial indicators that could imply particular handling of 
security is the most significant easily fixable cause (of the market share 
decline). That's what I'm raising.

I'm beginning to feel like no-one's noticed this question yet. Is there anyone 
on this thread who can understand what I'm saying? Is there a better group to 
take this to? mozilla.strategy? I thought security.policy would be strategy 
central on security choices and how implementations impact users?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Firefox security too strict (HSTS?)?

[Peter Gutmann]

AnilG  writes:

>This is really big picture here: I've looked up and suddenly seen Firefox
>market share trajectory looking like we need some steering input fast. This
>is a 3 to 6 year picture of decline so it will take as long to correct.

Oh dear, this is really going to open a can of worms that probably shouldn't
be opened, I'll try and make this my one and only comment on the topic to
avoid a flamefest, but this does need to be corrected: The unstoppable slide
of Firefox towards a zero market share has nothing to do with HSTS and other
stuff and everything to do with the fact that it's been turned into a bloated
copy of Google Chrome, with an endless succession of disastrously bad
decisions that have progressively alienated more and more of its loyal user
base.  If you look at Mozilla's own figures at
https://input.mozilla.org/en-US/, they have a 90% dissatisfaction rating from
their own users (I was going to use a political comparison there but can't
actually find either a politician or corporation who has an approval rating
that low).  Slashdot (yeah, I know, but it is a reasonable indicator of geek
opinion) recently introduced a story on Firefox with the comment "for once a
story about a Firefox change that isn't negative".

I don't think it's worth trying to appeal to Mozilla, because it's a toss-up
whether they'll drop to zero percent market share naturally or drive it to
zero when they discontinue their plugin API (XPCOM and XUL), the only reason
for still staying with Firefox.  So the organisation you want to negotiate
with is whoever forks Firefox and reboots it, not the one that's currently
running it into the ground.  The "correction" will be when it's forked and
saved by others, in the same way that Phoenix was forked and saved from
Netscape.

(Apologies to the Mozilla security folks reading this, I know you guys do a
good job on your part of the browser, but seeing Mozilla slowly run their
flagship product into the ground has been like watching a train wreck one
freeze-frame at a time).

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Firefox security too strict (HSTS?)?

[Yuhong Bao]

> On Friday, 18 September 2015 12:29:46 UTC+10, Peter Gutmann wrote:
>> base. If you look at Mozilla's own figures at
>> https://input.mozilla.org/en-US/, they have a 90% dissatisfaction rating from
>
> To make my point again, I can't access https://input.mozilla.org/en-US/ from 
> Firefox, I have to use Chrome.
>
> My "secure connection failed" because "the authenticity of the received data 
> could not be verified".

Can you post a full screenshot or at least the error code?  
  
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Peter Bowen]

> On Sep 17, 2015, at 8:29 PM, AnilG  wrote:
> 
> On Friday, 18 September 2015 12:29:46 UTC+10, Peter Gutmann  wrote:
>> base.  If you look at Mozilla's own figures at
>> https://input.mozilla.org/en-US/, they have a 90% dissatisfaction rating from
> 
> To make my point again, I can't access https://input.mozilla.org/en-US/ from 
> Firefox, I have to use Chrome.

Can you do a quick test to help understand the likely root cause of your issue?

In Chrome, navigate to https://input.mozilla.org/en-US/ 
 and then click the green lock.  Click on the 
“Connection” tab then cut and paste the first couple of sentences.

It should say something like “The identity of […] has been verified by […]. […] 
information was supplied by the server.”

That will help determine what is causing your problem.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Firefox security too strict (HSTS?)?

[Yuhong Bao]

>> On Sep 17, 2015, at 8:29 PM, AnilG  wrote:
>>
>> On Friday, 18 September 2015 12:29:46 UTC+10, Peter Gutmann wrote:
>>> base. If you look at Mozilla's own figures at
>>> https://input.mozilla.org/en-US/, they have a 90% dissatisfaction rating 
>>> from
>>
>> To make my point again, I can't access https://input.mozilla.org/en-US/ from 
>> Firefox, I have to use Chrome.
>
> Can you do a quick test to help understand the likely root cause of your 
> issue?
>
> In Chrome, navigate to https://input.mozilla.org/en-US/ 
>  and then click the green lock. Click on 
> the “Connection” tab then cut and paste the first couple of sentences.
>
> It should say something like “The identity of […] has been verified by […]. 
> […] information was supplied by the server.”
>
> That will help determine what is causing your problem.

Also see if it has something about TLS version fallback. Chrome is still doing 
TLS 1.1 version fallback and it might be hiding the problem at the MITM.
   
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[AnilG]

On Friday, 18 September 2015 12:29:46 UTC+10, Peter Gutmann  wrote:
> AnilG writes:
> 
> >This is really big picture here: I've looked up and suddenly seen Firefox
> >market share trajectory looking like we need some steering input fast. This
> >is a 3 to 6 year picture of decline so it will take as long to correct.
> 
> Oh dear, this is really going to open a can of worms that probably shouldn't
> be opened . . .

Thanks for responding to my question, Peter.

What I'm proposing here though, whether or not anyone agrees with your context, 
is could it be that:

1. the difficulty of administering Firefox in an enterprise environment
2. and other security related behaviours in the domestic environment

are aspects of Firefox that:

1. could have been having the effect of cutting Firefox out of the game 
(because the rest of the world "couldn't keep up")
2. can be feasibly changed in the next year to "get back onto the pitch"

I don't have the knowledge or context that Peter (anyone here) has but it looks 
to me like there's still a lot of folks who love Firefox. I think it's still 
the world's best browser, but it was disconcerting to me when I couldn't 
physically use it because it simply stopped working.

I put in the yards to get my Firefox back out to the internet, using Chrome 
meanwhile. Other users would have flipped off Firefox to Chrome and never 
looked back.

Also in the domestic area, if a user finds Firefox "stops working sometimes" 
when Chrome "still works", he may switch to Chrome and never go back.

That's the restricted scope of this proposal. I'm not saying fix anything, just 
can we put Firefox at the same pace of the rest of the world with respect to 
security so that it (kind of) never fails to show a page that Chrome can show 
and works out of the box for enterprise roll outs?

It looks to me like these are the two most significant market share killers in 
the box.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[AnilG]

On Friday, 18 September 2015 12:29:46 UTC+10, Peter Gutmann  wrote:
> base.  If you look at Mozilla's own figures at
> https://input.mozilla.org/en-US/, they have a 90% dissatisfaction rating from

To make my point again, I can't access https://input.mozilla.org/en-US/ from 
Firefox, I have to use Chrome.

My "secure connection failed" because "the authenticity of the received data 
could not be verified".

I note that the sad faces aren't broken down by type of reason but a fair few 
of the first page comments are about operational problems like "wouldn't work".

This is the same problem I'm raising. If Firefox doesn't work when Chrome does, 
many types of users will stop using Firefox and start using Chrome.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[AnilG]

Co-incidentally, now that I've resolved that certificate problem, I am now 
getting an issue connecting to 
https://support.mozilla.org/1/firefox/40.0.3/Darwin/en-GB/clicktoplay

Secure Connection Failed
The connection to support.mozilla.org was interrupted while the page was 
loading.
The page you are trying to view cannot be shown because the authenticity of the 
received data could not be verified.
Please contact the web site owners to inform them of this problem.

I suspect our proxy behaviour is preventing access but Chrome accesses this URI 
with a green padlock in the address bar. Other domains are also affected.

I'd also personally like to breakdown the issues we are experiencing that 
unintentionally block this URI in this same context to see if it's relevant and 
important.


On Wednesday, 16 September 2015 08:42:33 UTC+10, AnilG  wrote:
> My point is that Firefox will be no good for the web if no one is using it.
> 
> . . . I'm just saying with respect to this particular _kind of issue_ (I know 
> of 2 instances that hit my organisation that accomplished full removal of 
> Firefox over 3 years) it looks to me like this could be one _kind of issue_ 
> where known solutions exist and can be having a big influence on Firefox 
> usage, significantly out of proportion to the effort and ability to fix it; 
> have you evaluated the threat?
 
> On Tuesday, 15 September 2015 19:21:26 UTC+10, Gervase Markham  wrote:
> > On 15/09/15 01:12, Anil Gulati wrote:
> > > To remove unnecessary impediments to Firefox use and adoption wouldn't it
> > > make sense to configure Firefox to use the OS cert store by default, and
> > > allow an option to use internal cert database? 
> > 
> > We would love it if the OS would give us a list of _just_ the
> > user-installed certs, but as far as we are aware, this is not possible
> > on Windows.
> > 
> > See https://bugzilla.mozilla.org/show_bug.cgi?id=432802 for more details.
> > 
> > As I noted there, due to these API problems, "recognizing the Windows
> > trust store is equivalent to abandoning our own root program and
> > adopting whatever Microsoft decides (because we can't tell which certs
> > are user-imported and which are MS-provided). That would not be a good
> > thing for the web."
> > 
> > Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Kathleen Wilson]

On 9/16/15 1:13 AM, Kurt Roeckx wrote:

I think they can distribute the certificate for use by chrome and
internet explorer by using the group policy and so it's trivial for them
to distribute it to all the PCs.  It might be a little bit more
complicated to do the same for Firefox.



We have some pointers about this here:

https://wiki.mozilla.org/CA:FAQ#How_do_I_import_a_root_cert_into_NSS_on_our_organization.27s_internal_servers.3F

and

https://wiki.mozilla.org/CA:AddRootToFirefox


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Kurt Roeckx]

On Wed, Sep 16, 2015 at 02:51:28PM -0700, AnilG wrote:
> 
> there's another issue blocking them for Firefox: Secure Connection Failed. 
> The connection to wiki.mozilla.org was interrupted while the page was loading.

I wonder if firefox is using certificate pinning for
*.mozilla.org.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[AnilG]

On Thursday, 17 September 2015 08:02:21 UTC+10, David Keeler  wrote:
> On 09/16/2015 02:51 PM, AnilG wrote:
> > Thanks Kathleen, those links might be helpful. I'm following them up in 
> > Chrome because there's another issue blocking them for Firefox: Secure 
> > Connection Failed. The connection to wiki.mozilla.org was interrupted while 
> > the page was loading. The page you are trying to view cannot be shown 
> > because the authenticity of the received data could not be verified. Please 
> > contact the web site owners to inform them of this problem.
> 
> Try setting the pref "security.tls.version.fallback-limit" to 1. It may
> be that the TLS-intercepting proxies (MITM boxes) you're behind are TLS
> 1.2-intolerant.

Thanks David, that's a hot tip. "Unfortunately" that issue on those links has 
"fixed itself" over 24 hours, so I can't test. I'm keeping my fallback-limit to 
3 and recording the action in case I can use it in future.

I'm very grateful for all the personal support I've got here but the issue I'm 
promoting is that in all these cases Chrome didn't have the impediments to 
simply getting out of the site and viewing the web. Hence Chrome now rules here.

Is this a (high level) issue that Mozilla is taking seriously?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[David Keeler]

On 09/16/2015 02:51 PM, AnilG wrote:
> Thanks Kathleen, those links might be helpful. I'm following them up in 
> Chrome because there's another issue blocking them for Firefox: Secure 
> Connection Failed. The connection to wiki.mozilla.org was interrupted while 
> the page was loading. The page you are trying to view cannot be shown because 
> the authenticity of the received data could not be verified. Please contact 
> the web site owners to inform them of this problem.

Try setting the pref "security.tls.version.fallback-limit" to 1. It may
be that the TLS-intercepting proxies (MITM boxes) you're behind are TLS
1.2-intolerant.



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[sjw]

Yes, some hosts are pinned:
https://dxr.mozilla.org/mozilla-central/source/security/manager/tools/PreloadedHPKPins.json

MITM is *always* bad and breaks the web. Modern browsers, especially
Firefox, have great features to protect the users and this is something
good. I'm pretty sure your students don't even know, that you attack
their connection to the Internet.
You may have no influence on the decision why you have to do this
(mostly because of surveillance and censorship), but this a political
discussion and there are many issues on this topic. I have no wish to
comment this further.


Am 16.09.2015 um 23:57 schrieb Kurt Roeckx:
> On Wed, Sep 16, 2015 at 02:51:28PM -0700, AnilG wrote:
>> there's another issue blocking them for Firefox: Secure Connection Failed. 
>> The connection to wiki.mozilla.org was interrupted while the page was 
>> loading.
> I wonder if firefox is using certificate pinning for
> *.mozilla.org.
>
>
> Kurt
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy




signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[AnilG]

On Thursday, 17 September 2015 09:27:15 UTC+10, s...@gmx.ch  wrote:
> MITM is *always* bad and breaks the web. Modern browsers, especially
> Firefox, have great features to protect the users and this is something
> good. I'm pretty sure your students don't even know, that you attack
> their connection to the Internet.
> You may have no influence on the decision why you have to do this
> (mostly because of surveillance and censorship), but this a political
> discussion and there are many issues on this topic. I have no wish to
> comment this further.

Yes, thanks, sjw, I understand that, and suspect we might probably agree on 
some of _those_ issues you hint at, but that's not the issue I'm raising here.

Of course, I'm not disputing Firefox should defeat MITM (!) but I'm comparing 
how, apparently, easily and reliably, from an _administration_ point of view, 
Chrome does that - leading to the extinction of Firefox from enterprise.

I'm not pretending to be able to take the planning and management of this away 
from you guys. You are clearly authoritative. But I am wondering - have you 
evaluated the threat?

I'm just saying - it looks like there may be a problem out there, and it could 
be a big one - actual operational continuity.

What's the vision for Firefox? Lead browser or niche player? Have you evaluted 
the threat?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Daniel Micay]

Chrome has pinning too (in fact, Firefox's baseline list for HSTS and
pinning is extracted from there). AFAIK, Mozilla just didn't ask for
their domains to be pinned in Chromium. I don't think lack of support
for MITM attacks is a bug that should be addressed. It's a security
liability even when used internally by an organization.

The system certificate store is used for everything else, so if you're
not looking at the bigger picture it has little value. However, it does
have real value because it provides a lot of leverage with the CAs via
the browser's usage share. It's also the system certificate store on
many platforms (Linux, *BSD) and using it universally keeps it tested
and maintained.



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[AnilG]

Thanks Gerv, I take your point. I think I do get a list of user certs from 
Keychain on Mac but I suppose that may not modify your response from a coding 
point of view.

My point is that Firefox will be no good for the web if no one is using it.

1. I have seen Firefox go from recommended browser to eliminated from my 
organisation over a period of about 3 years due to this and one other "strict 
security" "issue". (1 or 2 of us left, but I doubt there's anyone else other 
than me, actually).

2. I have seen intimations that similar experiences are appearing on forums.

3. These people love Firefox, think Firefox is the best for the web, and don't 
want to lose it. Have you evaluated the threat? Are you happy for Firefox to be 
eliminated from enterprise and become a domestic only browser, and possibly to 
lose significant market share in the domestic market too, with a long term 
worst case of Firefox becoming a niche browser like Opera?

I don't have the information to assess accurately, but I'm hoping you do. It's 
hard to link particular issues with actual drop in share but with an open mind 
and some research I thinking making some intuitive guesses gives probable 
solutions (which are better than none).

Even W3 schools, which I would expect to be a core Firefox stronghold from a 
dev point of view, shows 2 points loss this half year and a slight S curve from 
almost 50% share in 2009, with 6 / 7 % losses per year from 2010 - 2012 and 
reliable minimum 3% loss per year since then, by this unrepresentative generous 
sampling method. Firefox is now down to 40% of it's 2009 share. That's 60% loss 
of original share over the last 6 years.

I know this is a complex issue. I'm not saying I have certainties or have your 
level of understanding of the history. I'm not asking for an explanation of 
Firefox decline, I'm just saying with respect to this particular _kind of 
issue_ (I know of 2 instances that hit my organisation that accomplished full 
removal of Firefox over 3 years) it looks to me like this could be one _kind of 
issue_ where known solutions exist and can be having a big influence on Firefox 
usage, significantly out of proportion to the effort and ability to fix it; 
have you evaluated the threat?

On Tuesday, 15 September 2015 19:21:26 UTC+10, Gervase Markham  wrote:
> On 15/09/15 01:12, Anil Gulati wrote:
> > To remove unnecessary impediments to Firefox use and adoption wouldn't it
> > make sense to configure Firefox to use the OS cert store by default, and
> > allow an option to use internal cert database? 
> 
> We would love it if the OS would give us a list of _just_ the
> user-installed certs, but as far as we are aware, this is not possible
> on Windows.
> 
> See https://bugzilla.mozilla.org/show_bug.cgi?id=432802 for more details.
> 
> As I noted there, due to these API problems, "recognizing the Windows
> trust store is equivalent to abandoning our own root program and
> adopting whatever Microsoft decides (because we can't tell which certs
> are user-imported and which are MS-provided). That would not be a good
> thing for the web."
> 
> Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Gervase Markham]

On 15/09/15 01:12, Anil Gulati wrote:
> To remove unnecessary impediments to Firefox use and adoption wouldn't it
> make sense to configure Firefox to use the OS cert store by default, and
> allow an option to use internal cert database? 

We would love it if the OS would give us a list of _just_ the
user-installed certs, but as far as we are aware, this is not possible
on Windows.

See https://bugzilla.mozilla.org/show_bug.cgi?id=432802 for more details.

As I noted there, due to these API problems, "recognizing the Windows
trust store is equivalent to abandoning our own root program and
adopting whatever Microsoft decides (because we can't tell which certs
are user-imported and which are MS-provided). That would not be a good
thing for the web."

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Anil Gulati]

Thanks again, Chris. I've solved the problem and this sheds some light.

I found the cert in the Mac OS X Keychain app and exported it from there.
It exported with a different embedded CN for issuer and subject. The
original raw cert I imported into Firefox seemed to have arbitrary free
text in the CN which evidently was making it ineffective.

The cert was installed into Mac OS X keychain by a package, but IT told me
the package did not change or provide parameters, so I don't know how the
cert got the right CN when installing into OS X. Either way, the cert
exported from Mac OS X keychain did have correct CN and then worked like a
charm when imported into Firefox.

So I'd agree Firefox is not being too strict (in this scenario anyway - I
had previous issues a few months ago where Chrome worked and Firefox
didn't) but Firefox does have the additional step to install certs in it's
own certificate database instead of referring to the OS. In our case this
additional step was hard enough to prevent Firefox from working for several
days. I guess if there were any Firefox users in our organisation before it
seems unlikely there are any left now.

I wonder if this is the second issue that is harming Firefox market share.
As I said I had issues previously where Chrome became organisation
preferred because it "worked". I managed to find a workaround for Firefox
but other users wouldn't have bothered. Unfortunately I don't have a
breakdown on the causes of that issue.

I guess market share shouldn't necessarily be a driver for the Firefox
strategy, but we need market share to ensure vitality and *long term
operational continuity*. It doesn't matter how good Firefox is if it's not
being used (or doesn't "work" from an industry perspective).

To remove unnecessary impediments to Firefox use and adoption wouldn't it
make sense to configure Firefox to use the OS cert store by default, and
allow an option to use internal cert database? I know there's code costs
but if people are not using Firefox there's no Firefox. Even now our IT has
a working cert I'm not sure they have a way to automatically install into
Firefox for all users. I presume enterprises normally don't. So now that
this "issue" has slaughtered any remaining Firefox users we may have had
left from the previous issue, even though we now have a solution, we'll
probably not regain any market share here, unless I find a user and
personally install a cert for him/her. IT support may also be fed up to the
extent we won't have a Firefox install on new laptop images.

This is the picture we have in our organisation. It's been devastating. I'm
not sure how much this is replicated globally but I'm communicating back
here as properly as I can because I've caught hints that similar concerns
have been raised on forums and I want to do what I can to ensure that
Mozilla is not insulated from the true picture out in the community.

Thanks for all your attention.

On 15 September 2015 at 04:44, Chris Palmer  wrote:

> On Sun, Sep 13, 2015 at 2:56 PM, AnilG  wrote:
>
> Thanks Chris, I'll follow up with IT on this question.
>>
>
> You can check yourself if the chain you see chains up to the right root.
> In Chrome, click on the lock icon in the location bar, click the Connection
> Tab, and then click "Certificate information". This opens the Certificate
> Viewer. There, click the Details Tab and inspect the Certificate Hierarchy
> and each certificate's Certificate Fields. The root certificate should
> match the certificate your IT department gave you.
>
> Sounds like something basic but perhaps not so obvious if the IT preferred
>> (and test) browser (Chrome) is more permissive? But surely this is so basic
>> that (even) Chrome can't pretend a site is secured if there's no link to
>> the root certificate?
>>
>
> Chrome is not known for being permissive about certificate checking. :)
> And no, it's (I hope) very unlikely that Chrome is calling a certificate OK
> even without being able to chain to a root in your machine's root
> certificate store. You can verify that by following the steps above.
>
> Also, what does Safari do?
>
> I'm also following this up on evangelism@moz. I've got the impression
>> that there's global dissatisfaction with FF being "too strict" and it
>> *seems* like it's harder to get FF to "work" for IT? Or perhaps they just
>> know Chrome and not FF?
>>
>
> I also would not blame Firefox for being "too strict" here. Firefox'
> certificate validation policies are in line with industry norms. You
> shouldn't want any browser to blindly allow you to visit sites that should
> be secure but can't be validated as such due to a problem with the
> certificate chain.
>
> Keep in mind, your deployment scenario (enterprise MITM — presumably
> predicated on 'anti-virus' or 'data loss prevention') is identical to an
> actual attack, except that the IT department owns the computer and
> therefore it is OK for them to 

Re: Firefox security too strict (HSTS?)?

[Chris Palmer]

On Sun, Sep 13, 2015 at 2:56 PM, AnilG  wrote:

Thanks Chris, I'll follow up with IT on this question.
>

You can check yourself if the chain you see chains up to the right root. In
Chrome, click on the lock icon in the location bar, click the Connection
Tab, and then click "Certificate information". This opens the Certificate
Viewer. There, click the Details Tab and inspect the Certificate Hierarchy
and each certificate's Certificate Fields. The root certificate should
match the certificate your IT department gave you.

Sounds like something basic but perhaps not so obvious if the IT preferred
> (and test) browser (Chrome) is more permissive? But surely this is so basic
> that (even) Chrome can't pretend a site is secured if there's no link to
> the root certificate?
>

Chrome is not known for being permissive about certificate checking. :) And
no, it's (I hope) very unlikely that Chrome is calling a certificate OK
even without being able to chain to a root in your machine's root
certificate store. You can verify that by following the steps above.

Also, what does Safari do?

I'm also following this up on evangelism@moz. I've got the impression that
> there's global dissatisfaction with FF being "too strict" and it *seems*
> like it's harder to get FF to "work" for IT? Or perhaps they just know
> Chrome and not FF?
>

I also would not blame Firefox for being "too strict" here. Firefox'
certificate validation policies are in line with industry norms. You
shouldn't want any browser to blindly allow you to visit sites that should
be secure but can't be validated as such due to a problem with the
certificate chain.

Keep in mind, your deployment scenario (enterprise MITM — presumably
predicated on 'anti-virus' or 'data loss prevention') is identical to an
actual attack, except that the IT department owns the computer and
therefore it is OK for them to install this new root certificate. But no
browser can 'know' that, except by seeing and using the certificate. So the
good browser fails closed.


> For me I'm currently working in Chrome because I *can't* work in FF. It's
> been days now so this probably means I'm the last guy in my organisation
> still hanging on to FF. I'm worried that this may be a global issue cutting
> FF out of commercial (firewalled) use.
>

That is unlikely. Firefox is fine for these uses, and I'm sure it will turn
out to be a glitch in the deployment or configuration.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[AnilG]

Thanks Richard and Kurt.
I made sure I trusted it as much as possible :-)
All three bits are set (checked / on / trusted): web, mail and software.

On Saturday, 12 September 2015 13:18:52 UTC+10, Richard Barnes  wrote:
> On Fri, Sep 11, 2015 at 4:29 PM, Kurt Roeckx  wrote:
> > On Fri, Sep 11, 2015 at 03:34:21PM -0400, Richard Barnes wrote:
> > > And that the certificate has the "identify websites" bit set?
> > You mean that when it's important into firefox, he should say it
> > should be trusted for websites?  Or are you talking about an
> > extention in the certificate itself?
> The former.  When you import a certificate into Firefox, you can set three
> trust bits -- websites, email, and code signing.  If you want to use the CA
> for HTTPS and you don't check the websites box, you're gonna have a bad
> time.
> --Richard
> > Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Kurt Roeckx]

On Fri, Sep 11, 2015 at 03:34:21PM -0400, Richard Barnes wrote:
> And that the certificate has the "identify websites" bit set?

You mean that when it's important into firefox, he should say it
should be trusted for websites?  Or are you talking about an
extention in the certificate itself?


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Firefox security too strict (HSTS?)?

[Richard Barnes]

On Fri, Sep 11, 2015 at 4:29 PM, Kurt Roeckx  wrote:

> On Fri, Sep 11, 2015 at 03:34:21PM -0400, Richard Barnes wrote:
> > And that the certificate has the "identify websites" bit set?
>
> You mean that when it's important into firefox, he should say it
> should be trusted for websites?  Or are you talking about an
> extention in the certificate itself?
>

The former.  When you import a certificate into Firefox, you can set three
trust bits -- websites, email, and code signing.  If you want to use the CA
for HTTPS and you don't check the websites box, you're gonna have a bad
time.

--Richard



>
>
> Kurt
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy