Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Peter Gutmann]

Chris Palmer  writes:

>Tangential, fun note: felt, et al. found that ~50% of users thought a
>green lock was *open*, hence unsafe — green means you can go, through
>the locked door, while red means the lock is securely locked. Like an
>airplane toilet...

Do you have a reference for this?

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

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[fhw843]

In terms of the messaging behind any iconography, I would like to see something 
precise and perhaps more objective than, say, labels like 
secure/not-secure/good-luck-with-that. Those words can have different meanings 
depending on the context but the issues being addressed are pretty well 
defined. 

Here are 3 labels and my intention behind each one. They aren't great but do 
finish the sentence: Your data is 

"Monitored" means that all information is sent in the clear and is being 
monitored by outside parties. Such parties include your ISP, your mobile 
network provider, the government of the United States (and other countries 
where possible), your employer (while at work), and any rogue devices that are 
present on your local network (including those at restaurants, coffee shops, 
hotels, and other public access points as well as devices infected with malware 
that are used by you or other people you know). The purpose and extent of such 
monitoring is not known but you should expect that your data is being collected 
and analyzed. The possibility also exists that rogue actors might intercept 
your data and manipulate it without your knowledge. 

"Cloaked"‎ means that information is encrypted and will be indecipherable to 
most third parties. Assurances cannot be provided that a rogue actor is not 
intercepting your data, however, since some security features are inactive. 
[Here I'm referring to the self-signed and various override cases.]

"Pretty Safe" means that the best security features are automatically selected 
and in use for data exchange. The receiving party has been authenticated and 
the data indecipherable to all but the intended receiver. That said, nothing is 
perfect and some monitoring or interception by unwanted entities is still 
possible. [Here I'm thinking of bugs and vulnerabilities like Heartbleed as 
well as info leakage like DNS lookups or TCP/IP headers.]


Suggestions welcomed.


  Original Message  
From: Chris Palmer
Sent: Tuesday, July 22, 2014 1:00 PM‎

On Mon, Jul 21, 2014 at 7:15 PM, Michal Zalewski  wrote:

> Indeed. Instinctively [*], I think that a prominent always-on
> indicator - say, an icon alternating between a red peering eye and a
> green / gray closed lock - is strictly better than showing nothing for

Tangential, fun note: felt, et al. found that ~50% of users thought a
green lock was *open*, hence unsafe — green means you can go, through
the locked door, while red means the lock is securely locked. Like an
airplane toilet...

So, it seems we're mixing the Lock metaphor with the Traffic Light
metaphor, and that mixing them does not make sense. I have proposed
dropping the lock part and just going with red, yellow, and green
colors. No more lock.

Or, like Safari, just the lock, no color. But that doesn't get us the
3-state indicator I think we need. (Although that need is, ideally,
temporary.)

> HTTP and then having a DHS-grade fifteen-level color-coded threat
> level system for HTTPS. The latter mostly teaches people that the
> browser always cries wolf - and it leaves them vulnerable to
> sslstrip-type attacks.

Agree.

> We should also explicitly and very vocally tell website owners is that
> if their stuff is important, they *need* to start using HSTS.

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

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Chris Palmer]

On Tue, Jul 22, 2014 at 2:00 PM, Brian Smith  wrote:

> Firefox's cert override mechanism uses a different pinning mechanism
> than the "key pinning" feature. Basically, Firefox saves a tuple
> (domain, port, cert fingerprint, isDomainMismatch,
> isValidityPeriodProblem, isUntrustedIssuer) into a database. When it
> encounters an untrsuted certificate, it computes that tuple and tries
> to find a matching one in the database; if so, it allows the
> connection.

Interesting! Thanks for the clue.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Brian Smith]

[+keeler, +cviecco]

On Tue, Jul 22, 2014 at 1:55 PM, Chris Palmer  wrote:
> On Tue, Jul 22, 2014 at 3:01 AM, Hubert Kario  wrote:
>
>>> I'm pretty sure Firefox merely remembers your decision to click
>>> through the warning, not that it pins the keys/certificates in the
>>> chain you clicked through on.
>>
>> No, I'm sure it remembers the certificate.
>
> 1. Generate a self-signed cert; configure Apache to use it; restart Apache.
> 2. Browse to the server with Firefox. Add Exception for the cert.
> 3. Quit Firefox; restart Firefox; browse to server again. Everything is good.
> 4. Generate a *new* self-signed cert; configure Apache to use it;
> restart Apache.
> 5. Quite Firefox; restart Firefox; browse to server again.
>
> Results:
>
> A. On first page-load after step (5), no certificate warning. (I
> assume a cached page was being shown.)
> B. Reload the page; now I get a cert warning as expected. But,
> crucially, this not a key pinning validation failure; just an unknown
> authority error. (Error code: sec_error_untrusted_issuer)

