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

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

Your concept would cast a negative shadow over many non-commercial Web
sites, blogs, and legitimate freeware sources.  Are you willing to pay
the cost of site certificates for such sites?  How about just the cost
of a site certificate for my own site?  I have no advertising on my site
and thus no revenues to pay for a certificate.

Yes, I know there are some certification authorities that issue free
certificates.  For various reasons, I have marked many of their root
certificates as untrusted.

--

David E. Ross
<http://www.rossde.com/>

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.

I was able to get a certificate for a year for $3 that links up to COMODO CA.
That was without any promotions or coupons - regular price.

You need to pay few times more for hosting than you need to pay for
certificates.

Also, while you might have marked them as untrusted, I'm sure that
the vast majority (over 99%) of users didn't. Rightfully so.
They are not supposed to thwart any and all attacks. They are there so
that trivial attacks can't be launched.

There are about 1000 CA's that are trusted by Firefox (by linking up to root
CA certs or by being in the root store directly), how many of them have
you marked as untrustworthy?


+1 on the idea of starting treating HTTP as insecure

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

--
Regards,
Hubert Kario

They shouldn't show up with a lock icon, but treating HTTPS connections
as less secure than an HTTP connection is counterproductive.

Self-signed certificates should still be forbidden with HSTS. It
prevents an attacker from using sslstrip, so it should also prevent them
from providing their own certificate.

The sslstrip technique already prevents HTTPS from having *any* value
without basic user education (or HSTS). Looking for a lock icon instead
of https:// wouldn't be a big change.

In Chromium, the leading http:// is hidden, so they're in the position
to start allowing self-signed HTTPS with the leading https:// hidden. It
would only be there when copying the URL.

http://tools.ietf.org/html/draft-dukhovni-opportunistic-security-00

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.

So what can be done to lower the threshold to get sysadmins to start serving over HTTPS? Allowing self-signed certs is one proposal. What are some others?

Could Mozilla start their own root CA and give out SSL certs for free?

How about a kickstarter to make a free root CA?

Now is the time for creative solutions! And it will likely take pushing from many different fronts to make this happen :)

----- Original Message -----
> From: dia...@gmail.com
> To: mozilla-dev-s...@lists.mozilla.org
> Sent: Monday, 21 July, 2014 4:08:30 AM
> Subject: Re: Proposal: Switch generic icon to negative feedback for non-https        sites
>

> 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.
>
> So what can be done to lower the threshold to get sysadmins to start serving
> over HTTPS? Allowing self-signed certs is one proposal. What are some
> others?

This is actually what most Linux distributions do by default, so I'd say that any other
solutions should be *in addition* to accepting self signed certs.

--
Regards,
Hubert Kario

+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

On Sun, Jul 20, 2014 at 3:23 AM, Hubert Kario <hka...@redhat.com> 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)?

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/

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.


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.

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

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.

Just brainstorming a bit here:

