http marked insecure

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

http marked insecure

Lisa Nocera
I recently saw mockups of a future FF where http is marked insecure. I think it was a slide deck linked from planet.mozilla.org. Anyone have this link? I can't find it...
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: http marked insecure

Daniel Veditz-2
Experimental brainstorm:
https://people.mozilla.org/~fqueze2/slides/fosdem2015/#28.0

The point of that slide was the additional content on site info panel, not
so much the specific treatment of the different connection classes. Given
the struggle the security team had to break our monochrome color scheme to
get a colored warning when a secure page includes insecure scripts I'm
fairly sure that angry red is going to get toned down.

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

Re: http marked insecure

Eric Mill
Has anyone from Mozilla suggested that Firefox is interested in pursuing
this, at least at the same abstract "somehow" level that Chrome has
expressed? I know it'd help me a lot to be able to say that "browsers" are
planning to do this, and not just "Chrome".

On Wed, Mar 4, 2015 at 11:59 AM, Daniel Veditz <[hidden email]> wrote:

> Experimental brainstorm:
> https://people.mozilla.org/~fqueze2/slides/fosdem2015/#28.0
>
> The point of that slide was the additional content on site info panel, not
> so much the specific treatment of the different connection classes. Given
> the struggle the security team had to break our monochrome color scheme to
> get a colored warning when a secure page includes insecure scripts I'm
> fairly sure that angry red is going to get toned down.
> ​
> -
> ​Dan Veditz​
> _______________________________________________
> 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 marked insecure

Daniel Veditz-2
On Wed, Mar 4, 2015 at 3:22 PM, Eric Mill <[hidden email]> wrote:

> Has anyone from Mozilla suggested that Firefox is interested in pursuing
> this, at least at the same abstract "somehow" level that Chrome has
> expressed? I know it'd help me a lot to be able to say that "browsers" are
> planning to do this, and not just "Chrome".
>

I don't know that we have buy-in from the product team although Florian's
slides leave me hopeful. I can't promise "we will do this" or what exactly
we will do when we get there, but the security team is pursuing this.

It's not exactly a controversial stand, look at the standards bodies
Mozilla participates in:
https://tools.ietf.org/html/rfc7258
http://www.w3.org/2001/tag/doc/web-https

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

Re: http marked insecure

Richard Barnes
Hey Eric,