Firefox's cert override mechanism uses a different pinning mechanism
than the "key pinning" feature. Basically, Firefox saves a tuple
(domain, port, cert fingerprint, isDomainMismatch,
isValidityPeriodProblem, isUntrustedIssuer) into a database. When it
encounters an untrsuted certificate, it computes that tuple and tries
to find a matching one in the database; if so, it allows the
connection.

> C. I do the clicks to Add Exception, but it fails: In the Add Security
> Exception dialog, the [ ] Permanently store this exception checkbox is
> grayed out, and the [ Confirm Security Exception ] button is also
> grayed out. I can only click [ Cancel ].
>
> I take it this is a Firefox UI bug...? Everything was working as I
> expected except (C). I think the button and the checkbox should be
> active and should work as normal.

It seems like a UI bug to me.

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

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Chris Palmer]

On Tue, Jul 22, 2014 at 3:01 AM, Hubert Kario  wrote:

>> I'm pretty sure Firefox merely remembers your decision to click
>> through the warning, not that it pins the keys/certificates in the
>> chain you clicked through on.
>>
>> Although I have proposed that for certain use-cases, its applicability
>> is limited — will people know how to recover if the key(s) change(s)?
>
> No, I'm sure it remembers the certificate.
>
> I have setup a SNI-enabled server that returns one certificate for two
> different virtual hosts.
>
> When the certificate was about to expire, I changed it to
> a new one signed by a trusted CA, for the site for which the CN matched,
> the Firefox didn't even bat an eye, for the site for which I had to waive
> the mismatched CN in the past, I had to waive the certificate again.
>
> I can retests with self signed certificates, but I'd be very surprised
> if it didn't work exactly the same.

I just ran this test:

1. Generate a self-signed cert; configure Apache to use it; restart Apache.
2. Browse to the server with Firefox. Add Exception for the cert.
3. Quit Firefox; restart Firefox; browse to server again. Everything is good.
4. Generate a *new* self-signed cert; configure Apache to use it;
restart Apache.
5. Quite Firefox; restart Firefox; browse to server again.

Results:

A. On first page-load after step (5), no certificate warning. (I
assume a cached page was being shown.)
B. Reload the page; now I get a cert warning as expected. But,
crucially, this not a key pinning validation failure; just an unknown
authority error. (Error code: sec_error_untrusted_issuer)
C. I do the clicks to Add Exception, but it fails: In the Add Security
Exception dialog, the [ ] Permanently store this exception checkbox is
grayed out, and the [ Confirm Security Exception ] button is also
grayed out. I can only click [ Cancel ].

I take it this is a Firefox UI bug...? Everything was working as I
expected except (C). I think the button and the checkbox should be
active and should work as normal.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[David E. Ross]

On 7/22/2014 11:27 AM, Chris Palmer wrote [in part]:
> On Tue, Jul 22, 2014 at 10:49 AM, I previously wrote [also in part]:
> 
> (Your intentionally broken email address suggests that you don't
> really want to communicate, so mostly this message is directed to the
> public list subscribers in general.)
> 
>> Someone please explain to me how my non-HTTPS personal Web site at
>>  creates any risk to visitors.

When I post to a newsgroup, yes, I munge my E-mail address.  I expect to
communicate in a public discussion, not a private exchange of E-mail.

My E-mail address, however, can be found in the Organization header
field if you view the message source.  Also, you can go to my home Web
page and select the "E-mail link with the envelope graphic near the top
of the page; on the resulting "Send Me E-Mail" Web page, you will see my
address in a graphic.

All this is to reduce my exposure to spam.  I am not the only
participant in news.mozilla.org newsgroups who munges his or her E-mail
address.

-- 

David E. Ross


On occasion, I filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam, flames, and trolling from that source.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Adrienne Porter Felt]

On Tue, Jul 22, 2014 at 12:24 PM, Brian Smith  wrote:

