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

[Chris Hofmann]

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 <hka...@redhat.com> 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
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
>

[Kevin Chadwick]

> -force ISPs to be the neutral commodity pipes and/or make survielance
> economically unattractive

Well that's a reason that maybe has power (I wrote to the UK prime
minister about it) to reverse my own decision, however I find it very
very hard to make my own services more vulnerable to DDOS in order to
teach ISPs that I have already switched away from that they shouldn't be
conducting dangerously exploitable activity at layer 7 that they such
as Talk Talk/Huawei certainly are not competent enough to perform.

A builtin letsencrypt wordpress plugin enabled by default would
certainly aid your goal significantly, btw. I had to go to extra
lengths for free!! to enable https on the admin login of a friends
wordpress site despite him having paid a supposedly professional web
development company to set it up,

--

KISSIS - Keep It Simple So It's Securable

[Boris Zbarsky]

On 11/25/15 2:51 PM, Chris Hofmann wrote:
> 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

I should note that most modern cars have exactly such an alarm: they
start beeping at you if the car goes over some (fairly low) speed and
the driver's seat belt is not buckled.

It's a fairly effective UI affordance to get people who simply forgot to
buckle to do so, though of course it won't deter an obstinate
non-buckler (who will just buckle the belt behind his or her back).

> and an
> alarm tried to communcate "you don't have your seatbelt attached, your're
> going crash and kill yourself"

It doesn't do that, though. It just beeps annoyingly. ;)

All of this is clearly veering slightly off topic, of course.

-Boris

[Chris Hofmann]

On Wed, Nov 25, 2015 at 1:20 PM, Boris Zbarsky <bzba...@mit.edu> wrote:

> On 11/25/15 2:51 PM, Chris Hofmann wrote:
>

>> 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
>>
>
> I should note that most modern cars have exactly such an alarm: they start
> beeping at you if the car goes over some (fairly low) speed and the
> driver's seat belt is not buckled.
>
> It's a fairly effective UI affordance to get people who simply forgot to
> buckle to do so, though of course it won't deter an obstinate non-buckler
> (who will just buckle the belt behind his or her back).
>

> and an
>> alarm tried to communcate "you don't have your seatbelt attached, your're
>> going crash and kill yourself"
>>
>

> It doesn't do that, though. It just beeps annoyingly. ;)
>
> All of this is clearly veering slightly off topic, of course.
>
> -Boris
>

The point was to try and make the warnings and operation of the
vehicle/software match the risks.

That's how the seat belt example got to something productive and higher
rates of compliance.

minor beeping annoying signal, backed up with lots of side channel
explanation of why seat belts were important, plus case study and example
of how they saved lives had impact on people. thats the combination is
what worked. if the seatbelt was tied to the ignition system they may have
been great backlash and people were forced to engage the seatbelt before
starting the car it's likely to have created backlash. the same kind of
backlash seen in this thread by people who would normally be supportive of
the larger goal.

this is how the "http is unsafe" warning and possible later prohibition in
the browser down the line might be getting off track, and away from the
main goal of stopping surveillance. If the "unsafe" risks are overstated
in situations where its not exactly true then its going to be counter
productive. If the warning are gentle and communicating the goal of
stopping surveillance we might get more traction on reaching that goal.

Its just a small twist in the way we approach and talk about the problem.
Thinking about this as project to stop surveillance, rather than a project
to shutdown http. starting to reduce, or nearly eliminating all, use of
http can help, but certainly will not be the only thing needed to stop
surveillance. Let's all work together and keep people focused on the
larger problem. That's what I think we should be asking for.

-chofmann

[Robert Kaiser]

Boris Zbarsky schrieb:

> It doesn't do that, though. It just beeps annoyingly. ;)
>
> All of this is clearly veering slightly off topic, of course.

To bring it back on topic: Should we make the browser beep annoyingly
when using a non-secure connection?