I would be prepared to say that we're considering it at about the same
level that Chrome is.  (In fact, looking back at the original thread, I
said "I think there's a fair degree of interest in this on the Mozilla
side.")  As Florian's presentation indicates, there are some ideas being
tossed around.

The main question is just "when".  This hasn't been a hugely high priority
for us so far, since there's a lot of daylight between the 70% HTTP usage
levels and a level where an insecure indication would be appropriate.  An
insecure indication is good for moving from HTTP from "minority" downwards
towards "very rare"; it's counter-productive to have a warning indicator
that is active a significant percentage of the time.

So the best focus for now is on better measuring HTTP/HTTPS usage,
establishing some thresholds, and being prepared to turn things on when the
time comes.

--Richard

On Wed, Mar 4, 2015 at 7:31 PM, Daniel Veditz <[hidden email]> wrote:

> On Wed, Mar 4, 2015 at 3:22 PM, Eric Mill <[hidden email]> wrote:
>
> > Has anyone from Mozilla suggested that Firefox is interested in pursuing
> > this, at least at the same abstract "somehow" level that Chrome has
> > expressed? I know it'd help me a lot to be able to say that "browsers"
> are
> > planning to do this, and not just "Chrome".
> >
>
> I don't know that we have buy-in from the product team although Florian's
> slides leave me hopeful. I can't promise "we will do this" or what exactly
> we will do when we get there, but the security team is pursuing this.
>
> It's not exactly a controversial stand, look at the standards bodies
> Mozilla participates in:
> https://tools.ietf.org/html/rfc7258
> http://www.w3.org/2001/tag/doc/web-https
>
> -Dan Veditz
> _______________________________________________
> 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 marked insecure

Eric Mill
On Wed, Mar 4, 2015 at 8:07 PM, Richard Barnes <[hidden email]> wrote:

> I would be prepared to say that we're considering it at about the same
> level that Chrome is.  (In fact, looking back at the original thread, I
> said "I think there's a fair degree of interest in this on the Mozilla
> side.")  As Florian's presentation indicates, there are some ideas being
> tossed around.
>

That's terrific to hear. I think to really be at Chrome's level of
consideration though -- for the outside world to be able to say "Mozilla is
doing this" -- you'd have to have a permalink somewhere
<https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure>,
the way that Chrome does, stating that it's the intention of the team to
figure out a way to do this, somehow, someday.


>
> The main question is just "when".  This hasn't been a hugely high priority
> for us so far, since there's a lot of daylight between the 70% HTTP usage
> levels and a level where an insecure indication would be appropriate.  An
> insecure indication is good for moving from HTTP from "minority" downwards
> towards "very rare"; it's counter-productive to have a warning indicator
> that is active a significant percentage of the time.
>
> So the best focus for now is on better measuring HTTP/HTTPS usage,
> establishing some thresholds, and being prepared to turn things on when the
> time comes.
>

That sounds totally right to me, and I think the Chrome team feels the same
way. There's an extent to which going out on a limb and having a public
declaration can help to self-fulfill that prophecy.

-- Eric


>
>
> --Richard
>
> On Wed, Mar 4, 2015 at 7:31 PM, Daniel Veditz <[hidden email]> wrote:
>
>> On Wed, Mar 4, 2015 at 3:22 PM, Eric Mill <[hidden email]> wrote:
>>
>> > Has anyone from Mozilla suggested that Firefox is interested in pursuing
>> > this, at least at the same abstract "somehow" level that Chrome has
>> > expressed? I know it'd help me a lot to be able to say that "browsers"
>> are
>> > planning to do this, and not just "Chrome".
>> >
>>
>> I don't know that we have buy-in from the product team although Florian's
>> slides leave me hopeful. I can't promise "we will do this" or what exactly
>> we will do when we get there, but the security team is pursuing this.
>>
>> It's not exactly a controversial stand, look at the standards bodies
>> Mozilla participates in:
>> https://tools.ietf.org/html/rfc7258
>> http://www.w3.org/2001/tag/doc/web-https
>>
>> -Dan Veditz
>> _______________________________________________
>> 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 marked insecure

Kevin Chadwick-2


> On Wed, Mar 4, 2015 at 8:07 PM, Richard Barnes <[hidden email]> wrote:
>
> > I would be prepared to say that we're considering it at about the same
> > level that Chrome is.  (In fact, looking back at the original thread, I
> > said "I think there's a fair degree of interest in this on the Mozilla
> > side.")  As Florian's presentation indicates, there are some ideas being
> > tossed around.
> >  
>
> That's terrific to hear. I think to really be at Chrome's level of
> consideration though -- for the outside world to be able to say "Mozilla is
> doing this" -- you'd have to have a permalink somewhere
> <https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure>,
> the way that Chrome does, stating that it's the intention of the team to
> figure out a way to do this, somehow, someday.
>
>
> >
> > The main question is just "when".  This hasn't been a hugely high priority
> > for us so far, since there's a lot of daylight between the 70% HTTP usage
> > levels and a level where an insecure indication would be appropriate.  An
> > insecure indication is good for moving from HTTP from "minority" downwards
> > towards "very rare"; it's counter-productive to have a warning indicator
> > that is active a significant percentage of the time.
> >
> > So the best focus for now is on better measuring HTTP/HTTPS usage,
> > establishing some thresholds, and being prepared to turn things on when the
> > time comes.
> >  
>
> That sounds totally right to me, and I think the Chrome team feels the same
> way. There's an extent to which going out on a limb and having a public
> declaration can help to self-fulfill that prophecy.
>

This is a completely flawed strategy in I would guess many minds
especially those with a security background following what I call
KISSIS (Keep it simple so it's securable). I realise web browsers don't
follow this principle with Ted Unngst recently starting a project to
replace/do JIT properly. I have no problem with saying http pages may
not be secure but think the word insecure is misleading.

Expecting everyone to move to https is actually suggesting bad practice,
not good practice. Your server is actually less secure with a larger
attack footprint, and I said this before heartbleed. SSL uses more
resources which added up across the world will be huge and simply a
waste largely for no benefit (gpg and windows signing upgrades from
sha1 are still needed for downloads etc. but only the keyserver needs
ssl which some refuse annoyingly for false sense of security reasons
anyway (CA)). Using ssl has been demonstrated to open up servers to 100x
DOS amplification and so should not be used unless necessary. I always
was an advocate of google searches being https if that shows balance
however.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: http marked insecure

ianG-2
On 5/03/2015 07:47 am, Kevin Chadwick wrote:

>
>
>> On Wed, Mar 4, 2015 at 8:07 PM, Richard Barnes <[hidden email]> wrote:
>>
>>> I would be prepared to say that we're considering it at about the same
>>> level that Chrome is.  (In fact, looking back at the original thread, I
>>> said "I think there's a fair degree of interest in this on the Mozilla
>>> side.")  As Florian's presentation indicates, there are some ideas being
>>> tossed around.
>>>
>>
>> That's terrific to hear. I think to really be at Chrome's level of
>> consideration though -- for the outside world to be able to say "Mozilla is
>> doing this" -- you'd have to have a permalink somewhere
>> <https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure>,
>> the way that Chrome does, stating that it's the intention of the team to
>> figure out a way to do this, somehow, someday.
>>
>>
>>>
>>> The main question is just "when".  This hasn't been a hugely high priority
>>> for us so far, since there's a lot of daylight between the 70% HTTP usage
>>> levels and a level where an insecure indication would be appropriate.  An
>>> insecure indication is good for moving from HTTP from "minority" downwards
>>> towards "very rare"; it's counter-productive to have a warning indicator
>>> that is active a significant percentage of the time.
>>>
>>> So the best focus for now is on better measuring HTTP/HTTPS usage,
>>> establishing some thresholds, and being prepared to turn things on when the
>>> time comes.
>>>
>>
>> That sounds totally right to me, and I think the Chrome team feels the same
>> way. There's an extent to which going out on a limb and having a public
>> declaration can help to self-fulfill that prophecy.
>>
>
> This is a completely flawed strategy in I would guess many minds
> especially those with a security background following what I call
> KISSIS (Keep it simple so it's securable). I realise web browsers don't
> follow this principle with Ted Unngst recently starting a project to
> replace/do JIT properly. I have no problem with saying http pages may
> not be secure but think the word insecure is misleading.


Any use of the word 'secure' or 'insecure' is misleading without a
business->threat->risk->security model approach.


> Expecting everyone to move to https is actually suggesting bad practice,
> not good practice. Your server is actually less secure with a larger
> attack footprint, and I said this before heartbleed. SSL uses more
> resources which added up across the world will be huge and simply a
> waste largely for no benefit (gpg and windows signing upgrades from
> sha1 are still needed for downloads etc. but only the keyserver needs
> ssl which some refuse annoyingly for false sense of security reasons
> anyway (CA)).

So, assuming a particular security need, does SSL provide it?  No,
probably not.  This is the fallacy of SSL as a security service -- it's
not a general purpose security blanket but it is heavily marketed by the
CAs and browser vendors as "all you need" and, if that is questioned,
it's marketed as "at least you must have this."


> Using ssl has been demonstrated to open up servers to 100x
> DOS amplification and so should not be used unless necessary. I always
> was an advocate of google searches being https if that shows balance
> however.


Right, there are issues.  And classically, SSL was designed to ignore
DOS because "we can't fix DOS so we won't consider it."

But none of this addresses what SSL can do and what it should do.  Now
we get closer to the crux.

If there is anything that SSL is supposed to do, and do above all else,
it is to tell you that you are talking to the site you wanted to be
talking to.  This turns out to be more important than even the
encryption, because there has been relatively little snooping going on.

In particular, we want to know that we are talking to our online
financial site.  So that we don't get tricked in a phishing MITM.  And
end up handing our credentials to a money scammer or end up on an
injection site that spear-phishes through us into our secure workplace.

SSL had one job to do, and that was tell us we are on a secure site and
that the site is our chosen site.

Now, through long experience and suffering, it turns out that this is
practically impossible to achieve *if the browser has to seamlessly
offer both unprotected and protected* at the same time.

    (Insert long discussion here about UX, user issues, K6, etc.)

Given that assumption, there is only one way forward:  everything has to
go HTTPS.

The fact that this breaks a lot of things and changes a lot of things,
and throws up a lot of unforeseen consequences doesn't change the fact
that in order for SSL to do that one job, it has to be SSL all the way,
all the time, everywhere.

Sucks, 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 marked insecure

Kevin Chadwick-2
On Thu, 05 Mar 2015 19:50:09 -0800
ianG wrote:

> The fact that this breaks a lot of things and changes a lot of things,
> and throws up a lot of unforeseen consequences doesn't change the fact
> that in order for SSL to do that one job, it has to be SSL all the way,
> all the time, everywhere.
>
> Sucks, right?

Sucks yeah but false, Gollum, Gollum.

Even if it were true technically, which I don't believe it is, (link
please, last time the link did not even remotely proove this at all)
you don't pin something with a sledgehammer.

p.s. The presentation requires js for navigation which goes against w3c
guidelines and doesn't work at all with xombrero in whitelist
mode possibly because the js is from another domain or for another
reason. I won't test further, there's little more in the presentation
than the first slide anyway.


p.p.s. EV was always a bad money making idea poorly executed security
wise. Even if I was running a billion pound organisation I would not
use it on principle despite lost revenue ( brand building ;-) ). So I'd
say get rid of green entirely as the user should be deciding by domain,
anything else should be additional assurance ONCE that is understood
(clicking).

White as ssl normal with tracking and ev info clickable. (after all
tracking largely shows how likely the organisation is to actually
secure your submission other than the password)

yellow as http password

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

Re: http marked insecure

Hubert Kario
On Monday 09 March 2015 08:32:16 Kevin Chadwick wrote:

> On Thu, 05 Mar 2015 19:50:09 -0800
>
> ianG wrote:
> > The fact that this breaks a lot of things and changes a lot of things,
> > and throws up a lot of unforeseen consequences doesn't change the fact
> > that in order for SSL to do that one job, it has to be SSL all the way,
> > all the time, everywhere.
> >
> > Sucks, right?
>
> Sucks yeah but false, Gollum, Gollum.

you didn't say why it's false...

and no, "making servers vulnerable to DoS amplification" is not a valid
argument. It's better to not provide communication than to provide insecure
communication *when secure is expected*.

> p.s. The presentation requires js for navigation which goes against w3c
> guidelines and doesn't work at all with xombrero in whitelist
> mode possibly because the js is from another domain or for another
> reason. I won't test further, there's little more in the presentation
> than the first slide anyway.

https://yourlogicalfallacyis.com/the-fallacy-fallacy

> p.p.s. EV was always a bad money making idea poorly executed security
> wise. Even if I was running a billion pound organisation I would not
> use it on principle despite lost revenue ( brand building ;-) ). So I'd
> say get rid of green entirely as the user should be deciding by domain,

EV makes OCSP mandatory, something not possible to do with regular
certificates

> anything else should be additional assurance ONCE that is understood
> (clicking).

server _administrators_ don't understand TLS, expecting users to understand it
is at best far fetched
--
Regards,
Hubert Kario
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: http marked insecure

Kevin Chadwick-2
On Mon, 09 Mar 2015 16:15:24 +0100
Hubert Kario wrote:

> > ianG wrote:  
> > > The fact that this breaks a lot of things and changes a lot of things,
> > > and throws up a lot of unforeseen consequences doesn't change the fact
> > > that in order for SSL to do that one job, it has to be SSL all the way,
> > > all the time, everywhere.
> > >
> > > Sucks, right?  
> >
> > Sucks yeah but false, Gollum, Gollum.  
>
> you didn't say why it's false...
>

If you mean sessions then I did here though some of it also applies
to stripping but also http2 may alleviate the sessions issue further
though I'm not convinced by http2 at all yet and certainly won't use it
until it's more mature... if I do decide to.

"http://permalink.gmane.org/gmane.comp.mozilla.security/6585&sa=U&ei=XMP-VN6NA-jk7AahiIHQCg&ved=0CBQQFjAA&usg=AFQjCNHE8d4JQ4wC1v4Z9JupRemtjO_PFg"

> and no, "making servers vulnerable to DoS amplification" is not a valid
> argument. It's better to not provide communication than to provide insecure
> communication *when secure is expected*.
>

It is, because secure transport does not mean you can trust that domain
so all you are doing is scaremongering for commercial gain or causing a
false sense of security whilst increasing the danger of downtime. I
don't believe in the security triangle and separate them out
but for those that do, DOS and so this plan is actually reducing
security and actually accessibility is what people care about most!

> > p.s. The presentation requires js for navigation which goes against w3c
> > guidelines and doesn't work at all with xombrero in whitelist
> > mode possibly because the js is from another domain or for another
> > reason. I won't test further, there's little more in the presentation
> > than the first slide anyway.  
>
> https://yourlogicalfallacyis.com/the-fallacy-fallacy
>
> > p.p.s. EV was always a bad money making idea poorly executed security
> > wise. Even if I was running a billion pound organisation I would not
> > use it on principle despite lost revenue ( brand building ;-) ). So I'd
> > say get rid of green entirely as the user should be deciding by domain,  
>
> EV makes OCSP mandatory, something not possible to do with regular
> certificates
>

OCSP is a bandaid. We need a solution and is there a valid reason why
it is tied to EV? or is just to actually give EV a use case as it has
been repeatedly criticised by many papers?

> > anything else should be additional assurance ONCE that is understood
> > (clicking).  
>
> server _administrators_ don't understand TLS, expecting users to understand it
> is at best far fetched

That is the falsest and one of the most disingenuous things I have
ever read. Do you have an agenda???

Understanding the intricacies of the various flavors of TLS has nothing
to do with anything. A user needs to decide if they trust a domain with
whatever they are sending in any case. *Nothing will change that*, the
only answer is education and pointers to nudge them and I see the
image from the presentation seems to have some improvements there
unless they were already made previously as I use firefox less these
days. Having a negative affect on the world such as scaring people with
insecure and pushing https everywhere should rightly be unacceptable to
the general population atleast.

Web of trust is one useful tool which may affect small players but
that's a negative that may be worth trading for the real benefit it
offers unlike https everywhere which offers nothing but bad practice.


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

Re: http marked insecure

Hubert Kario
On Tuesday 10 March 2015 09:39:33 Kevin Chadwick wrote:

> On Mon, 09 Mar 2015 16:15:24 +0100
>
> Hubert Kario wrote:
> > > ianG wrote:
> > > > The fact that this breaks a lot of things and changes a lot of things,
> > > > and throws up a lot of unforeseen consequences doesn't change the fact
> > > > that in order for SSL to do that one job, it has to be SSL all the
> > > > way,
> > > > all the time, everywhere.
> > > >
> > > > Sucks, right?
> > >
> > > Sucks yeah but false, Gollum, Gollum.
> >
> > you didn't say why it's false...
>
> If you mean sessions then I did here though some of it also applies
> to stripping but also http2 may alleviate the sessions issue further
> though I'm not convinced by http2 at all yet and certainly won't use it
> until it's more mature... if I do decide to.

without cryptographic protection you have no idea if the messages in transit
were modified, come from the same peer or were not read by third party in
transit, it doesn't matter how the session was established or is kept if I can
just hijack it

be it by taking over your TCP connection or by stealing your cookies, the
outcome is the same
 
> "http://permalink.gmane.org/gmane.comp.mozilla.security/6585&sa=U&ei=XMP-VN6
> NA-jk7AahiIHQCg&ved=0CBQQFjAA&usg=AFQjCNHE8d4JQ4wC1v4Z9JupRemtjO_PFg"

"No such message."

> > and no, "making servers vulnerable to DoS amplification" is not a valid
> > argument. It's better to not provide communication than to provide
> > insecure
> > communication *when secure is expected*.
>
> It is, because secure transport does not mean you can trust that domain
> so all you are doing is scaremongering for commercial gain or causing a
> false sense of security whilst increasing the danger of downtime. I
> don't believe in the security triangle and separate them out
> but for those that do, DOS and so this plan is actually reducing
> security and actually accessibility is what people care about most!

DoS is a Denial of Service, it doesn't expose data in transit or in rest!
Including sensitive data like cookies.

The proposal is to treat connections that use untrusted certificates (self
signed, so no CA involvement what-so-ever) as more secure than plaintext.
With stuff like TOFU/pinning (which Firefox already implements for untrusted
certs) it does make the connection more secure.

Where do you see commercial gain in that and for who?

> > > p.p.s. EV was always a bad money making idea poorly executed security
> > > wise. Even if I was running a billion pound organisation I would not
> > > use it on principle despite lost revenue ( brand building ;-) ). So I'd
> > > say get rid of green entirely as the user should be deciding by domain,
> >
> > EV makes OCSP mandatory, something not possible to do with regular
> > certificates
>
> OCSP is a bandaid. We need a solution and is there a valid reason why
> it is tied to EV?

so you don't know that CAs have refused to keep OCSP responders online for DV
and OV certificates after it was pointed out to then they are often offline or
very slow...

> or is just to actually give EV a use case as it has
> been repeatedly criticised by many papers?

I try to see things for what they are, both good and bad sides, and not
categorise them as fully bad or good just because one element of it is bad or
good.

mandatory OCSP for EV is a good thing, that makes EV certs better than regular
certs, even if the CA failed to do its job properly and in essence issued just
a DV cert
 
> > > anything else should be additional assurance ONCE that is understood
> > > (clicking).
> >
> > server _administrators_ don't understand TLS, expecting users to
> > understand it is at best far fetched
>
> That is the falsest and one of the most disingenuous things I have
> ever read.

18% of servers with valid certificates in Alexa top 1 million websites enable
completely insecure ciphersuites, like export grade, single DES or anonymous
key exchange

7% enable the completely insecure SSLv2, 35% still have enabled SSLv3 despite
POODLE

the internet scans after FREAK only show that the rest of the Internet
_is even worse_

and this is obvious stuff, issues that would be shown by running any kind of
vulnerability scanner against the server

yes, significant portion of server administrators don't understand TLS

> Do you have an agenda???

Yes, I have an agenda: make the Internet (web) more secure for everybody, make
eavesdropping hard.

> Understanding the intricacies of the various flavors of TLS has nothing
> to do with anything.

so attacks like FREAK are not the result of administrators wilful ignorance,
and insistence on enabling ciphersuites that aren't needed for
interoperability with clients for at least 10 years now

right

> A user needs to decide if they trust a domain with
> whatever they are sending in any case. *Nothing will change that*,

the average BigName™ website references at least 5 other servers/domainnames,
you honestly imagine that a user can make an informed decision whatever let
the browser connect to them? Have you *ever* used addon like Request Policy?

especially when "I just want to see cute kittens"

ha! good one

> the
> only answer is education and pointers to nudge them and I see the
> image from the presentation seems to have some improvements there
> unless they were already made previously as I use firefox less these
> days. Having a negative affect on the world such as scaring people with
> insecure and pushing https everywhere should rightly be unacceptable to
> the general population atleast.
>
> Web of trust is one useful tool which may affect small players but
> that's a negative that may be worth trading for the real benefit it
> offers unlike https everywhere which offers nothing but bad practice.

which is showed best by the stellar success of GPG and its rise during last 15
years to be the de-facto standard of email communication... no, something
doesn't sound right in this sentence, probably lacking comma somewhere
/sarcasm

HTTPS as a whole isn't perfect, far from it, but network effects make
deploying anything but "slightly changed HTTP", "slightly changed TLS" and
"slightly changed PKI/X.509" impossible in practice.

In general I can't see your arguments as anything else but throwing the baby
with the bathwater, sorry.
--
Regards,
Hubert Kario
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: http marked insecure

Kevin Chadwick-2
On Tue, 10 Mar 2015 13:18:49 +0100
Hubert Kario wrote:

> On Tuesday 10 March 2015 09:39:33 Kevin Chadwick wrote:
> > On Mon, 09 Mar 2015 16:15:24 +0100
> >
> > Hubert Kario wrote:
> > > > ianG wrote:

_________________________________________________________________________________

> > > > > The fact that this breaks a lot of things and changes a lot of things,
> > > > > and throws up a lot of unforeseen consequences doesn't change the fact
> > > > > that in order for SSL to do that one job, it has to be SSL all the                                     d   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > > > way,
> > > > > all the time, everywhere.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_________________________________________________________________________________

> > > > >
> > > > > Sucks, right?
> > > >
> > > > Sucks yeah but false, Gollum, Gollum.
> > >
> > > you didn't say why it's false...
> >
> > If you mean sessions then I did here though some of it also applies
> > to stripping but also http2 may alleviate the sessions issue further
> > though I'm not convinced by http2 at all yet and certainly won't use it
> > until it's more mature... if I do decide to.
>
> without cryptographic protection you have no idea if the messages in transit
> were modified, come from the same peer or were not read by third party in
> transit, it doesn't matter how the session was established or is kept if I can
> just hijack it
>
> be it by taking over your TCP connection or by stealing your cookies, the
> outcome is the same
>  


Nobody said anything about without cryptographic transport protection,
though I am sure you realise that almost every session involves
cryptography. A session/cookie can easily be tied to https only and
http still be correctly used where it isn't required.

> > "http://permalink.gmane.org/gmane.comp.mozilla.security/6585&sa=U&ei=XMP-VN6
> > NA-jk7AahiIHQCg&ved=0CBQQFjAA&usg=AFQjCNHE8d4JQ4wC1v4Z9JupRemtjO_PFg"
>
> "No such message."
>
> > > and no, "making servers vulnerable to DoS amplification" is not a valid
> > > argument. It's better to not provide communication than to provide
> > > insecure
> > > communication *when secure is expected*.
> >
> > It is, because secure transport does not mean you can trust that domain
> > so all you are doing is scaremongering for commercial gain or causing a
> > false sense of security whilst increasing the danger of downtime. I
> > don't believe in the security triangle and separate them out
> > but for those that do, DOS and so this plan is actually reducing
> > security and actually accessibility is what people care about most!
>
> DoS is a Denial of Service, it doesn't expose data in transit or in rest!
> Including sensitive data like cookies.
>
> The proposal is to treat connections that use untrusted certificates (self
> signed, so no CA involvement what-so-ever) as more secure than plaintext.
> With stuff like TOFU/pinning (which Firefox already implements for untrusted
> certs) it does make the connection more secure.
>


Potentially far more secure than EV and CA. What I was replying to was
the idea of using https for everything which is a bad idea.


> Where do you see commercial gain in that and for who?
>
> > > > p.p.s. EV was always a bad money making idea poorly executed security
> > > > wise. Even if I was running a billion pound organisation I would not
> > > > use it on principle despite lost revenue ( brand building ;-) ). So I'd
> > > > say get rid of green entirely as the user should be deciding by domain,
> > >
> > > EV makes OCSP mandatory, something not possible to do with regular
> > > certificates
> >
> > OCSP is a bandaid. We need a solution and is there a valid reason why
> > it is tied to EV?
>
> so you don't know that CAs have refused to keep OCSP responders online for DV
> and OV certificates after it was pointed out to then they are often offline or
> very slow...
>