* A charming low-fi icon of the all-seeing eye
<http://img1.wikia.nocookie.net/__cb20121208115833/deusex/en/images/8/8e/All_seeing_eye.jpg>
 * A tiny tower beaming circular waves (inspired by EFF's Open Wireless
<https://openwireless.org/> iconography)
* If a cartoony spy icon weren't already used for Chrome's Incognito Mode,
I'd suggest that
* Maybe just an eye (it could blink every 10 minutes, for extra fun)

-- Eric

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 22/07/14 12:58 AM, Brian Smith wrote:
> 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.

This would be a fantastic improvement. It would make attacks like
sslstrip much more obvious to users.

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

I think the existence of EV certificates is proof that browsers have a
lot of power here. Secure should imply perfect forward secrecy, as we're
aware that there's mass surveillance of these connections and keys can
and will be exposed in the future.

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

There's a lot of existing work on this:

https://www.eff.org/https-everywhere

----- Original Message -----
> From: "Chris Palmer" <pal...@google.com>
> To: "Hubert Kario" <hka...@redhat.com>
> Cc: "David E. Ross" <nobody@nowhere.invalid>, mozilla-dev-s...@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
>

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

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 <
securi...@chromium.org> wrote:

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

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

>
>
> 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.
> >
> >
> > On Mon, Jul 21, 2014 at 2:27 PM, 'Chris Palmer' via Security-dev
> > <securi...@chromium.org> wrote:
> >>
> >> +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.
> >> >
> >> >
> >> >

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

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

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

/mz

[*] Meaning, I'm pulling this out of thin air.

Someone please explain to me how my non-HTTPS personal Web site at
<http://www.rossde.com/> 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?

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.

On Tue, Jul 22, 2014 at 10:49 AM, David E. Ross <nobody@nowhere.invalid> 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
> <http://www.rossde.com/> 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.

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

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
>

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
>> <http://www.rossde.com/> 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
<http://www.rossde.com/>

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.

On Tue, Jul 22, 2014 at 3:01 AM, Hubert Kario <hka...@redhat.com> 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.

[+keeler, +cviecco]

On Tue, Jul 22, 2014 at 1:55 PM, Chris Palmer <pal...@google.com> wrote:
> On Tue, Jul 22, 2014 at 3:01 AM, Hubert Kario <hka...@redhat.com> 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

On Tue, Jul 22, 2014 at 2:00 PM, Brian Smith <br...@briansmith.org> 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.

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

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

This is not uncommon.  We found the same issue among all 3-letter agency
users of the P25 radios.  They frequently confused the *not* encrypted icon
for the encrypted one.  In fact, we still hear them over the air giving the
wrong instructions on how to encrypt.  I don't think developers are the
best choice for this, instead we should let the users decide.

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.

-sandy

On Tue, Jul 22, 2014 at 2:00 PM, 'Chris Palmer' via Security-dev <
securi...@chromium.org> wrote:

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

> To unsubscribe from this group and stop receiving emails from it, send an
> email to security-dev...@chromium.org.
>

on Tue, 22 Jul 2014 12:24:30 -0700, Brian Smith wrote:

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

How about showing a red border around the webpage, possibly with a banner
at the top (but inside the page area)?

--
begin  .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end

On Tue, Jul 22, 2014 at 2:00 PM, 'Chris Palmer' via Security-dev <
securi...@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.

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/

On Wed, Jul 23, 2014 at 4:06 AM, Jernej Simončič
<jernej@reply.in.newsgroup> wrote:

> How about showing a red border around the webpage, possibly with a banner
> at the top (but inside the page area)?

The page area (the Viewport) is not a good place for UI that needs to
be trustworthy. Trustworthy UI controls and indicators need to be in
the chrome.

on Wed, 23 Jul 2014 11:26:17 -0700, Chris Palmer wrote:

> The page area (the Viewport) is not a good place for UI that needs to
> be trustworthy. Trustworthy UI controls and indicators need to be in
> the chrome.

I meant to only use the page area to indicate when something is wrong.

On Thu, Jul 24, 2014 at 12:56 AM, Jernej Simončič
<jernej@reply.in.newsgroup> wrote:

>> The page area (the Viewport) is not a good place for UI that needs to
>> be trustworthy. Trustworthy UI controls and indicators need to be in
>> the chrome.
>
> I meant to only use the page area to indicate when something is wrong.

But it's just as important for indications of badness to be
trustworthy as indications of goodness.

I think it's worth looking at the cost issue as an enterprise one as well as a personal one.  Yes, there is a cost to the individual on a personal website and even a few dollars a year is off-putting if it potentially doubles the cost of your website.  But those of us who operate large sites through third party CDNs like Akamai, Limelight, Fastly, Cloudfront etc also face non-trivial costs: Multiple CDN vendors are quoting numbers in the range of thousands of dollars *per CDN*, *per domain*, *per month* for SSL support.  Depending on your traffic level, that might easily double or treble your CDN fees.

Equally, the ease of implementation is sometimes pretty dire.  I'm currently waiting for SSL setup for a domain on a CDN who only issue SSL certs on Mondays, for example!

I'm all for pushing people onto SSL, and of course if you stigmatise non-secure connections the demand for SSL increases and CDNs will need to compete on their ability to support it at a reasonable cost. But there's a chicken and egg problem, to some extent.  Is there anything browser vendors can do to make SSL easier and cheaper across the board before punishing you for not using it?

On Wed, Aug 6, 2014 at 12:02 AM,  <andrew...@gmail.com> wrote:

> I'm all for pushing people onto SSL, and of course if you stigmatise non-secure connections the demand for SSL increases and CDNs will need to compete on their ability to support it at a reasonable cost. But there's a chicken and egg problem, to some extent.  Is there anything browser vendors can do to make SSL easier and cheaper across the board before punishing you for not using it?

The value proposition of CDNs has never been quite clear to me,
especially at volume and especially with any requirement of security.
If they choose to bilk people who ask for HTTPS, that just strengthens
the "rent your own rack on each continent" argument. But that's
another matter...

I don't know what browsers can do to make it easier for server
operators — I'm busy with Chrome; I don't work on Nginx or Apache.
There's work they need to do to make configuration easier.

That said, part of our activism campaign should probably involve
nagging server vendors to ship better configurations by default,
auto-generating keys and CSRs for each configured hostname/domain that
doesn't already have one, et c. The default configurations of a lot
servers are bad in a lot of ways, not even just HTTPS- or
security-related.

For getting certs, https://sslmate.com/ seems pretty good.

On Wed, Aug 06, 2014 at 12:02:57AM -0700, andrew...@gmail.com wrote:
> Is there anything browser vendors can do to make SSL easier and cheaper
> across the board before punishing you for not using it?

Implement support for DANE.  It won't fix the 0.001% (by number, not traffic
volume) of sites that use CDNs that charge outrageously for SSL support, but
it will remove the cost and operational hassle barrier for the vast majority
of sites.