> On Mon, Jul 21, 2014 at 4:10 PM, Adrienne Porter Felt 
> wrote:
> > I would very much like to make http sites look insecure.
> >
> > But we face a very real problem: a large fraction of the web is still
> > http-only. That means that:
> >
> >- Users will get used to the insecure icon, and it will start looking
> >meaningless pretty quickly.
> >- This might also make users ignore the broken https icon.
> >
> > I'm not sure how to reconcile this.
>
> I think they key to reconciling this is to recognize that the primary
> audience for the address bar UI elements for this are website
> *makers*, not website visitors, regardless of what we'd like. That is,
> if the indicators in the address bar are already so confusing or
> useless for end-users that they generally ignore them or take them to
> have the opposite meaning from what's intended, and yet users are
> still using our products, then that means that we don't have to worry
> so much about the possibility of adding end-user confusion by making
> such a change. Yet, it is in the economic interests of every website
> to avoid being branded "not secure"; it is likely that the marginal
> utility of avoiding that is significant enough that it will be the
> tipping point for many websites to make the switch. To see if this is
> a workable strategy, we should learn whether or not end-user apathy
> and confusion is so high that we can turn it from a negative into a
> positive this way.
>
> Further, like I said in my previous message, we should be able to do a
> lot more to ensure that the browser navigates to https:// instead of
> http:// when https:// is available. This would likely significantly
> reduce the number of websites for which the negative branding would be
> shown.
>
> Having said all of that, I remember that Mozilla did some user
> research ~3 years ago that showed that when we show a negative
> security indicator like the broken lock icon, a significant percentage
> of users interpreted the problem to lie in the browser, not in the
> website--i.e. the security problem is Firefox's fault, not their
> favorite website. It would be important to do research to confirm or
> (hopefully) refute this finding.
>

I suspect this is still sometimes true. We've been working on the SSL
interstitial and people sometimes believe that the fault lies with Chrome
("Chrome can't set up a secure connection because of a bug in Chrome...").
We've been trying to tweak the wording to avoid this misconception, but we
have a lot more space in an interstitial than in the URL bar.


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

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Brian Smith]

On Mon, Jul 21, 2014 at 4:10 PM, Adrienne Porter Felt  wrote:
> I would very much like to make http sites look insecure.
>
> But we face a very real problem: a large fraction of the web is still
> http-only. That means that:
>
>- Users will get used to the insecure icon, and it will start looking
>meaningless pretty quickly.
>- This might also make users ignore the broken https icon.
>
> I'm not sure how to reconcile this.

I think they key to reconciling this is to recognize that the primary
audience for the address bar UI elements for this are website
*makers*, not website visitors, regardless of what we'd like. That is,
if the indicators in the address bar are already so confusing or
useless for end-users that they generally ignore them or take them to
have the opposite meaning from what's intended, and yet users are
still using our products, then that means that we don't have to worry
so much about the possibility of adding end-user confusion by making
such a change. Yet, it is in the economic interests of every website
to avoid being branded "not secure"; it is likely that the marginal
utility of avoiding that is significant enough that it will be the
tipping point for many websites to make the switch. To see if this is
a workable strategy, we should learn whether or not end-user apathy
and confusion is so high that we can turn it from a negative into a
positive this way.

Further, like I said in my previous message, we should be able to do a
lot more to ensure that the browser navigates to https:// instead of
http:// when https:// is available. This would likely significantly
reduce the number of websites for which the negative branding would be
shown.

Having said all of that, I remember that Mozilla did some user
research ~3 years ago that showed that when we show a negative
security indicator like the broken lock icon, a significant percentage
of users interpreted the problem to lie in the browser, not in the
website--i.e. the security problem is Firefox's fault, not their
favorite website. It would be important to do research to confirm or
(hopefully) refute this finding.

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

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Chris Palmer]

On Tue, Jul 22, 2014 at 10:49 AM, David E. Ross  wrote:

(Your intentionally broken email address suggests that you don't
really want to communicate, so mostly this message is directed to the
public list subscribers in general.)

> Someone please explain to me how my non-HTTPS personal Web site at
>  creates any risk to visitors.

One of our goals is to create a cultural norm among engineers: Secure
By Default.

That engineering cultural norm allows us to work toward another of our
goals: to create a cultural norm among users that they can expect the
internet to work safely.

Because security is a complex idea that is hard to communicate to
non-experts, engineers are quantizing it upward rather than downward,
to best satisfy a wide variety of security needs and use cases.

> I do not force any downloads other than GIF and JPEG files.  I do not
> accept any inputs other than search terms for a search engine I do not
> control.  I give visitors no login capability.  There is no way to input
> personal information.