I don't care, we need a proper CA less solution like DANE may be for
email. OCSP offers little assurance anyway. All it does offer is damage
limitation for accidental/discovered leakage and does nothing for
malicious/pay related leakage.

snipped as off discussion noise

>
> > A user needs to decide if they trust a domain with
> > whatever they are sending in any case. *Nothing will change that*,
>
> the average BigName™ website references at least 5 other servers/domainnames,
> you honestly imagine that a user can make an informed decision whatever let
> the browser connect to them? Have you *ever* used addon like Request Policy?
>
> especially when "I just want to see cute kittens"
>
> ha! good one

Yeah so if anything those domains should get orange and not green like
the proposal.

They often run javascript from about ten. This is a big problem and
actually if you are using tls then only one domain should be allowed at
once per page and javascript should be banned completely ideally but
not practically in all tabs during that time (I can hear the
backlash of screams calling foul already). That should be tackled but
ssl everywhere does nothing but help them hide their activity.

And actually css3/html5 means you shouldn't have an argument for
actually needing javascript over tls any more especially from any
third parties.

>
> > the
> > only answer is education and pointers to nudge them and I see the
> > image from the presentation seems to have some improvements there
> > unless they were already made previously as I use firefox less these
> > days. Having a negative affect on the world such as scaring people with
> > insecure and pushing https everywhere should rightly be unacceptable to
> > the general population atleast.
> >
> > Web of trust is one useful tool which may affect small players but
> > that's a negative that may be worth trading for the real benefit it
> > offers unlike https everywhere which offers nothing but bad practice.
>
> which is showed best by the stellar success of GPG and its rise during last 15
> years to be the de-facto standard of email communication... no, something
> doesn't sound right in this sentence, probably lacking comma somewhere
> /sarcasm