- Matt

I second that: DANE support is the right direction to go! It considerably raises the effort required to do MITM attacks, it allows the site ops to cut out the CAs and take control back.

If Firefox/Mozilla really want to be on the forefront: go for DANE!

On Thu, Aug 7, 2014 at 7:11 AM,  <huse...@gmail.com> wrote:

> I second that: DANE support is the right direction to go! It considerably raises the effort required to do MITM attacks, it allows the site ops to cut out the CAs and take control back.

DANE relies on DNSSEC, which (apart from having had and lost its
chance to be widely deployed) ossifies trust in fewer, more powerful
third parties who use weaker keys.

But now we are off the topic of this thread.

Switched the subject line :)

You're talking as if those fewer, more powerful third parties can't *already* subvert the CA system.

Whether you like the DNS or not, all the many DV certs in the world are attesting to DNS names.  All the CAs are supposed to be doing is verifying that the person requesting a cert is the person that holds a DNS name.  Since the parent zones are authoritative for that, they can already screw you.  (Verisign can get a cert for your .com domain; the Libyan government for your .ly domain.)  DANE just centralizes the risk in one place.

I don't disagree with the "weaker keys" point, but that can be fixed.  Likewise, the brokenness of the DNS protocol as a way of fetching DNSSEC records can be mitigated with things like AGL's proposal for carrying DANE records in TLS.

I'm not saying that DANE is a panacea, but we should be honest about the tradeoffs.

--Richard

On Thu, Aug 7, 2014 at 3:08 PM, Richard Barnes <rba...@mozilla.com> wrote:
>
> On Aug 7, 2014, at 2:17 PM, Chris Palmer <pal...@google.com> wrote:
>
>> On Thu, Aug 7, 2014 at 7:11 AM,  <huse...@gmail.com> wrote:
>>
>>> I second that: DANE support is the right direction to go! It considerably raises the effort required to do MITM attacks, it allows the site ops to cut out the CAs and take control back.
>>
>> DANE relies on DNSSEC, which (apart from having had and lost its
>> chance to be widely deployed) ossifies trust in fewer, more powerful
>> third parties who use weaker keys.
>>
>> But now we are off the topic of this thread.
>
> Switched the subject line :)
>
> You're talking as if those fewer, more powerful third parties can't *already* subvert the CA system.
>
> Whether you like the DNS or not, all the many DV certs in the world are attesting to DNS names.  All the CAs are supposed to be doing is verifying that the person requesting a cert is the person that holds a DNS name.  Since the parent zones are authoritative for that, they can already screw you.  (Verisign can get a cert for your .com domain; the Libyan government for your .ly domain.)  DANE just centralizes the risk in one place.

