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?)?

[Eric Mill]

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?)?

[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?)?

[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]

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?)?

[Ryan Sleevi]

On Wed, September 23, 2015 2:17 pm, R Kent James wrote:
>  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?

I would suggest continuing to explore alternatives.

Chrome's experiments with this show that, to users, it does not appear to
be less disruptive or confusing, even if 'logically' it should be.

We (Chrome) did this with SHA-1 deprecation *well in advance* of removing
support, to give the industry the time it agreed it needed, and took ample
hit from those who'd agreed to the timeline (any sort of communication is
seen as advancing the timeline) and from users (who found it confusing and
not actionable by the user).

In short, if there isn't something directly and immediately that a user
can do, it doesn't help. And "send an email to your administrator"
unfortunately doesn't meet that criteria for empowerment.

___
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]

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?)?

[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?)?

[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?)?

[Michael Ströder]

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, 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).

I completely concur with Peter here.

The situation with Firefox is so frustrating that I feel it's e.g. a waste of
time to comment on the  removal proposal. Because it seems within
Mozilla every security code is regarded as obstacle and will be removed anyway
in the not-so-long run.

Ciao, Michael.

___
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?)?

[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?)?

[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?)?

[Peter Gutmann]

AnilG  writes:

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

Hmm, interesting, I'm getting it fine via Firefox.  Could you be behind a MITM
proxy or something?

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?)?

[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]

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?)?

[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?)?

[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?)?

[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]

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?)?

[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 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?)?

[AnilG]

On Wednesday, 16 September 2015 18:14:28 UTC+10, Kurt Roeckx  wrote:
> On 2015-09-15 02:12, Anil Gulati wrote:
> > 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.
> 
> It seems to me that the issues are:
> - The IT department wants to MITM you for some reason, and Firefox 
> complains like it should.  You *are* actively being attacked.
> - The IT department (or some contractor) knows how to deal with chrome 
> (and internet explorer) so it allows this, but doesn't know how to do it 
> with Firefox.  I would argue that this isn't Firefox's problem, it has 
> always had the functionality to allow it.
> 
> > 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 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.
> 
> Kurt

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.
___
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 04:00:22 UTC+10, Kathleen Wilson  wrote:
> 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

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.

Do you guys get the issue I'm trying to communicate? I _know_ it's not your 
fault. I _know_ Firefox is the best browser. But like when you're riding a 
motorbike through traffic: it doesn't matter who's fault it is if you're dead 
(it's the car's fault but he's only dented).

1. In 3 years Firefox has gone from recommended browser in my organisation to 
practically unsupported with 1 user left. That's just one experience.

2. But it's not only us. Following Kathleen's link (in Chrome) someone says 
"Firefox was a nightmare to admin, I've spent days, but much easier now." 
Someone else says "Without CCK2, I wouldn't be packaging Firefox for Windows 
for enterprise deployment at all! It would simply be too hard to do." Not all 
IT departments are as committed to supporting Firefox. They just tell their 
users to run Chrome.

3. Have you evaluated the threat? What's you're long term vision for Firefox? 
Lead browser or niche player like Opera?
___
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 2015-09-15 02:12, Anil Gulati wrote:

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.


It seems to me that the issues are:
- The IT department wants to MITM you for some reason, and Firefox 
complains like it should.  You *are* actively being attacked.
- The IT department (or some contractor) knows how to deal with chrome 
(and internet explorer) so it allows this, but doesn't know how to do it 
with Firefox.  I would argue that this isn't Firefox's problem, it has 
always had the functionality to allow it.



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 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.



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]

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?)?

[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 install this new root certificate. But no
> brows

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]