(I prefer to say HTTP being "non-secure" or "not secure" vs. "insecure"
as while that means exactly the same, it's psychologically easier to
accept - HTTP is not suddenly becoming "insecure", it's just that it
never was secure in the first place.)

And that comment about beeping is only half-joking, we probably will
need warning to go more intense after some time. OTOH, one issue with
the comparison is that in the car example, the user can easily do
something to secure themselves and use the seatbelt - while in our case,
the user cannot make the site they want to use secure, the website
author has to. But the user still wants to use the website and/or its
content, so unfortunately we end up "punishing" them for wanting to see
that content, and that's a bad experience and makes the user angry,
without necessarily making the website author/owner/maintainer react.
Unfortunately, sitting at the client side there makes this a difficult
situation.

KaiRo

[Chris Hofmann]

Personally I like the leaky pipe metaphor better.

The problem is not with the site. Its with the pipe that connects a user
to the site.

The next stage is to explain to all parties what's needed and involved in
taking action to fix the leaky pipes of the internet just enough to make
progress on stampping out surveillance, and future risks of increasing
surveillance.

-chofmann

On Wed, Nov 25, 2015 at 6:10 PM, Robert Kaiser <ka...@kairo.at> wrote:

> Boris Zbarsky schrieb:

>
>> It doesn't do that, though. It just beeps annoyingly. ;)
>>
>> All of this is clearly veering slightly off topic, of course.
>>
>

> To bring it back on topic: Should we make the browser beep annoyingly when
> using a non-secure connection?
>
> (I prefer to say HTTP being "non-secure" or "not secure" vs. "insecure" as
> while that means exactly the same, it's psychologically easier to accept -
> HTTP is not suddenly becoming "insecure", it's just that it never was
> secure in the first place.)
>
> And that comment about beeping is only half-joking, we probably will need
> warning to go more intense after some time. OTOH, one issue with the
> comparison is that in the car example, the user can easily do something to
> secure themselves and use the seatbelt - while in our case, the user cannot
> make the site they want to use secure, the website author has to. But the
> user still wants to use the website and/or its content, so unfortunately we
> end up "punishing" them for wanting to see that content, and that's a bad
> experience and makes the user angry, without necessarily making the website
> author/owner/maintainer react. Unfortunately, sitting at the client side
> there makes this a difficult situation.
>
> KaiRo
>

[Robert Kaiser]

Chris Hofmann schrieb:

> Personally I like the leaky pipe metaphor better.
>
> The problem is not with the site. Its with the pipe that connects a user
> to the site.

Maybe a better word to use would be "unprotected" - I guess if we say
HTTP is "an unprotected connection" that also makes clear that anything
in traffic on that connection can be viewed and/or altered before arriving.

KaiRo

[ianG]

On 25/11/2015 19:51 pm, Chris Hofmann wrote:
> I'm sad to see a level of frustration so high that people are wanting to
> give up on this discussion.

Yeah. But it's Mozilla's fault - not the people's.

> 1)... stop widespread surveillance,...
> 2) ... 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.

This is the problem that everyone in Mozilla is not facing up to.

Unfortunately there's no point in entering it because without a cultural
change, you won't be able to deal with the results.

Just one small result: your 1) is actually the worry of the developer
community, not the users. In order to figure out what users are worried
about, you'd have to ... ask them.

And if they told you something different to what the developers wanted,
then what?

Mozilla are spectacularly ill-equipped to ask that question - without a
cultural change internally which actually goes as far as (say) changing
the manifesto, Mozilla is locked out of that game.

> 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

Not really. Mozilla wants to say that the model is operating correctly
and this site is in/outside its approved model. To say "secure" or
"insecure" is to say something outside Mozilla's legal comfort zone.

Developers OTOH want to say it is secure or insecure. But developers
aren't responsible.

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

All analogies are good until they are not. If one is to apply that to
the situation, the mistake might be analogised as - yes, you are
supplying seats with seatbelts, and they are very good seats and
fantastically safe seatbelts. But have you noticed that the seatbelt
design assumed cars, and you don't actually supply seats to cars?