To a user agent, your site is indistinguishable from
aids-health-facts.com or unpopular-political-views.org — sites where
confidentiality in the material being read (as opposed to written) is
a concern. Similarly, your site is indistinguishable from
live-stock-quotes.com, where authentication and data integrity are
paramount. Because we have to quantize the security message we
communicate to users, we must quantize the guarantee upward to suit
the general case.

> Yet you propose that I obtain a site certificate and pay my ISP to
> convert my site to a secure site.  For what purpose?  Who (other than
> some certification authority that derives revenue from signing site
> certificates) will benefit in my case?

Unfortunately, secure introduction for peers in a globally-distributed
system remains a hard problem, and so we have to make do with a little
duct tape (trusted third parties, in this case). We are trying as hard
as we can to reduce the amount of trust placed in the third parties,
while also finding ways to bolster their trustworthiness. (See e.g.
Certificate Transparency.) But, yes, they do perform some work, and
$15 is the marginal amount they need to continue operating. It's not
actually that much to ask. The cost is on the same order of magnitude
as the deluxe duct tape collection:

http://www.walmart.com/ip/Shurtape-Light-Industrial-Grade-Duct-Tapes-201458-2-x60yds-silver-duct-tape/15640850

One way to avoid the (marginal!) costs is to use a hosting service
that includes HTTPS in the default configuration, like Heroku,
Appspot, or GitHub. Wordpress is moving toward all HTTPS too, I hear.
Soon that will be the norm. And that will be good.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Problem (Error Code: sec_error_bad_der)

[Kathleen Wilson]

On 7/22/14, 4:49 AM, Ernesto Acosta wrote:

El 22/07/14 02:10, Brian Smith escribió:

On Thu, Jul 10, 2014 at 6:36 AM, Ernesto Acosta
 wrote:

With Firefox 30 everything works fancy me so far with the tests I've
done. But with Firefox Nightly I present problems when trying to
access my business sites that do not have a valid SSL certificate.

When I try to access some of these sites, I get the following message:

"Secure connection failed

An error occurred during a connection to uinfo.correos.cu. security
library: DER encoded incorrectly formatted message. (Error code:
sec_error_bad_der)


Please list the sites that you are having the trouble with.
https://uinfo.correos.cu doesn't connect for me now in any browser.

Cheers,
Brian



As I see what else I report problems, as I said,
https://uinfo.correos.cu is a local intranet site for the company I work
for.

Thanks



Ernesto,

If your intranet site is still working with Firefox 30 and not with 
Nightly, it might be a side effect of our switch to mozilla::pkix as 
described on this wiki page:

https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes

But I don't know why the change would cause you to get the 
sec_error_bad_der error.


If you can provide a way for us to reproduce the error (i.e. provide a 
cert or test website), please file a bug:

https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security:%20PSM&short_desc=(mozilla::pkix)%20


Thanks,
Kathleen

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

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Chris Palmer]

On Mon, Jul 21, 2014 at 7:15 PM, Michal Zalewski  wrote:

> Indeed. Instinctively [*], I think that a prominent always-on
> indicator - say, an icon alternating between a red peering eye and a
> green / gray closed lock - is strictly better than showing nothing for

Tangential, fun note: felt, et al. found that ~50% of users thought a
green lock was *open*, hence unsafe — green means you can go, through
the locked door, while red means the lock is securely locked. Like an
airplane toilet...

So, it seems we're mixing the Lock metaphor with the Traffic Light
metaphor, and that mixing them does not make sense. I have proposed
dropping the lock part and just going with red, yellow, and green
colors. No more lock.

Or, like Safari, just the lock, no color. But that doesn't get us the
3-state indicator I think we need. (Although that need is, ideally,
temporary.)

> HTTP and then having a DHS-grade fifteen-level color-coded threat
> level system for HTTPS. The latter mostly teaches people that the
> browser always cries wolf - and it leaves them vulnerable to
> sslstrip-type attacks.

Agree.

> We should also explicitly and very vocally tell website owners is that
> if their stuff is important, they *need* to start using HSTS.

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

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[David E. Ross]

Someone please explain to me how my non-HTTPS personal Web site at
 creates any risk to visitors.

I do not force any downloads other than GIF and JPEG files.  I do not
accept any inputs other than search terms for a search engine I do not
control.  I give visitors no login capability.  There is no way to input
personal information.

Yet you propose that I obtain a site certificate and pay my ISP to
convert my site to a secure site.  For what purpose?  Who (other than
some certification authority that derives revenue from signing site
certificates) will benefit in my case?

-- 

David E. Ross


On occasion, I filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam, flames, and trolling from that source.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Adrienne Porter Felt]