I wonder if it's been decided yet, or whether it's still disputed, whether 
keeping a separate certificate database is more secure or not (Feb 2015 
http://news.softpedia.com/news/44-000-Superfish-MitM-Certificates-Found-in-Mozilla-Firefox-473823.shtml),
 or was this dispute just naively founded?

On Saturday, 12 September 2015 13:18:52 UTC+10, Richard Barnes  wrote:
> . . . 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
___
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 Chris, I'll follow up with IT on this question.

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?

IT provided a package to install the cert in the OS for Chrome. I'm thinking 
now maybe the installer did something additional with the cert when installing 
it, like set up it's "applicability" in some way? Are there some fields I can 
check? I'm going to ask my IT that as well. I'll also see if I can find the 
cert that works for Chrome in the OS file structure (OS X 10.8.5) and see if 
there's a plist or something that gives clues.

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?

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.

On Saturday, 12 September 2015 03:26:07 UTC+10, Chris Palmer  wrote:
> On Thu, Sep 10, 2015 at 3:21 PM, AnilG wrote:
> 
> Thanks Chris, I appreciate any help I can get. I'm trying to help IT get
> > this fixed so we can keep FF.
> >
> > I already, and now again on your advice, imported to Firefox Authorities
> > Certificates the same certificate that was circulated by IT in a package,
> > which is presumably the OS installed certificate that enables Chrome to
> > work. Same error continues. I've passed on your advice to my ticket but
> > don't yet have a response from my IT.
> >
> > Can you clarify how to install or required particulars of this
> > certificate? It's sitting their in "Authorities" list but the cert seems to
> > have little information in it's fields. Perhaps it's inadequately
> > constituted? The CN is a slightly lengthy piece of arbitrary free text with
> > no O or OU in the issued to, and no OU and the CN replicated in the O for
> > the issued by section. Otherwise it's PKCS #1 SHA-256 With RSA Encryption
> > with validity dates and a few other fields including a CRL distribution
> > point with a local URI marked Not Critical.?
> >
> 
> Have you verified that the proxy issues its MITM certs *from that
> particular issuing certificate*?

___
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?)?

[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

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]

And that the certificate has the "identify websites" bit set?

On Fri, Sep 11, 2015 at 1:26 PM, Chris Palmer  wrote:

> On Thu, Sep 10, 2015 at 3:21 PM, AnilG  wrote:
>
> Thanks Chris, I appreciate any help I can get. I'm trying to help IT get
> > this fixed so we can keep FF.
> >
> > I already, and now again on your advice, imported to Firefox Authorities
> > Certificates the same certificate that was circulated by IT in a package,
> > which is presumably the OS installed certificate that enables Chrome to
> > work. Same error continues. I've passed on your advice to my ticket but
> > don't yet have a response from my IT.
> >
> > Can you clarify how to install or required particulars of this
> > certificate? It's sitting their in "Authorities" list but the cert seems
> to
> > have little information in it's fields. Perhaps it's inadequately
> > constituted? The CN is a slightly lengthy piece of arbitrary free text
> with
> > no O or OU in the issued to, and no OU and the CN replicated in the O for
> > the issued by section. Otherwise it's PKCS #1 SHA-256 With RSA Encryption
> > with validity dates and a few other fields including a CRL distribution
> > point with a local URI marked Not Critical.?
> >
>
> Have you verified that the proxy issues its MITM certs *from that
> particular issuing certificate*?
> ___
> 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?)?

[AnilG]

Thanks Chris, I appreciate any help I can get. I'm trying to help IT get this 
fixed so we can keep FF.

I already, and now again on your advice, imported to Firefox Authorities 
Certificates the same certificate that was circulated by IT in a package, which 
is presumably the OS installed certificate that enables Chrome to work. Same 
error continues. I've passed on your advice to my ticket but don't yet have a 
response from my IT.

Can you clarify how to install or required particulars of this certificate? 
It's sitting their in "Authorities" list but the cert seems to have little 
information in it's fields. Perhaps it's inadequately constituted? The CN is a 
slightly lengthy piece of arbitrary free text with no O or OU in the issued to, 
and no OU and the CN replicated in the O for the issued by section. Otherwise 
it's PKCS #1 SHA-256 With RSA Encryption with validity dates and a few other 
fields including a CRL distribution point with a local URI marked Not Critical.?