So who do you supply seats to? And what might make *them* safer?

iang

[ianG]

On 26/11/2015 02:10 am, Robert Kaiser wrote:
> Unfortunately, sitting at the client side there makes this a difficult
> situation.

Yup - this is why you will never be able to secure the user. Because
you're only sitting at one point in the chain.



iang

[Hubert Kario]

On Thursday 26 November 2015 08:14:21 ianG wrote:
> > 1)... stop widespread surveillance,...
> > 2) ... 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.
>
> This is the problem that everyone in Mozilla is not facing up to.
>
> Unfortunately there's no point in entering it because without a
> cultural change, you won't be able to deal with the results.
>
> Just one small result: your 1) is actually the worry of the developer
> community, not the users. In order to figure out what users are
> worried about, you'd have to ... ask them.

And people did ask them and did receive responses saying "yes we want
this program shut down":
https://www.youtube.com/watch?v=XEVlyP4_11M

you just need to ask correct question to get people to understand the
issue

> > 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
>
> Not really. Mozilla wants to say that the model is operating
> correctly and this site is in/outside its approved model. To say
> "secure" or "insecure" is to say something outside Mozilla's legal
> comfort zone.
>
> Developers OTOH want to say it is secure or insecure. But developers
> aren't responsible.

The browser has insight in the protections used on the connection
between it and the site. It can make automated and correct assessments
of the security (integrity and confidentiality) of those connections.

Firefox still doesn't say anything about the *server* being secure or
not, it says "Secure Connection". This won't change.

[ianG]

On 26/11/2015 11:37 am, Hubert Kario wrote:
> On Thursday 26 November 2015 08:14:21 ianG wrote:
>>> 1)... stop widespread surveillance,...
>>> 2) ... 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.
>>
>> This is the problem that everyone in Mozilla is not facing up to.
>>
>> Unfortunately there's no point in entering it because without a
>> cultural change, you won't be able to deal with the results.
>>
>> Just one small result: your 1) is actually the worry of the developer
>> community, not the users. In order to figure out what users are
>> worried about, you'd have to ... ask them.
>
> And people did ask them and did receive responses saying "yes we want
> this program shut down":
> https://www.youtube.com/watch?v=XEVlyP4_11M

:) great show. That was worth watching *all the way through* !

> you just need to ask correct question to get people to understand the
> issue

Right. That guy knows how to frame things, he should be in security :)

Along those lines, asking whether people are worried about mass
surveillance is going to walk into some cultural artifacts. In Europe
for example, the general feeling is more about government protecting the
people, so mass surveillance is more expected. What they fear is
corporate surveillance. Whereas Americans tend to be the reverse.

Then, if you go to various other quarters like Africa which is now
mobile-enabled, they won't understand the question (unless they are
western educated). It will be something between "well of course!" or
"err..." or "how does this effect battery life?"

Point being, you have to get down and dirty to find out what is really
worrying people. And whether you can help. If you pick your threat
models from your circle of people, you've already lost.

>>> 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
>>
>> Not really. Mozilla wants to say that the model is operating
>> correctly and this site is in/outside its approved model. To say
>> "secure" or "insecure" is to say something outside Mozilla's legal
>> comfort zone.
>>
>> Developers OTOH want to say it is secure or insecure. But developers
>> aren't responsible.
>
> The browser has insight in the protections used on the connection
> between it and the site. It can make automated and correct assessments
> of the security (integrity and confidentiality) of those connections.
>
> Firefox still doesn't say anything about the *server* being secure or
> not, it says "Secure Connection". This won't change.

We are in full agreement. Firefox does secure connections. Within a
security model (assumptions). What Firefox doesn't do is security.

Security is something different. Security is what users need. In the
context of that above video, SnapChat gets it right.



iang

[Kevin Chadwick]

> > Firefox still doesn't say anything about the *server* being secure or
> > not, it says "Secure Connection". This won't change.
>
>
> We are in full agreement. Firefox does secure connections. Within a
> security model (assumptions). What Firefox doesn't do is security.