On Mon, Jul 21, 2014 at 4:20 PM, Daniel Roesler  wrote:

> Gotta start somewhere.


Best case: no one will notice it after the first few days.
Worst case: people notice it, and therefore start ignoring all https
authentication errors.

Is there a way to make the best case better, without ending up at the worst
case?


> I actually kind of like the idea of showing the
> current generic icon for self-signed ssl certificates, and the broken
> lock icon for insecure connections.


That would mean that any active attacker on your network could silently
MITM bank of america, with no visible change except for a subtle downgrade
of the icon.


>
>
> On Mon, Jul 21, 2014 at 4:10 PM, Adrienne Porter Felt 
> wrote:
> > I would very much like to make http sites look insecure.
> >
> > But we face a very real problem: a large fraction of the web is still
> > http-only. That means that:
> >
> > Users will get used to the insecure icon, and it will start looking
> > meaningless pretty quickly.
> > This might also make users ignore the broken https icon.
> >
> > I'm not sure how to reconcile this.
> >
> >
> > On Mon, Jul 21, 2014 at 2:27 PM, 'Chris Palmer' via Security-dev
> >  wrote:
> >>
> >> +security-...@chromium.org
> >>
> >> I also think it's a good idea to affirmatively label non-secure
> >> origins as such, in some way.
> >>
> >> On Sat, Jul 19, 2014 at 12:10 PM, Eric Mill  wrote:
> >> > A good idea, though you need to be careful. Just posted to the bug:
> >> >
> >> > What you definitely *don't* want to do is give the user such negative
> >> > feedback that they stop noticing when there's a direct problem
> (insecure
> >> > HTTPS).
> >> >
> >> > A grey unlocked padlock would be a nice way to ease people into the
> idea
> >> > that they are browsing a normal website that is insecure.
> >> >
> >> >
> >> >
> >> > On Sat, Jul 19, 2014 at 2:54 PM, Daniel Roesler 
> >> > wrote:
> >> >
> >> >> Howdy all,
> >> >>
> >> >> Yesterday, I created a bug proposing that Firefox switch the generic
> >> >> url icon to a negative feedback icon for non-https sites.
> >> >>
> >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1041087
> >> >>
> >> >> I created this bug because it's time we start treating insecure
> >> >> connections as a Bug. There is so much open wifi available to the
> >> >> modern internet user that a significant portion Firefox users'
> >> >> requests can be sniffed. If that request is insecure, it makes
> session
> >> >> hijacking, MITM, and metadata attacks trivially easy. Not using https
> >> >> should now be bad practice and considered harmful.
> >> >>
> >> >> Mozilla should be a leader and push websites to start securing their
> >> >> connections. Many of the largest websites already default to https,
> >> >> and it's time to start bringing the rest on board. Having negative
> >> >> feedback for insecure connections offers a huge incentive to fixing
> >> >> the larger Bug of insecure connections.
> >> >>
> >> >> Thanks and looking forward to any discussion,
> >> >> Daniel Roesler
> >> >> diaf...@gmail.com
> >> >> ___
> >> >> 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
> >
> >
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Michal Zalewski]

The number of security states for the address bar seems to have gotten
a bit out of control. Depending on the browser, you will have
different indicators for plain HTTP; HTTPS; EV SSL HTTPS; HTTPS with
cert errors (often without distinguishing between their severity);
HTTPS with passive mixed content; and HTTPS with active mixed content.

I'd wager that most people just want to know if the connection can be
snooped on or tampered with, a notion only loosely coupled to the use
of HTTPS. Since Chrome is already omitting "http://"; in URLs, maybe we
should go all the way through and just provide a simple, two-state
indicator for that instead of reshuffling the current UI?

/mz


On Mon, Jul 21, 2014 at 5:07 PM, Daniel Roesler  wrote:
>
> > Best case: no one will notice it after the first few days.
> > Worst case: people notice it, and therefore start ignoring all https
> > authentication errors.
> >
> > Is there a way to make the best case better, without ending up at the worst
> > case?
>
> At least for Firefox, the gray broken lock icon option is pretty
> tame[1]. I don't think the worst case is likely with that option since
> it's not red and scary like all the other https errors. Also, it's
> just annoying enough to be an eyesore to sysadmins (who might upgrade
> to https), even if their users tend to ignore it.
>
> [1] - https://bugzilla.mozilla.org/attachment.cgi?id=8459203&action=edit
>
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to security-dev+unsubscr...@chromium.org.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Problem (Error Code: sec_error_bad_der)