That is only the case for DV certs. And it is a situation that is
hardly acceptable.

It isn't really the case that its a permanent vulnerability either. If
a DNS registry was ever discovered to have acted as you suggest then I
would expect that the CAs and browser providers would establish a new
control to stop it happening again. That can't happen in the DNS
system.

Security by analogy almost always fails. Back in the day a lot of Web
sites decided that a 4 digit pin was sufficient for a password. After
all, ATMs use 4 digit PINs, so it must be OK. They discovered
otherwise the expensive way.


The problem with DV are that (1) it causes the user to be told that
they are safe and (2) the user is expected to check this information.
Both are bad.

I want to get rid of the first problem but to do that I need to
address the second which means that the computer must take over the
responsibility for checking if TLS should be on or not. Which means
having a security policy mechanism.

DANE does have a security policy mechanism. But the security policy
isn't generated from the system that is ensuring that the system is
secured. So there is a probability of the two being out of sync.

This is fixable but so far not been fixed.


The way to make this all work acceptably is to automate all the steps
required to administer deployment of a new network service in one
system. Right now the network admin has to poke their server with a
stick, then poke the DNS with another stick and in networks of any
size they also need to poke the firewall and the PKI and the
directory. Which is kind of clueless since if the directory was any
good it would drive all the rest but right now thats not what happens
and LDAP is a farce anyway.

On Thu, August 7, 2014 4:29 pm, Phillip Hallam-Baker wrote:
>  That is only the case for DV certs. And it is a situation that is
>  hardly acceptable.
>
>  It isn't really the case that its a permanent vulnerability either. If
>  a DNS registry was ever discovered to have acted as you suggest then I
>  would expect that the CAs and browser providers would establish a new
>  control to stop it happening again. That can't happen in the DNS
>  system.

OK - http://www.noip.com/blog/2014/07/10/microsoft-takedown-details-updates/
So - https://torrentfreak.com/tag/domain-seizure/
Where - http://en.wikipedia.org/wiki/Category:Seized_domain_names
Is - http://www.wired.com/2012/03/feds-seize-foreign-sites/
This -
https://www.europol.europa.eu/content/690-internet-domain-names-seized-because-fraudulent-practices
New - http://www.ice.gov/news/releases/1312/131202washingtondc.htm
System? -
https://www.icann.org/en/system/files/files/guidance-domain-seizures-07mar12-en.pdf

>  The problem with DV are that (1) it causes the user to be told that
>  they are safe and (2) the user is expected to check this information.
>  Both are bad.

When CAs start requiring a site have HSTS and HPKP, when they require sane
CSP and no mixed content, when CAs embrace CT, and when they check to make
sure passwords are sufficiently hashed, then we can talk about how "user's
being told their safe" is a lie for DV, but somehow true for OV/EV.

Until then, it's a true and accurate statement that you're safely only
talking to foo.example - or evil.example or good.example, and it's
pointless and misleading to suggest this is somehow "not safe".

Talking about "safe" is talking about "security". It's a game of threat
models. And it benefits no one to suggest that defense against network
interception and manipulation isn't a reasonable definition of both "safe"
and "secure".

On 7/19/2014 11:54 AM, 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
> dia...@gmail.com
>

Anyone wishing to argue this issue further -- to argue in favor of
implementing a scheme to encourage all Web sites to be HTTPS with site
certificates -- should first read
<http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/>.
 The blogger is a certificate reseller and also a computer systems
integrator.  Thus, he is a professional in the area of computer systems,
including security.  Although he has a vested interest in selling site
certificates, he argues against the idea that all Web sites should be
HTTPS.

--
David E. Ross

The Crimea is Putin's Sudetenland.
The Ukraine will be Putin's Czechoslovakia.
See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