Actually it is probably best shown by antivirus tools and comodo
firewall etc. that inform users of how many have allowed this
communication or program without objection or known issues (mindshare).

paypa1.com would have a bad score. Again you miss the point or we seem
to be talking cross purposes. https everywhere and saying some things
are insecure and some have a green light when in fact it could be the
opposite way around in terms of trust is simply wrong.

A lot of this is off the point I was making which is that tls
everywhere brings problems and the idea that it solves any that can't
already be solved more correctly is false.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: http marked insecure

ianG-2
In reply to this post by Kevin Chadwick-2
On 10/03/2015 09:39 am, Kevin Chadwick wrote:
> On Mon, 09 Mar 2015 16:15:24 +0100
> Hubert Kario wrote:

>>> anything else should be additional assurance ONCE that is understood
>>> (clicking).
>>
>> server _administrators_ don't understand TLS, expecting users to understand it
>> is at best far fetched
>
> That is the falsest and one of the most disingenuous things I have
> ever read. Do you have an agenda???


What's false about it?

Just my personal impression:  Of the server admins I've known,
approximately none of them understand TLS, and they only barely
understand configuration of https.  They all copy config scripts from
some place and move on when the pages are being served.  None of them
perceive any difference between absence of security and presence of
pages, so leaving in ephemeral ADH suites and null suites is ... fine!