On Thursday, 10 September 2015 04:37:04 UTC+10, Chris Palmer  wrote:
> It looks like perhaps your organization is using an intercepting proxy . . .
> the fix is for your IT department to add their proxy's root certificate to 
> Firefox,
> 
> On Tue, Sep 8, 2015 at 8:33 PM,  wrote:
> > I want to ask about Firefox security implementation, possibly HSTS?
> > Firefox seems to implement strict-er security in comparison to Chrome.
> >
> > Our IT department have been making changes to implement SSO including
> > using a SAML identity provider with Google services.
> >
> > From the perspective of our ICT support it looks like Firefox doesn't
> > work. . . .
> > You have asked Firefox to connect securely to mail.google.com, but we
> > can't confirm that your connection is secure.
> > Normally, when you try to connect securely, sites will present trusted
> > identification to prove that you are going to the right place.
> > However, this site's identity can't be verified.
> > What Should I Do?
> > If you usually connect to this site without problems, this error could
> > mean that someone is trying to impersonate the site, and you shouldn't
> > continue.
> > This site uses HTTP Strict Transport Security (HSTS) to specify that
> > Firefox only connect to it securely. As a result, it is not possible to add
> > an exception for this certificate.
> > Get me out of here!
> > Technical Details
> > mail.google.com uses an invalid security certificate.
> > The certificate is not trusted because the issuer certificate is unknown.
> > The server might not be sending the appropriate intermediate certificates.
> > An additional root certificate may need to be imported.
> > (Error code: sec_error_unknown_issuer)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Firefox security too strict (HSTS?)?

[gulati . au]

Dear Moz, sorry to barge in on this topic, which I presume is an existing 
unpopular topic.

I want to ask about Firefox security implementation, possibly HSTS? Firefox 
seems to implement strict-er security in comparison to Chrome.

Our IT department have been making changes to implement SSO including using a 
SAML identity provider with Google services.

>From the perspective of our ICT support it looks like Firefox doesn't work. I 
>can no longer use Firefox with Google, or MDN or a range of other sites.

We've gone from Firefox as the recommended browser, to Chrome being 
recommended, and today I've got a support request open because I can't use 
Firefox at all. There is a risk that Firefox will become unsupported in our 
organisation simply because Chrome implements looser security, but at least it 
"works".

This doesn't look like a simple problem to solve for our IT. I'm not sure of 
the details but we seem to be forwarding SSL certs from outside our network and 
then they look like they're issued by us. FF allows some sites a security 
exception. Others just can't.

Is there some known practice or update that is required to "fix" this?

MDN:

Secure Connection Failed
The connection to developer.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.
This Connection is Untrusted

Google:

You have asked Firefox to connect securely to mail.google.com, but we can't 
confirm that your connection is secure.
Normally, when you try to connect securely, sites will present trusted 
identification to prove that you are going to the right place.
However, this site's identity can't be verified.
What Should I Do?
If you usually connect to this site without problems, this error could mean 
that someone is trying to impersonate the site, and you shouldn't continue.
This site uses HTTP Strict Transport Security (HSTS) to specify that Firefox 
only connect to it securely. As a result, it is not possible to add an 
exception for this certificate.
Get me out of here!
Technical Details
mail.google.com uses an invalid security certificate.
The certificate is not trusted because the issuer certificate is unknown.
The server might not be sending the appropriate intermediate certificates.
An additional root certificate may need to be imported.
(Error code: sec_error_unknown_issuer)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: HSTS

[fhw843]

Thanks Hubert. I was guessing about 1,000 sites so seeing 3,000 is better but 
still small. What I didn't expect is that fewer than 50,000 sites present 
themselves as being secure in ‎the first place. That's smaller than it ought to 
be. 

The real shocker however is how many sites exhibit known vulnerabilities. The 
Heartbleed stat especially stands out. ‎I suppose those sites are given an F 
rating but really the certs need to be revoked in all 738 cases.

Any way the CA's can help us confirm that any site which is vulnerable to 
Heartbleed has had its cert revoked?


  Original Message  
From: Hubert Kario
Sent: Friday, September 26, 2014 6:07 AM
To: fhw...@gmail.com
Cc: dev-security-policy@lists.mozilla.org
Subject: Re: HSTS

- Original Message - 
> From: fhw...@gmail.com
> To: dev-security-policy@lists.mozilla.org
> Sent: Thursday, 25 September, 2014 7:39:33 PM
> Subject: Re: HSTS

> I'll address the DoS thing momentarily but first I'm curious if there's any
> data out there on how widely deployed HSTS currently is