I feel my concern here is being missed; if users interpret it to mean a
site is insecure rather than the connection not being encrypted which
is likely (without craeful consideration by mozilla) then you may be
damaging a site (possibly libellous) that uses TLS on some pages but is
actually far more secure than facebook that now uses encrypted
connections for every page but allows the server to write it's own
pages for example.

[Eric Mill]

> 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 <chof...@mozilla.com> wrote:

> I'm sad to see a level of frustration so high that people are wanting to
> give up on this discussion.
>

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

> -chofmann
>
>
>
>

> On Wed, Nov 25, 2015 at 8:50 AM, Hubert Kario <hka...@redhat.com> 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
> >

> > --
> > 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
> > dev-se...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security
> >
> >
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>

--
konklone.com | @konklone <https://twitter.com/konklone>

[Kevin Chadwick]

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

I am an enthusiast inside a currently small organisation and whilst I
may encourage adoption generally, it is not about necessary, it is about
mozilla forcing me or not to choose between two actions, both of which
are detrimental to my business.

1./ DDOS amplification meaning it's harder to keep any parts of my
sites and future sites running and not just http pages, should such an
attack occur. (This is important at most scales). It's probably
worth noting that wasting extra redundant resources on protection here
would actually be far worse for the world.

2./ Whatever this "stick" is, which will just seriously affect my
view and advocacy of mozilla and may lead to sites actually stating
the truth behind this stick in their FAQ.

People should be encouraged like the green bar (which is
technically very close to pointless btw) and not threatened. I believe
googles policy is meant to be "no harm". How about mozilla's??

[Hanno Böck]

On Sat, 28 Nov 2015 16:30:05 +0000
Kevin Chadwick <m8il...@gmail.com> wrote:

> 1./ DDOS amplification meaning it's harder to keep any parts of my
> sites and future sites running and not just http pages, should such an
> attack occur. (This is important at most scales). It's probably
> worth noting that wasting extra redundant resources on protection here
> would actually be far worse for the world.

This is the second time I read ddos amplification in this thread.

DDOS amplification is an issue where UDP services (mostly ntp and dns)
send a reply to potentially forged packets that is larger than the sent
package. This can be abused for ddos attacks.

This has nothing to do with https. Not at all. HTTPS won't make ddos
amplification any different, it happens on completely different
protocols.

--
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

[Kevin Chadwick]

> This is the second time I read ddos amplification in this thread.
>
> DDOS amplification is an issue where UDP services (mostly ntp and dns)
> send a reply to potentially forged packets that is larger than the sent
> package. This can be abused for ddos attacks.
>
> This has nothing to do with https. Not at all. HTTPS won't make ddos
> amplification any different, it happens on completely different
> protocols.

Not true at all there are many forms, SSL as a form of amplification can
wreak major havoc. A 100x amplification was demonstrated by tying
together attacks involving DNSSEC and TLS.

https://www.stateoftheinternet.com/types-of-ddos-attacks.html

[Ben Bucksch]

Hey Chris, thanks for your balanced stance. That's how I know you :)

Chris Hofmann wrote on 26.11.2015 04:04:
> taking action to fix the leaky pipes of the internet just enough to make
> progress on stampping out surveillance, and future risks of increasing
> surveillance.

The thing is: There is no technical solution against governments.
GSM has crypto. And built-in backdoors. And the crypto is weak.

TLS is weak crypto, because it relies on a third party (actually
hundreds of third parties) to vet my communication partner. That's
inherently insecure, and I think it was deliberate. It plays into the
hands of governments. At the time when SSL was invented, the government
still had to approve crypto exports (I'm sure you still vividly remember
the time, Chris :) ), and made sure they didn't have any problem with
surveillance. Since then, the NSA made a little progress on one or two
fronts.

The NSA hacked Google data centers (see e.g. Google Analytics), hacked
Linux, hacked ISPs, telcos and core routers. Dell and Lenovo added root
keys to their computers and allowed all traffic to be intercepted.