Hopefully where they copied the configs from is better equipped.  While
we're on the topic, there is a good guide here (written by sysadms who
do understand TLS to some extent):

https://bettercrypto.org/

Honestly, it isn't their fault.  I would much rather TLS was reduced to
one suite & one mode than 'sell' the BetterCrypto group's fine work.  So
much effort wasted by society because the IETF committee of 'experts'
has this fantasy "replacement" dream...


> Understanding the intricacies of the various flavors of TLS has nothing
> to do with anything. A user needs to decide if they trust a domain with
> whatever they are sending in any case. *Nothing will change that*,


True, but an excuse nonetheless.  Blaming the victim for not doing their
mandated job does not excuse the infrastructure from making the job
impossible to do.


> the
> only answer is education

10 years ago, I wrote "User Education: worse than useless" :)

http://www.financialcryptography.com/mt/archives/000279.html


> and pointers to nudge them and I see the
> image from the presentation seems to have some improvements there
> unless they were already made previously as I use firefox less these
> days. Having a negative affect on the world such as scaring people with
> insecure and pushing https everywhere should rightly be unacceptable to
> the general population atleast.


I'm fine with that.  I think the choice is simple:  switch off HTTP or
switch off HTTPS.  Either will free up the future to be more secure.


> Web of trust is one useful tool which may affect small players but
> that's a negative that may be worth trading for the real benefit it
> offers unlike https everywhere which offers nothing but bad practice.