[Ernesto Acosta]

El 22/07/14 02:10, Brian Smith escribió:

On Thu, Jul 10, 2014 at 6:36 AM, Ernesto Acosta  wrote:

With Firefox 30 everything works fancy me so far with the tests I've done. But 
with Firefox Nightly I present problems when trying to access my business sites 
that do not have a valid SSL certificate.

When I try to access some of these sites, I get the following message:

"Secure connection failed

An error occurred during a connection to uinfo.correos.cu. security library: 
DER encoded incorrectly formatted message. (Error code: sec_error_bad_der)


Please list the sites that you are having the trouble with.
https://uinfo.correos.cu doesn't connect for me now in any browser.

Cheers,
Brian



As I see what else I report problems, as I said, 
https://uinfo.correos.cu is a local intranet site for the company I work 
for.


Thanks

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

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Adrienne Porter Felt]

I would very much like to make http sites look insecure.

But we face a very real problem: a large fraction of the web is still
http-only. That means that:

   - Users will get used to the insecure icon, and it will start looking
   meaningless pretty quickly.
   - This might also make users ignore the broken https icon.

I'm not sure how to reconcile this.


On Mon, Jul 21, 2014 at 2:27 PM, 'Chris Palmer' via Security-dev <
security-...@chromium.org> wrote:

> +security-...@chromium.org
>
> I also think it's a good idea to affirmatively label non-secure
> origins as such, in some way.
>
> On Sat, Jul 19, 2014 at 12:10 PM, Eric Mill  wrote:
> > A good idea, though you need to be careful. Just posted to the bug:
> >
> > What you definitely *don't* want to do is give the user such negative
> > feedback that they stop noticing when there's a direct problem (insecure
> > HTTPS).
> >
> > A grey unlocked padlock would be a nice way to ease people into the idea
> > that they are browsing a normal website that is insecure.
> >
> >
> >
> > On Sat, Jul 19, 2014 at 2:54 PM, Daniel Roesler 
> wrote:
> >
> >> Howdy all,
> >>
> >> Yesterday, I created a bug proposing that Firefox switch the generic
> >> url icon to a negative feedback icon for non-https sites.
> >>
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1041087
> >>
> >> I created this bug because it's time we start treating insecure
> >> connections as a Bug. There is so much open wifi available to the
> >> modern internet user that a significant portion Firefox users'
> >> requests can be sniffed. If that request is insecure, it makes session
> >> hijacking, MITM, and metadata attacks trivially easy. Not using https
> >> should now be bad practice and considered harmful.
> >>
> >> Mozilla should be a leader and push websites to start securing their
> >> connections. Many of the largest websites already default to https,
> >> and it's time to start bringing the rest on board. Having negative
> >> feedback for insecure connections offers a huge incentive to fixing
> >> the larger Bug of insecure connections.
> >>
> >> Thanks and looking forward to any discussion,
> >> Daniel Roesler
> >> diaf...@gmail.com
> >> ___
> >> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Proposal: Switch generic icon to negative feedback for non-https sites

[Hubert Kario]

- Original Message -
> From: "Chris Palmer" 
> To: "Hubert Kario" 
> Cc: "David E. Ross" , 
> mozilla-dev-security-pol...@lists.mozilla.org
> Sent: Tuesday, 22 July, 2014 1:08:57 AM
> Subject: Re: Proposal: Switch generic icon to negative feedback for non-https 
> sites
> 
> On Sun, Jul 20, 2014 at 3:23 AM, Hubert Kario  wrote:
> 
> > and while we're at it, let's get rid of those warnings about self
> > signed certificates -- they are less insecure than HTTP (Firefox actually
> > uses certificate pinning for sites with previously waived cert problems!)
> > so let's not treat them worse than HTTP connections
> 
> I'm pretty sure Firefox merely remembers your decision to click
> through the warning, not that it pins the keys/certificates in the
> chain you clicked through on.
> 
> Although I have proposed that for certain use-cases, its applicability
> is limited — will people know how to recover if the key(s) change(s)?

No, I'm sure it remembers the certificate.

I have setup a SNI-enabled server that returns one certificate for two
different virtual hosts.

When the certificate was about to expire, I changed it to
a new one signed by a trusted CA, for the site for which the CN matched,
the Firefox didn't even bat an eye, for the site for which I had to waive
the mismatched CN in the past, I had to waive the certificate again.

I can retests with self signed certificates, but I'd be very surprised
if it didn't work exactly the same.
-- 
Regards,
Hubert Kario
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy