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

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Chris Hofmann-2
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 <[hidden email]> 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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

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

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
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

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

ianG-2
In reply to this post by Chris Hofmann-2
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

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

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

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.

--
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

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

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

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

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.

--

KISSIS - Keep It Simple So It's Securable
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

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

Eric Mill
In reply to this post by Chris Hofmann-2
> 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 <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > https://lists.mozilla.org/listinfo/dev-security
> >
> >
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
>



--
konklone.com | @konklone <https://twitter.com/konklone>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

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

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

--

KISSIS - Keep It Simple So It's Securable
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

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

Hanno Böck-4
On Sat, 28 Nov 2015 16:30:05 +0000
Kevin Chadwick <[hidden email]> 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: [hidden email]
GPG: BBB51E42

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

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

--

KISSIS - Keep It Simple So It's Securable
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

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

Kurt Roeckx
In reply to this post by Hanno Böck-4
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

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

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

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?

--

KISSIS - Keep It Simple So It's Securable
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security