Web of Trust is certainly part of a high security system.  However not
as written about / deployed.  It needs a serious upgrade to do something
properly for the members.

And yes I agree that HTTPS is ever likely to be upgraded to be secure to
that level.  Browsing will only ever be medium security because of the
architectural decisions they so love and cherish.  But at least it could
be resilient to basic identity attacks.



iang

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

Re: http marked insecure

Julien Vehent-2
On Tue 10.Mar'15 at 16:19:22 +0000, ianG wrote:
> Just my personal impression:  Of the server admins I've known, approximately
> none of them understand TLS, and they only barely understand configuration
> of https.  They all copy config scripts from some place and move on when the
> pages are being served.  None of them perceive any difference between
> absence of security and presence of pages, so leaving in ephemeral ADH
> suites and null suites is ... fine!

"None" is an overstatement. While it is true that the topic of configuring
SSL/TLS is complex, most administrators understand the basics of ciphers
security and are perfectly capable of building strong configurations.

https://wiki.mozilla.org/Security/Server_Side_TLS was written in close
collaboration with administrators and cryptographers, both providing
equally valuable feedback.

I don't know the background of the people who wrote bettercrypto.org,
but they refusal to integrate backward compatibility requirements (we
actually do need sslv3 in a number of places) indicates to me a
disconnect with the reality of operatings large profile websites.

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