On Sat, August 9, 2014 4:53 pm, David E. Ross wrote:
>  Anyone wishing to argue this issue further -- to argue in favor of
>  implementing a scheme to encourage all Web sites to be HTTPS with site
>  certificates -- should first read
>  <http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/>.
>   The blogger is a certificate reseller and also a computer systems
>  integrator.  Thus, he is a professional in the area of computer systems,
>  including security.  Although he has a vested interest in selling site
>  certificates, he argues against the idea that all Web sites should be
>  HTTPS.

David,

At the risk of engaging what may be trolling behaviour (non-attributable
email addresses and all that good jazz), and while a point-by-point
takedown is not particularly worthy, the author makes a number of
demonstrably false or misleading claims.

1) That the issuance of certs increases the likelihood of CA compromise.
Evidence demonstrates the opposite, but either way, they're orthogonal
issues entirely. Having more certificates issued does not directly make it
more likely for a CA (like DigiNotar) to be breached.

2) The author continues to make the claim of "additional server overhead
and network/router/internet traffic", except leading experts and
implementers have shown time and time again that these are not true.

3) The author makes spurious leaps to seem to bolster their argument, but
frankly, they're misleading and FUD. "There are attacks which bypass
cookies altogether, thus rendering the threat from cookies themselves if
not obsolete, on their way in that direction" - the threat is not FROM
cookies, but TO cookies. "Will we soon need to encrypt our DNS queries"
ignores the purpose of SSL (authenticity and integrity, and not just
privacy), but as a strawman, sure.

If we're going to quote random blogs, why not
https://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/ or
http://scn.sap.com/community/netweaver/blog/2013/06/23/whos-afraid-of-ssl
or https://www.youtube.com/watch?v=cBhZ6S0PFCY

Now, I don't know the author, I have nothing personal against them, but
there are a lot of genuine mistakes in that article. Hopefully you can
realize them now.

On Sat, Aug 09, 2014 at 11:52:16PM -0700, Ryan Sleevi wrote:
> At the risk of engaging what may be trolling behaviour (non-attributable
> email addresses and all that good jazz), and while a point-by-point
> takedown is not particularly worthy, the author makes a number of
> demonstrably false or misleading claims.
>
> 1) That the issuance of certs increases the likelihood of CA compromise.
> Evidence demonstrates the opposite, but either way, they're orthogonal
> issues entirely. Having more certificates issued does not directly make it
> more likely for a CA (like DigiNotar) to be breached.

I'm curious to know what evidence you think demonstrates that issuing more
certificates *reduces* the risk of CA compromise.  I would say they *are*
orthogonal issues, but you can't have it both ways -- they're
meta-orthogonal (as it were).

I will say that having more certificates issued appears to at least be a
factor in determining whether or not you get de-trusted as a result of a
breach.  While the difference in behaviour between Comodo and DigiNotar in
response to their respective breaches no doubt played a part in the
different outcomes, there was a *lot* of hand-wringing about how many
end-users would be adversely impacted by de-trusting Comodo roots,
indicating it was a factor in the decision-making process.  

- Matt

On Sat, Aug 09, 2014 at 04:53:46PM -0700, David E. Ross wrote:
> Anyone wishing to argue this issue further -- to argue in favor of
> implementing a scheme to encourage all Web sites to be HTTPS with site
> certificates -- should first read
> <http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/>.
>  The blogger is a certificate reseller and also a computer systems
> integrator.  Thus, he is a professional in the area of computer systems,
> including security.

How do you get from "resells certificates and bolts parts together to "he is
a professional in [...] security"?  I won't deny that he is in the computer
systems profession (in the very precise definition of "for a livelihood"),
but beyond that, you're drawing an *exceptionally* long bow.

- Matt

I was a computer systems integrator for over 30 years.  I fully
understand what "integrator" means.  In my career, sopftware integration
often included dealing with secure systems and how they were made secure.

Rosenthal is also a reseller of X.509 subscriber certificates, which
should mean he understands Internet security.  Otherwise, how is he
allowed to sell such certificates?