If none of that works, they'll just pass more legislation.

Assuming that TLS will lock out the NSA is simply not taking history
into account.

Ben

[Ben Bucksch]

Chris Hofmann wrote on 25.11.2015 20:51:
> 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.

I completely agree with this. Making TLS easier to deploy is great.
Effectively forcing it is not great.

Once you have all the big sites on SSL-only, you probably have 80% of
the internet traffic and 95% of commercially interesting traffic on SSL
only. That should meet your defined "bar".

We might be getting there just by discouraging password forms to be on
non-https pages. I know that one of the biggest German ISPs are
switching their portal to https only precisely because of this
particular change in Firefox 44 (IIRC), and they'll switch in January.
Many of the big portals have accounts (Google, Facebook, YouTube, Yahoo,
ISP frontpages with their webmail etc.), so that alone might be
sufficient to reach 60% of Internet traffic.

If we get the big newspaper sites to enable TLS as well, we're probably
at 90%. These news sites are holding off mostly because of advertizing
networks. So, that's the angle to improve here.

The "long tail" of small sites are probably 98% of the sites in numbers,
but only 10% in traffic. Still they are important for free speech and
the freedom and innovation of the web.

Ben

[Kurt Roeckx]

On 2015-11-28 19:13, Kevin Chadwick wrote:
>> This is the second time I read ddos amplification in this thread.
>>
>> DDOS amplification is an issue where UDP services (mostly ntp and dns)
>> send a reply to potentially forged packets that is larger than the sent
>> package. This can be abused for ddos attacks.
>>
>> This has nothing to do with https. Not at all. HTTPS won't make ddos
>> amplification any different, it happens on completely different
>> protocols.
>
> Not true at all there are many forms, SSL as a form of amplification can
> wreak major havoc. A 100x amplification was demonstrated by tying
> together attacks involving DNSSEC and TLS.

The SSL/TLS attack is that you can make the server use more CPU time
than the client.

The DNSSEC thing is probably just about a DNS reflection attack, but
that a DNSSEC enabled domain usually returns more data. There are also
DNSSEC implementations that sign on the fly so you can get those to use
more CPU too.

I'm not sure what you mean with 100x when combining DNSSEC and TLS, and
what is exactly 100 times more.


Kurt

[Kevin Chadwick]

> > Not true at all there are many forms, SSL as a form of amplification can
> > wreak major havoc. A 100x amplification was demonstrated by tying
> > together attacks involving DNSSEC and TLS.
>

> The SSL/TLS attack is that you can make the server use more CPU time
> than the client.
>
> The DNSSEC thing is probably just about a DNS reflection attack, but
> that a DNSSEC enabled domain usually returns more data. There are also
> DNSSEC implementations that sign on the fly so you can get those to use
> more CPU too.
>
> I'm not sure what you mean with 100x when combining DNSSEC and TLS, and
> what is exactly 100 times more.

Firstly my main objection is simply around the notion of SSL
*everywhere* being so heavily advocated and any opposition being
mocked. Whilst some features that I am not aware of yet like GPU usage
over http *insecure* warnings may be a concern. I would never send a
password field over http, as why have the password in the first place.

I have to admit that I forget the details of the demonstration and
didn't have time to look into it very deeply, so whilst secure
re-negotiation could possibly be used to amplify connection saturation
I am guessing it may have been 100x server resource consumption.
Unfortunately a quick search doesn't turn up the info that could well
have been connection saturation and I have so much to do before xmas,
sorry.

I have however set my server up to drop TLS in an arguably feeble but
perfectly valid effort to maximise our chances of delivering any
content under an attack that would likely also aid any DDOS protection
service too. SSH will likely be a higher priority for protection than
SSL for our business in any case and custom measures may be used there.

When we can afford a service like cloudfare and find we can use it
without adding unwanted javascript and analytics to our sites then I
guess but am not completely sure that that will just make it less likely
that we would need to block TLS or port 443 but not remove the measure
as a last resort defence entirely?