Re: http marked insecure

Hubert Kario
In reply to this post by Kevin Chadwick-2
On Tuesday 10 March 2015 13:51:00 Kevin Chadwick wrote:

> On Tue, 10 Mar 2015 13:18:49 +0100
>
> Hubert Kario wrote:
> > On Tuesday 10 March 2015 09:39:33 Kevin Chadwick wrote:
> > > On Mon, 09 Mar 2015 16:15:24 +0100
> > >
> > > Hubert Kario wrote:
> > > > > ianG wrote:
> ____________________________________________________________________________
> _____
> > > > > > The fact that this breaks a lot of things and changes a lot of
> > > > > > things,
> > > > > > and throws up a lot of unforeseen consequences doesn't change the
> > > > > > fact
> > > > > > that in order for SSL to do that one job, it has to be SSL all the
> > > > > >                                     d  
> > > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ way,
> > > > > > all the time, everywhere.
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ____________________________________________________________________________
> _____
> > > > > > Sucks, right?
> > > > >
> > > > > Sucks yeah but false, Gollum, Gollum.
> > > >
> > > > you didn't say why it's false...
> > >
> > > If you mean sessions then I did here though some of it also applies
> > > to stripping but also http2 may alleviate the sessions issue further
> > > though I'm not convinced by http2 at all yet and certainly won't use it
> > > until it's more mature... if I do decide to.
> >
> > without cryptographic protection you have no idea if the messages in
> > transit were modified, come from the same peer or were not read by third
> > party in transit, it doesn't matter how the session was established or is
> > kept if I can just hijack it
> >
> > be it by taking over your TCP connection or by stealing your cookies, the
> > outcome is the same
>
> Nobody said anything about without cryptographic transport protection,

I already said, HTTPS using X.509 and TLS is only thing that can work because
of network effects. We can add stuff on top of it to make it secure against
certain kinds of attacks, but at the end of the day it will have to downgrade
gracefully to clients that don't support the additions.

And it will have to do that during the whole transitionally period -
realistically 10 years.

> though I am sure you realise that almost every session involves
> cryptography. A session/cookie can easily be tied to https only and
> http still be correctly used where it isn't required.

HTTPS is the only solution we have that will allow you to have even moderately
strong guarantee that the server you connected to yesterday is the same one
you connected today (or operated by same people).

When you're reading market quotes you want that to be served over HTTPS, when
you're reading about antics of the new starlet you don't care.
Problem is, the browser _has no way to know_ which is which.

HTTPS all the time, everywhere, is the only solution that has even a slight
chance of providing security where people expect it.

Yes, that unfortunately means "cute kittens over HTTPS". That also means
"reused passwords to log in to cute kittens website" are transferred over
HTTPS.
--
Regards,
Hubert Kario
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: http marked insecure

