Re: HTTP is just fine -- v. HTTP is insecure --> need a better metaphor

> I think we need just enough compliance to make the incentives low for bad
> actors to want to take advantage of.  That will help "preserve the
> leafs/decentralization/http" for some possible valuable things in the
> future.    The challenge here is that "Just enough compliance" is still a
> pretty high bar in this case.

I think that's a pretty good summation of the what the challenge is. We
don't need to get to 100.0% HTTPS use on the web to make corporate and
government surveillance programs no longer worth it, or to make mass
injection attacks ineffective.

But it needs to be much higher than it is, even after a few years of
progress. Perfect measurements seem hard, but Firefox's pageload
measurements for the last 3 releases over the last 3 months suggest that
it's flatlined at around 40%:

https://telemetry.mozilla.org/new-pipeline/evo.html#!aggregates=bucket-0!bucket-1!bucket-2&cumulative=0&end_date=null&keys=&max_channel_version=release%252F42&measure=HTTP_PAGELOAD_IS_SSL&min_channel_version=release%252F40&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2014-05-01&trim=1&use_submission_date=0

The Chrome team said something similar in a recent email to their
security-dev list: "over the Summer and Autumn we measured HTTPS adoption,
and it hasn't gone up much".

https://groups.google.com/a/chromium.org/d/msg/security-dev/uMAno8ezT6k/rTzqNs9tEgAJ

There are still a couple of juggernaut (Western) platforms I can think of
that have yet to move but likely will, Amazon and Netflix. Amazon's move
will make a big difference, because it's shopping history. Companies will
have to make (relatively) above-board deals to get that information, rather
than scoop it out of the network. Netflix browsing is probably less
valuable, but will be *huge* by volume (I've seen it cited as 35% of
internet traffic).

But the long tail is very long, and very wide, and volume isn't the best
metric to measure value. I mean, the Great Cannon attack was only
harnessing *some* users who visited *some* sites using Baidu Analytics, and
that was enough to knock down GitHub for a time.

And more relevantly, the meat and potatoes of everyday life are generally
unprotected. It looks to me like most news, university, non-profit, and
government properties are unencrypted -- all over the world. You can stay
within Silicon Valley's warm encrypted embrace as you search for things and
use social media, but the things you're googling *for*, and the things your
tweets are linking *to*, are still by and large unencrypted.

Most of those sites and services are run by bureaucratic institutions who
don't employ excited, principled technologists. Tech and security aren't
top-of-mind priorities, and the people who do them come through contractors
-- often similarly bureaucratic contractors who also don't always employ
the most excited technologists. These institutions don't respond to angry
tweets or passionate emails, and they don't read your blog posts.

So how do you move those kinds of mountains?

I understand it's really jarring to have a large organization like Mozilla
suddenly tell you they're going to punish you unless you do something you
don't feel like doing, or don't think is necessary for your own thing. But
I personally think it's not realistic to expect to tackle the long tail
without introducing a stick alongside the carrot.

Maybe the reason I don't see Mozilla's deprecation move as so martial or
oppressive is because I don't think it's really aimed at individual
bloggers or site owners. I see Mozilla's (and Google's) deprecation pushes
as constructively affecting two major audiences:

* Persuading apathetic bureaucrats at large organizations to roll their
eyes and add "HTTPS transition" line items to their Fiscal Year 2016 and
2017 budgets.

* Finally giving enthusiasts inside small to medium organizations the
headline they need to win the argument they've been losing for months or
years.

Maybe creating the sense that "browsers are killing HTTP" plus the coming
availability of Let's Encrypt is the pincer attack that convinces
Squarespace to allocate the non-trivial resources towards adding automatic
HTTPS support for custom domains. Maybe "browsers are killing HTTP" plus
the Interactive Advertising Bureau's call for encryption is what empowers a
team inside CNN to start the non-trivial process of measuring encrypted ad
inventory. Maybe if Squarespace and CNN manage to lead and ship that, their
competitors start moving to keep up.