Add those two concepts together.

On 10/08/14 11:16 PM, David E. Ross wrote:
> On 8/10/2014 4:09 PM, Matt Palmer wrote:
>> On Sat, Aug 09, 2014 at 04:53:46PM -0700, David E. Ross wrote:
>>> Anyone wishing to argue this issue further -- to argue in favor of
>>> implementing a scheme to encourage all Web sites to be HTTPS with site
>>> certificates -- should first read
>>> <http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/>.
>>>  The blogger is a certificate reseller and also a computer systems
>>> integrator.  Thus, he is a professional in the area of computer systems,
>>> including security.
>>
>> How do you get from "resells certificates and bolts parts together to "he is
>> a professional in [...] security"?  I won't deny that he is in the computer
>> systems profession (in the very precise definition of "for a livelihood"),
>> but beyond that, you're drawing an *exceptionally* long bow.
>>
>> - Matt
>>
>
> I was a computer systems integrator for over 30 years.  I fully
> understand what "integrator" means.  In my career, sopftware integration
> often included dealing with secure systems and how they were made secure.
>
> Rosenthal is also a reseller of X.509 subscriber certificates, which
> should mean he understands Internet security.  Otherwise, how is he
> allowed to sell such certificates?
>
> Add those two concepts together.

An appeal to authority isn't much of an argument.

HTTPS and HSTS are still very important for an entirely static site.

The alternative is allowing an attacker to masquerade as the site and
leverage the trust it has built for malicious purposes. If it's a blog,
the latest post may appear to be a link to the attacker's payload with a
stellar review.

Encryption is only half of the picture, as HTTP connections offer no way
to assure the authenticity of the source. Informing users that the
browser is unable to verify the authenticity of the source is not a bad
thing.

It's possible to have authenticated but unencrypted data for a use case
like this, but it's best if the opportunity to screw up by making the
wrong choice is not there in the first place. There's no compelling
reason not to encrypt everything because it's so cheap.

On Sun, August 10, 2014 4:06 pm, Matt Palmer wrote:
>  On Sat, Aug 09, 2014 at 11:52:16PM -0700, Ryan Sleevi wrote:
> > At the risk of engaging what may be trolling behaviour (non-attributable
> > email addresses and all that good jazz), and while a point-by-point
> > takedown is not particularly worthy, the author makes a number of
> > demonstrably false or misleading claims.
> >
> > 1) That the issuance of certs increases the likelihood of CA compromise.
> > Evidence demonstrates the opposite, but either way, they're orthogonal
> > issues entirely. Having more certificates issued does not directly make
> > it
> > more likely for a CA (like DigiNotar) to be breached.
>
>  I'm curious to know what evidence you think demonstrates that issuing more
>  certificates *reduces* the risk of CA compromise.  I would say they *are*
>  orthogonal issues, but you can't have it both ways -- they're
>  meta-orthogonal (as it were).