Kevin Chadwick-2
On Wed, 11 Mar 2015 13:56:53 +0100
Hubert Kario wrote:

> HTTPS all the time, everywhere, is the only solution that has even a slight
> chance of providing security where people expect it.
>

False, you have gone too far.

> Yes, that unfortunately means "cute kittens over HTTPS". That also means
> "reused passwords to log in to cute kittens website" are transferred over
> HTTPS.

I have pointed out what can prevent the attacks mentioned so far and
that people need to check https is enabled and most importantly to a
correct domain whenever they submit anything sensitive. Nothing can
change that and to believe that you can rather than dealing with that
problem perhaps through the browser educating them, is dangerous.
Automated cookie sending can and always should be tied to https only
for that domain already. So I repeat all that ssl everywhere achieves
is a higher potential for downtime and security breaches. Perhaps it
allows existing "big sites" to continue behaving badly, is that your
point?

Repeating yourself without addressing what I have said is just like the
program about the big bang I half watched last night. The opening
sentence was pointless and all the rest was pointless conjecture made
into a pantomime about the origin of the universe when what they
actually meant was the origin of the known universe (new term being
multiverse to make it fit the box, how rediculous).
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: http marked insecure

Hubert Kario
On Wednesday 11 March 2015 14:23:11 Kevin Chadwick wrote:
> Automated cookie sending can and always should be tied to https only
> for that domain already.

Thing is we can't turn off sending cookies over http without breaking the web.
Similarly, we can't turn off transition of https cookies without secure flag
to http without breaking the web.

> So I repeat all that ssl everywhere achieves
> is a higher potential for downtime and security breaches.

HTTP *is* a security breach in and out of itself if it sends anything remotely
useful. And that happens far more often than bugs in TLS libraries, and is far
far easier to exploit, to the point that there are ready to use browser addons
that do that.

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

Re: http marked insecure

Kevin Chadwick-2
On Wed, 11 Mar 2015 20:35:51 +0100
Hubert Kario wrote:

> On Wednesday 11 March 2015 14:23:11 Kevin Chadwick wrote:
> > Automated cookie sending can and always should be tied to https only
> > for that domain already.  
>
> Thing is we can't turn off sending cookies over http without breaking the web.

That's not necessary, though I don't see any need for http cookies
personally (web logs are more accurate than google analytics for
example and that's probably secure flagged anyway).

> Similarly, we can't turn off transition of https cookies without secure flag
> to http without breaking the web.
>

So, If they aren't secure flagged then they shouldn't matter?

It seems you are trying to wipe web admins arses that don't use the
secure flag properly. Wiping peoples arses has caused many problems in
the past. Make it easier if it isn't already but please don't encourage
everyone to use an inferior web with ssl everywhere (far more severe
breakage potential).

> > So I repeat all that ssl everywhere achieves
> > is a higher potential for downtime and security breaches.  
>
> HTTP *is* a security breach in and out of itself if it sends anything remotely
> useful.

That's not true, an argument could easily be made that the *most*
important content is sent over http like sharing publicly available
information. I don't rate facebook/google+ as that important myself?
Online banking is important but information sharing probably still
trumps it.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: http marked insecure

Hubert Kario
On Wednesday 11 March 2015 20:21:23 Kevin Chadwick wrote:

> On Wed, 11 Mar 2015 20:35:51 +0100
>
> Hubert Kario wrote:
> > On Wednesday 11 March 2015 14:23:11 Kevin Chadwick wrote:
> > > Automated cookie sending can and always should be tied to https only
> > > for that domain already.
> >
> > Thing is we can't turn off sending cookies over http without breaking the
> > web.
>
> That's not necessary, though I don't see any need for http cookies
> personally

I'm at a loss for words.

But if you go from this, no wonder that you are against HTTPS everywhere...
 

> > Similarly, we can't turn off transition of https cookies without secure
> > flag to http without breaking the web.
>
> So, If they aren't secure flagged then they shouldn't matter?
>
> It seems you are trying to wipe web admins arses that don't use the
> secure flag properly. Wiping peoples arses has caused many problems in
> the past. Make it easier if it isn't already but please don't encourage
> everyone to use an inferior web with ssl everywhere (far more severe
> breakage potential).

Yes, breaking stuff like logon over HTTPS and then redirect with a regular
cookie to HTTP is one of the goals. Developers should know better, but they
don't. We tried to educate them, it didn't work. Yes, it is "wiping arses" and
it will be ugly, but the status quo is even worse.

Breakage is visible so it gets noticed and gets fixed. Security issues like
not setting "secure" flag on authentication cookies or saving passwords in the
clear don't get noticed because stuff continues to work.

I also really don't see how SSL web is inferior. In my personal experience it
is more robust and _faster_ because there are no middleboxes meddling with the
connection, see for yourself: http://www.httpvshttps.com/
 
> > > So I repeat all that ssl everywhere achieves
> > > is a higher potential for downtime and security breaches.
> >
> > HTTP *is* a security breach in and out of itself if it sends anything
> > remotely useful.
>
> That's not true, an argument could easily be made that the *most*
> important content is sent over http like sharing publicly available
> information.

even if it is publicly available, I still want to know who is the source of
it, call me lazy, but I don't cross verify every minutiae of news
--
Regards,
Hubert Kario
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
12