I don't have any knowledge about those particular companies, but I
definitely see those dynamics play out at other very similar institutions.

So I can understand why it feels like Mozilla is forcing *you* to use
HTTPS, but I think it's better understood as contributing to larger
political change -- which hopefully ultimately removes or reduces any work
you need to do. I know that's the principal way it's affected my life, and
it's a larger change I think is worth contributing to.

-- Eric

On Wed, Nov 25, 2015 at 2:51 PM, Chris Hofmann <[email protected]> wrote:

> I'm sad to see a level of frustration so high that people are wanting to
> give up on this discussion.
>
> There are some important issues that need addressing and it seems like
> there is all too much cross talking on how to get to a reasonable and
> effective solution.
>
> Eric Mill's analysis was very good and I think gets at the heart of
> something worthwhile in doing.
>
> > https://konklone.com/post/were-deprecating-http-and-its-going-to-be-okay
>
> In short, I see power moving away from the leafs and devolving back into
> the center, where power has been used to living for thousands of years.
>
> What animates me is knowing that *we can actually change this dynamic* by
> making strong encryption ubiquitous. We can force online surveillance to be
> as narrowly targeted and inconvenient as law enforcement was always meant
> to be. We can force ISPs to be the neutral commodity pipes they were always
> meant to be. On the web, that means HTTPS.
> From this it seems a couple of points worth discussion.
>
> 1) Are there other approaches than having browsers primary only support
> universal strong encryption that might work to stop widespread
> surveillance, ot the future possibility of ever increasing surveillance?
> Seems unlikely, but still worth analysis.  It would be hard to legislate
> anti-surveillance given the nature and powers of the players involved.  One
> other possibility is to try and make/keep encryption widespread enough to
> make it not worth the economic time and effort to watch traffic and inject
> cookies and content.  In this case you don't need personal blogs with
> non-critical content sharing to be encrypted if the value is low to ISP's
> and other participants in the network stack.  That still doesn't solve the
> problem with organizations like the NSA that have had the mandate to
> capture all network traffic on and off for many decades now.
>
> 2) This second part is around how best to create a metaphor that describes
> to a wide range of people about the risks they are encountering.  I think
> that's a major area for improvement here and at the focal point of the back
> an forth in this thread.  It seems that the argument is just around HTTP
> being safe or unsafe, without really defining what safety is or how it
> applies to both the situation that a user is in at an exact moment in time
> or potentially at some time in the future.
>
> These comments help to get some focus back on that area of the discussion/
>
> > > if mozilla says my site is insecure.
>
> > mozilla doesn't say that your site is insecure
>
> > mozilla wants to say that the connection between the computer and your
> site is insecure
>
> Exactly.  Just as it would be inappropriate for an alarm in my car to go
> off if I pull out of the driveway without my seatbelt attaached, and an
> alarm tried to communcate "you don't have your seatbelt attached, your're
> going crash and kill yourself"  It would not be appropriate to over (or
> under) communcate about the exact risks you are currently encountering.
> These things are more to the truth.
>
> -My seatbelt is not attached.
> -I might be involved in a crash at some point in the future (insert
> statically pct here)
> -When that crash happens having the seatbelt increases my chance of
> survival (insert more stats)
>
> The case of the auto industry go from zero seatbelts to near universal
> seatbelt use might have some valuable lessons for us to learn from here.
> Certainly there was legislation, but there was also some amount of
> increased awareness and personal experience created around the chances of
> being invloved in a crash, and how seatbelts increased survival rates.
>
> If the goals here are really to:
>
> -force online surveillance to be as narrowly targeted and inconvenient for
> law enforcment
> -force ISPs to be the neutral commodity pipes and/or make survielance
> economically unattractive
>
> Lets just say that.  Let's say that to users,
>
>  -- the pipe you are on to this website is a bit leaky.  the website can
> help fix the leaky pipe by using https, and this will make the web better
> now and in the future.
>
> lets say that to Website Adminstrators,
>
>  -- join the movement to stop on-line surveillance that slows your
> connection to users
>     and robs you of the economic value you provide...
>
> lets also say this to people with personal blogs that probably won't get or
> attract is kind of surveillance that we are talking about, but will see
> this as a way to help and important cause.
>
> Lets measure against these goal, and think creatively about ways to reach
> that goal rather than the pounding away a one dogma or another, or one
> technical approach or other.  Along the way lets also try to "preserve the
> leafs" and the decentralized way the internet as operated.  That's
> important too.
>
> In this way we might attract more people to take action.  Al of those
> people might *want* there personal blogs using https if they knew to might
> be helpful toward these causes.  All of the people running sites and were
> having their economic value taxes/stripped off by ISPs might want to
> implement https.  All of the users that viewed http content might *want* to
> be advocates to these parties to make sure the stay on track for making
> https as wide spread as possible (even if not ubiquitous).
>
> One thing I might disagree with Eric on is either the ability or the need
> to *force* ubiquity.
>
> I think we need just enough compliance to make the incentives low for bad
> actors to want to take advantage of.  That will help "preserve the
> leafs/decentralization/http" for some possible valuable things in the
> future.    The challenge here is that "Just enough compliance" is still a
> pretty high bar in this case.
>
> Another hard part is this is a bit of tragedy of the commons problem where
> no one wants to act or has incentive unless everyone acts to try and make
> things better.  Its worthwhike thinking about this problem in that light as
> well.
>
> -chofmann
>
>
>
>
> On Wed, Nov 25, 2015 at 8:50 AM, Hubert Kario <[email protected]> wrote:
>
> > On Wednesday 25 November 2015 16:07:10 Kevin Chadwick wrote:
> > > it's getting tiresome when the same bull keeps being
> > > repeated on the same topic on the same list without included
> > > justification that has had any consideration or time spent
> > > and at the same time the opposite is stated whimsically and very
> > > strongly yet incorrectly with the intention of stopping responses.
> > >
> > > Anyway, I give up, some people obviously have irremovable filters on
> > > their brains
> >
> > "funny" you say that, I have exact same feelings
> >
> > > if mozilla say my site is insecure.
> >
> > mozilla doesn't say that your site is insecure
> >
> > mozilla wants to say that the connection between the computer and your
> > site is insecure
> >
> > > I shall simply tell
> > > customers that it is more secure than mozilla.com and mozilla are dumb
> > > and believe that they will believe me.
> >
> > and again with the ad hominems... I seriously wonder why I'm even
> > bothering at this point
> >
> >
> > Please, explain why we should not have protections against unlikely, but
> > conceivable attacks (attacks that are either documented, or have easy to
> > use tools to facilitate them).
> >
> > yes, the few times you went to the coffee place and used unsecured WiFi
> > you may not have gotten your cookies sniffed and didn't get malware
> > injected into javascript (or jpg files that exploit bugs in renderers, r
> > different account numbers for wire-transfers... pick your poison)
> >
> > you may live in a place where your ISP doesn't want to get few extra
> > pennies by replacing ads on pages you watch, and you may not have
> > neighbours that try to sniff credit card numbers (or SSNs) from
> > connections that go through the shared cable TV network
> >
> > you may even leave your doors unlocked because you live in a house in
> > the middle of a prairie
> >
> > or live in a city and forgot to close the doors few times and nothing
> > bad happened
> >
> > are you really trying to say that because of that few instances we all
> > should leave our doors unlocked and boycott insurance companies that
> > expect you to lock your homes?
> >
> > that because there are other technologies for securing communications we
> > shouldn't use the one that is easiest to use by normal users? one that
> > does not require any additional setup by the users?
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
> >
> > _______________________________________________
> > dev-security mailing list
> > [email protected]
> > https://lists.mozilla.org/listinfo/dev-security
> >
> >
> _______________________________________________
> dev-security mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security