About 2% of sites advertise HSTS, see 
https://www.trustworthyinternet.org/ssl-pulse/

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

Re: HSTS

[Hubert Kario]

- Original Message - 
> From: fhw...@gmail.com
> To: dev-security-policy@lists.mozilla.org
> Sent: Thursday, 25 September, 2014 7:39:33 PM
> Subject: Re: HSTS

> I'll address the DoS thing momentarily but first I'm curious if there's any
> data out there on how widely deployed HSTS currently is

About 2% of sites advertise HSTS, see 
https://www.trustworthyinternet.org/ssl-pulse/

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

Re: HSTS

[fhw843]

I'll address the DoS thing momentarily but first I'm curious if there's any data out there on how widely deployed HSTS currently is and/or to what extent site/domain owners are committing to support it going forward?Also are the cases where self-DoS might occur well known? The cases I can think of generally fall into 3 different categories, but since the actual ways in which you might shoot yourself in the foot are numerous (and subtle) I'd argue that choosing to implement HSTS is a much larger commitment than HTTPS alone.  For one thing, you need knowledge of your whole domain and the content being delivered (and how it's being deployed) or you run the risk of screwing something up.You hit upon one such case below, where a subdomain that doesn't have SSL becomes inaccessible due to ‎the "includeSubdomains" flag. Actually the other case is a problem too, but for illustration purposes I'll talk about the former.So, consider a brand like Nike who has a large ‎internet presence and a lot of products serving different people and markets. I don't personally know anything about them or how they get their internet needs met, but let's just assume for this discussion they have a bunch of different teams and outsourcing agreements that try to make it all work (something I think could be said for all major corporations). Next, let's suppose they want to run a marketing campaign during a major sports event and give away free shoes to the first 500 people who sign up at a new micro site setup just for this campaign. The browser requests go something like this (substituting - for. )1. Go to the landing page at freeshoes-nike-com using http2. Grab some some logo graphics from nike-com using https, hsts is enabled with includesubdomains3. Grab a js file at freeshoes-nike-com that will collect people's information usi‎ng http, which is rewritten to be https but a cert was never installed for "freeshoes"Clearly you are screwed, the page will not display correctly. And if you try to go back to the landing page (with just http), you're even worse off because then nothing shows up, only the error screen. People will be very upset, especially the marketing team who can do nothing but watch their campaign blow up before their very eyes.Put simply, a debacle such as this would be a very big deal, and no matter how much people might like the idea of security there is not a person out there who wants to risk losing their job just to be more secure. So that's why I have a hard time seeing HSTS becoming widely adopted. Maybe it will make my site more secure but if it's going to screw everything up, I'm not interested. Bait-and-switch.Some of the other DoS cases might be even more problematic, but I don't know if anyone wants to get into them here.Thanks.  From: David KeelerSent: Wednesday, September 24, 2014 12:32 PM‎On 09/23/2014 10:03 PM, fhw...@gmail.com wrote:...snip...> The shortcoming of HSTS is on the deployment side, where on the one hand> it purports to help web app developers and deployment teams who falter> at security and on the other hand gives those same people all-new ways> to falter at security. It's your classic bait-and-switch except this> time your site could become unusablesnip...A site can only DOS itself if it sets a long-lived header and then stopssupporting https (or if it sets includeSubdomains and a subdomaindoesn't support https). The easy answer is if your site is committed toalways supporting https, then HSTS is appropriate. If not, then it isn'tappropriate.> The most ambitious of web sites and services will be up for the> challenge of doing a proper HSTS implementation but the rest...I don't> know. Any thoughts on how widely this will be adopted?Again, using HSTS is essentially as difficult as using https properly.If that's doable (and it's definitely a whole lot easier than it used tobe), then setting an HSTS header is a small incremental step that doesincrease a site's security.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: HSTS

[David Keeler]

On 09/23/2014 10:03 PM, fhw...@gmail.com wrote:
> So I read through RFC 6797 and see that ‎some of my concerns are
> addressed there. Still, I would like to have a better understanding of
> Mozilla's implementation since there is user agent flexibility that's
> open to interpretation. One other thing that isn't clear to me is how
> complete the Mozilla implementation is. Is there more work to do or is
> it all in there and now we're just waiting for websites to deploy it?