The evidence is that the majority of compromises/CA events in the past
several years (DigiNotar, TurkTrust, India CCA, ANSSI ) have been
nation-state vanity CAs that issue certificates to small populations. The
'big' CA's events (read: Comodogate, StartSSL) have been significantly
more limited in scope, and have been contained, and have been quickly
remediated (with quick communication on the CA's behalf)

That's not to suggest correlation implies causation, merely that if the
author (or David, by virtue of referencing the author) wishes to support
such an idea, the evidence runs counter to their conclusion.

On Sun, August 10, 2014 8:16 pm, David E. Ross wrote:
>  I was a computer systems integrator for over 30 years.  I fully
>  understand what "integrator" means.  In my career, sopftware integration
>  often included dealing with secure systems and how they were made secure.

That's a very... liberal... conclusion of what integrator means. I've
known integrators who just glued together CMS systems. Does that mean
they're also experts in computer systems?

>
>  Rosenthal is also a reseller of X.509 subscriber certificates, which
>  should mean he understands Internet security.  Otherwise, how is he
>  allowed to sell such certificates?

There are no security requirements for resellers. Resellers are just the
middlemen that facilitate the introduction of the CA to the customer, get
a cut of the proceeds, and in return for such introductions, get to
pretend they have a brand.

Most importantly, resllser != registration authority. The two are,
unsurprisingly, unrelated concepts.

I say this because my dog could be a reseller, if she was allowed to enter
into legal contracts. That's really the ONLY requirement, at the core, of
a reseller.

On Sun, Aug 10, 2014 at 08:16:42PM -0700, David E. Ross wrote:
> On 8/10/2014 4:09 PM, Matt Palmer wrote:
> > On Sat, Aug 09, 2014 at 04:53:46PM -0700, David E. Ross wrote:
> >> Anyone wishing to argue this issue further -- to argue in favor of
> >> implementing a scheme to encourage all Web sites to be HTTPS with site
> >> certificates -- should first read
> >> <http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/>.
> >>  The blogger is a certificate reseller and also a computer systems
> >> integrator.  Thus, he is a professional in the area of computer systems,
> >> including security.
> >
> > How do you get from "resells certificates and bolts parts together to "he is
> > a professional in [...] security"?  I won't deny that he is in the computer
> > systems profession (in the very precise definition of "for a livelihood"),
> > but beyond that, you're drawing an *exceptionally* long bow.
>

> I was a computer systems integrator for over 30 years.  I fully
> understand what "integrator" means.  In my career, sopftware integration
> often included dealing with secure systems and how they were made secure.

"Dealing with" != "competent to assess and recommend".  I deal with the
electrical system in my house, by virtue of using it.  Doesn't mean I'm a
professional electrican.

> Rosenthal is also a reseller of X.509 subscriber certificates, which
> should mean he understands Internet security.

How do you figure?  Being a reseller of SSL certs just means that you're
taking people's money and giving them someone else's certificates.  Even if
a reseller "should" understand Internet security (which isn't the case), is
there any evidence to suggest that he does understand Internet security?

> Otherwise, how is he allowed to sell such certificates?

Who assesses his competence, and is capable of prohibiting him (with
meaningful sanctions) if he is not, in fact, competent?

> Add those two concepts together.

My calculator laughed at me, muttering something about "apples and oranges".
I wonder what that means?

- Matt

On 8/10/2014 8:16 PM, David E. Ross wrote:
> On 8/10/2014 4:09 PM, Matt Palmer wrote:
>> On Sat, Aug 09, 2014 at 04:53:46PM -0700, David E. Ross wrote:
>>> Anyone wishing to argue this issue further -- to argue in favor of
>>> implementing a scheme to encourage all Web sites to be HTTPS with site
>>> certificates -- should first read
>>> <http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/>.
>>>  The blogger is a certificate reseller and also a computer systems
>>> integrator.  Thus, he is a professional in the area of computer systems,
>>> including security.
>>
>> How do you get from "resells certificates and bolts parts together to "he is
>> a professional in [...] security"?  I won't deny that he is in the computer
>> systems profession (in the very precise definition of "for a livelihood"),
>> but beyond that, you're drawing an *exceptionally* long bow.
>>
>> - Matt
>>
>
> I was a computer systems integrator for over 30 years.  I fully
> understand what "integrator" means.  In my career, sopftware integration
> often included dealing with secure systems and how they were made secure.

Let me put "dealing" in context.  I wrote the specifications for the
software including the components that handled the security of
databases, displays, and printouts.  I tested the software in an
end-user environment, after which I sometimes rejected it and sent it
back to the developer.  I prepared the user documentation for the
software.  And I taught classes to U.S. Air Force officers on how to use
the software.  All this was for software systems used to operate
earth-orbiting, classified, military space satellites.  I understand
secure software systems, and Rosenthal's blog makes sense to me.

>
> Rosenthal is also a reseller of X.509 subscriber certificates, which
> should mean he understands Internet security.  Otherwise, how is he
> allowed to sell such certificates?
>
> Add those two concepts together.
>

I will not further defend Rosenthal.  I think he is competent to defend
himself.

You mean satellites like those?:
http://arstechnica.com/security/2014/04/mission-critical-satellite-communications-wide-open-to-malicious-hacking/

Working in a business for 10/20/30/90 years doesn't make you an expert
yet alone authority. One year of experience repeated 20 times doesn't make
you even skilled.

Bring arguments to the table and argue arguments, not who they come from.

And the arguments you brought are weak - only TLS can protect against drive
by eavesdropping - think bored kid with Firesheep in St***ucks. Ergo
you should deploy TLS even on your family instance of OwnCloud, let
alone any commercial website.

Properly deployed TLS has minimal impact on servers running current webapps
and is below measurement uncertainty as far as network load goes.
If you want us to have a different opinion, show us that it is not the case.

--
Regards,
Hubert Kario

On 11/08/14 04:16, David E. Ross wrote:
> Rosenthal is also a reseller of X.509 subscriber certificates, which
> should mean he understands Internet security.  Otherwise, how is he
> allowed to sell such certificates?

I don't often say this, because it's not often true, but...

LOL.

Gerv

Can we please declare this thread closed?  The level of debate has gotten a little low.

--Richard

On Aug 9, 2014, at 7:53 PM, David E. Ross <nobody@nowhere.invalid> wrote:

> On 7/19/2014 11:54 AM, 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
>> dia...@gmail.com
>>
>

> Anyone wishing to argue this issue further -- to argue in favor of
> implementing a scheme to encourage all Web sites to be HTTPS with site
> certificates -- should first read
> <http://www.2rosenthals.net/wordpress/googles-https-everywhere-initiative-not-so-fast-994/>.
> The blogger is a certificate reseller and also a computer systems
> integrator.  Thus, he is a professional in the area of computer systems,

> including security.  Although he has a vested interest in selling site
> certificates, he argues against the idea that all Web sites should be
> HTTPS.
>

> --
> David E. Ross
>
> The Crimea is Putin's Sudetenland.
> The Ukraine will be Putin's Czechoslovakia.
> See <http://www.rossde.com/editorials/edtl_PutinUkraine.html>.

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

Yes, I started this thread. I officially declare this thread closed...even though I have no ability to enforce it.

[Apologies if you've seen this before, it looks like up to a week's worth of
 mail from here has been lost, this is a resend of the backlog]

Chris Palmer <pal...@google.com> writes:

>Firefox 31 data:
>
>on desktop the median successful OCSP validation took 261ms, and the 95th
>percentile (looking at just the universe of successful ones) was over 1300ms.
>9% of all OCSP requests on desktop timed out completely and aren't counted in
>those numbers.

Do you have equivalent data for the TLS connect times?  In other words how
much was TLS being slowed down by including OCSP?

Peter.

FWIW, that's a misquote; I didn't write that.

Chris Palmer <pal...@google.com> writes:

>FWIW, that's a misquote; I didn't write that.

Ooops, sorry, it was posted by Patrick McManus <pmcm...@mozilla.com> (I used
a script to try and resurrect the lost emails for re-send, I suspect something
got mangled somewhere).

So the question should have been addressed to Patrick (or anyone else who
wants to answer, enciphering minds want to know :-).

Peter.

Peter,

I suspect you haven't received an answer because your question doesn't
quite make sense.

In the other thread, Patrick provided the details for how to look up the
details for Mozilla telemetry (http://telemetry.mozilla.org -
unfortunately, HTTPS doesn't work for this domain)

The answer for "how much the TLS connection was being affected by OCSP" is
sort of answered by "How long did OCSP take", which Patrick provided the
details of.

Phrasing the data in terms of overall connection handshake time doesn't
really work either - OCSP is, by design, a serial and blocking process.
You check one cert, then the next, then the next. So that time
accumulates.

However, if you wish to slice the data for your own analysis, well, as Pat
mentioned, Mozilla's data is there.

>From the looks of it, Chrome is capturing a lot more data points in terms
of the SSL connection details, but we saw similar-to-worse performance
across our platforms, including dominant platforms (like Windows), which
have a number of optimizations for revocation checks, and 'marginal'
platforms like OS X, which have a number of limitations in their
revocation checking ability.