+securi...@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 <er...@konklone.com> 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 <dia...@gmail.com> 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
>> dia...@gmail.com
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
>
> --
> konklone.com | @konklone <https://twitter.com/konklone>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Gotta start somewhere. 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.

Another complementary effort could be to ask apache and nginx to start
to use SSL in their example default config.

On Mon, Jul 21, 2014 at 4:11 PM, Chris Palmer <pal...@google.com> wrote:
> On Sun, Jul 20, 2014 at 7:08 PM,  <dia...@gmail.com> wrote:
>
>> So the general top criticism I'm seeing to this proposal is that it's too expensive (in both time and money) get an SSL certificate. I'm feeling a general consensus that HTTPS is desired, but it's too difficult to attain for many sysadmins.
>
> https://sslmate.com/

On Mon, Jul 21, 2014 at 4:36 PM, Daniel Roesler <dia...@gmail.com> wrote:

> Another complementary effort could be to ask apache and nginx to start
> to use SSL in their example default config.

Including generating a certificate and CSR for each virtual host that
does not yet have a certificate. And warning about sub-optimal
deployments ("Say, looks like you aren't serving the intermediate that
links your end-entity cert to its trust anchor/root... want to fix
that?")

apache security-configtest :)

> 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

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
> To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

On Mon, Jul 21, 2014 at 5:29 PM, 'Michal Zalewski' via Security-dev
<securi...@chromium.org> wrote:

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

I agree, but I think a 3-state solution is warranted (Good, Non-Fatal
Problems, Bad). Non-Fatal Problems would include the most minor TLS
errors and passive mixed content; Bad would include HTTP. Given that
Bad includes HTTP, it might need to be a gentle indicator rather than
a burning screaming fire.

Not claiming to have the solution at hand, but the best first step might be non-scolding, non-lock-related imagery that clearly and affirmatively gets across that this is a *public* connection.

On Mon, Jul 21, 2014 at 8:50 PM, Eric Mill <er...@konklone.com> wrote:
> Not claiming to have the solution at hand, but the best first step might be

> non-scolding, non-lock-related imagery that clearly and affirmativ' ely gets

> across that this is a *public* connection.

I think you have the right idea. Keep in mind that browsers reserve a
significant amount of space in the address bar for the organization
name in an EV certificate. So, we don't have to limit ourselves to the
square space that the lock icon occupies. For example, we could
replace the globe icon with gray text "Not Secure." That would be a
clear message for people who looked at it, and it would encourage
websites to switch to HTTPS, but it probably wouldn't be overly scary
(at least it's not red!). People who object to getting a certificate
for their website should be willing to accept browsers saying their
non-secure website is not secure.

Although the lock icon is often interpreted to mean "Secure," we know
that there are a lot of factors that go into whether a website is
secure. But, clearly HTTPS is necessary condition. Thus, it makes
sense to say "Not Secure" for non-HTTPS, but it doesn't make sense to
say explicitly "Secure" for HTTPS.

Further, this would work better if we stopped cutting off the
"http://" prefix for non-secure sites, and if browsers made more of an
effort to try https:// URIs when the scheme is omitted from a domain
name or URL typed (or pasted) into the address bar. Right now,
browsers omit the "http://" as a hint that it is not necessary to type
it in. But, we should make browsers such that it isn't necessary to
type in "https://" to get the secure variant of a page too, so the
current UI doesn't make sense.

A good start for this might be building, maintaining, and sharing a
list of websites that should default to https:// in the address bar,
even if they are not HSTS. This would include, for example,
https://www.google.com, https://en.wikipedia.org/, and
https://bing.com/.

I fully support efforts to make address bar UI changes like this
happen. They are overdue; at least, it is unlikely things will change
dramatically in the future to make it easier to make changes later
than it is to make them now.

Cheers,
Brian

On Mon, Jul 21, 2014 at 7:15 PM, Michal Zalewski <lca...@google.com> 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.

There was a meetup of HCI security people at HOPE X last weekend.  Somebody proposed a contest to help find which icons are the easiest to comprehend.

On Mon, Jul 21, 2014 at 4:10 PM, Adrienne Porter Felt <fe...@chromium.org> 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

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

Chris Palmer <pal...@google.com> 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.

----- Original Message -----
> From: "Adrienne Porter Felt" <fe...@chromium.org>
> To: "Daniel Roesler" <dia...@gmail.com>
> Cc: dev-secur...@lists.mozilla.org, "Eric Mill" <er...@konklone.com>, "security-dev"
> <securi...@chromium.org>, "Chris Palmer" <pal...@google.com>
> Sent: Tuesday, 22 July, 2014 1:42:05 AM
> Subject: Re: Proposal: Switch generic icon to negative feedback for non-https        sites
>
> On Mon, Jul 21, 2014 at 4:20 PM, Daniel Roesler <dia...@gmail.com> 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.

And how is this worse than the current sslstrip attacks?

People click through certificate warnings because in vast majority of instances
they are false positives.

We need to remove false positives.

For example through mechanism sort of like of TOFU - remember if the web site did
provide a valid cert (signed by a trusted CA) in the past. If it did and
we now get a self signed cert - cry wolf.

If it always did provide self signed or untrusted certificate - keep silent.

Sure, this will not catch the MITM attack when the user uses a site for the first
time. I'd say that's ok, the point is that we don't want to leak valid
authentication cookies. Not to deny access to web servers.

Users provide personally identifiable data or passwords over untrusted
connections -- we really can't stop them from doing that. In fact, it's more
problematic if it happens over HTTP than when it happens over HTTPS with self
signed certs. The latter requires an active attack.

--
Regards,
Hubert Kario

On Wed, Jul 23, 2014 at 7:03 AM, Robert Sesek <rse...@chromium.org> wrote:

>> 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.
>
> While we should sort out our mixed metaphors, I don't think this wouldn't
> work for accessibility reasons.

Yes, my mocks retained the Caution Triangle (yellow case) and Danger X
(red case) for the colorblind. This testing tool is useful for seeing
what the effects of (various kinds of) colorblindness are:

http://www.etre.com/tools/colourblindsimulator/