The implementation in Firefox has been complete for a few years now:
http://blog.sidstamm.com/2010/08/http-strict-transport-security-has.html
Many sites do use HSTS, although it would be great if more did.

> The shortcoming of HSTS is on the deployment side, where on the one hand
> it purports to help web app developers and deployment teams who falter
> at security and on the other hand gives those same people all-new ways
> to falter at security. It's your classic bait-and-switch except this
> time your site could become unusable.

It doesn't just help development and deployment - it prevents things
like ssl-stripping attacks (where an attacker actively re-writes https
links as http).

> For example, how do I pick a suitable max-age? Suppose I mistake the
> units for days instead of seconds (seriously? seconds?!?) and set the
> value to 10. What are the practical effects of that? What happens when I
> use a value of 0x? If my settings mean I've DoS-ed myself, what
> can I do to the browser to restore service?

HSTS is particularly useful when combined with browser preload lists
(that is, some browsers ship knowing that some sites use HSTS - this
fixes the first-connection issue). To get on the Firefox and Chrome
lists, a site must set a max-age of at least 18 weeks (10886400
seconds). So, if your site fully supports https, 10886400 is a suitable
max-age to use. If max-age is set to 10, your site will not get the
benefit of HSTS. For Firefox, as long as the max-age value fits in a
signed 64-bit integer, it will be honored (this is just an
implementation detail).
A site can only DOS itself if it sets a long-lived header and then stops
supporting https (or if it sets includeSubdomains and a subdomain
doesn't support https). The easy answer is if your site is committed to
always supporting https, then HSTS is appropriate. If not, then it isn't
appropriate.

> The most ambitious of web sites and services will be up for the
> challenge of doing a proper HSTS implementation but the rest...I don't
> know. Any thoughts on how widely this will be adopted?

Again, using HSTS is essentially as difficult as using https properly.
If that's doable (and it's definitely a whole lot easier than it used to
be), then setting an HSTS header is a small incremental step that does
increase a site's security.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

HSTS (was: Indicators for high-security features)

[fhw843]

So I read through RFC 6797 and see that ‎some of my concerns are addressed there. Still, I would like to have a better understanding of Mozilla's implementation since there is user agent flexibility that's open to interpretation. One other thing that isn't clear to me is how complete the Mozilla implementation is. Is there more work to do or is it all in there and now we're just waiting for websites to deploy it?The shortcoming of HSTS is on the deployment side, where on the one hand it purports to help web app developers and deployment teams who falter at security and on the other hand gives those same people all-new ways to falter at security. It's your classic bait-and-switch except this time your site could become unusable.For example, how do I pick a suitable max-age? Suppose I mistake the units for days instead of seconds (seriously? seconds?!?) and set the value to 10. What are the practical effects of that? What happens when I use a value of 0x? If my settings mean I've DoS-ed myself, what can I do to the browser to restore service?The most ambitious of web sites and services will be up for the challenge of doing a proper HSTS implementation but the rest...I don't know. Any thoughts on how widely this will be adopted?From: fhw...@gmail.comSent: Tuesday, September 23, 2014 8:10 PM‎OK, thanks Matt.  So the security improvement is because it's a server config plus persistent memory on the client side.What is the thinking in Firefox (assume Thunderbird will be similar?) for handling of all the different cases that arise with it? I'm thinking of how persistent is the HSTS knowledge, can it be cleared, what errors/warnings might appear, will users be allowed to bypass them, and so forth.  Original Message  From: Matt PalmerSent: Tuesday, September 23, 2014 5:01 PM‎‎On Tue, Sep 23, 2014 at 01:08:13PM -0500, fhw...@gmail.com wrote:> So what is the reason to use HSTS over a server initiated redirect? Seems> to me the latter would provide greater security whereas the former is easy> to bypass. On the contrary, HSTS is much harder to bypass, because the browserremembers the HSTS setting for an extended period of time. While first useis still vulnerable to a downgrade attack under HSTS, it's only *one* use,whereas the browser is vulnerable to redirect filtering on *every* use. Ifan attacker has enough access to the network to be able to strip the HSTSheader, they also have enough access to be able to block theserver-initiated redirect to HTTPS.- Matt‎
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy