Proposal: Marking HTTP As Non-Secure

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

Re: Proposal: Marking HTTP As Non-Secure

Chris Palmer
On Sun, Dec 14, 2014 at 10:34 AM, Igor Bukanov <[hidden email]> wrote:

If serving context over HTTPS generates broken pages, the insensitive of
> enabling encryption is very low.
>

That's the definition of a collective action problem, yes.

I think that the incentives will change, and are changing, and people are
becoming more aware of the problems of non-secure transport. There is an
on-going culture shift, and more and more publishers are going to offer
HTTPS. For example,
http://open.blogs.nytimes.com/author/eitan-konigsburg/?_r=0.

As it was already mentioned, a solution to that is to allow to serve
> encrypted pages over HTTP so pages that refer to unencrypted elements would
> not break pages but just produces warnings. Such encrypted http:// also
> allows to generate less warnings for a page where all context is available
> over self-signed and key-pinned certificate as that solution is strictly
> more secure then a plain HTTP.
>

But, again, consider the definition of the origin. If it is possible for
securely-transported code to run in the same context as non-securely
transported code, the securely-transported code is effectively non-secure.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Chris Palmer
In reply to this post by Michael Ströder
On Sun, Dec 14, 2014 at 10:37 AM, Michael Ströder <[hidden email]>
wrote:

I just wanted to point out that a large amount of domains will be affected
> (marked as non-secure) where the domain owner cannot quickly do anything
> about it.
>

That's why we propose a gradual transition, and why we and Richard Barnes
of Mozilla prefer to predicate the transition on increased deployment of
HTTPS.


> But migrating domains from one hosting provider to another can be complex.
> Not
> something people do within a day as a side job.


Yes, I suspect that most people who are about to migrate from HTTP to HTTPS
are the people who have that as their main job (as e.g.
http://open.blogs.nytimes.com/2014/11/13/embracing-https/).

The long tail will come later, and most likely they won't migrate; instead,
their hosting providers will do it for them as a service. That is as it
should be.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Michael Ströder
In reply to this post by Chris Palmer
Chris Palmer wrote:
> Reducing the number of parties you have to trust from [ the site operator,
> the operators of all networks between you and the site operator ] to just [
> the site operator ] is a huge win.

Yes, I agree. But to really guarantee this you would have to block all the
shiny SSL facade reverse proxy services out there. ;-)

I suspect your approach will rather make people rush into using such central
SSL fake services and data is transmitted in clear behind the service. If this
happens those services will be an even more attractive interception point.

Ciao, Michael.

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

Re: Proposal: Marking HTTP As Non-Secure

Igor Bukanov-2
In reply to this post by Chris Palmer
On 14 December 2014 at 19:40, Chris Palmer <[hidden email]> wrote:

>
> But, again, consider the definition of the origin. If it is possible for
> securely-transported code to run in the same context as non-securely
> transported code, the securely-transported code is effectively non-secure.
>

Yes, but the point is that the page will be shown with the same warnings as
a plain http page rather then showing a broken page.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Michael Ströder
In reply to this post by Igor Bukanov-2
Chris Palmer wrote:
> HTTPS. For example,
> http://open.blogs.nytimes.com/author/eitan-konigsburg/?_r=0.

It does not make sense linking to NYT articles which are behind a paywall.
Or did you want to show us that the paywall login page is HTTPS? ;-)

Ciao, Michael.

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

Re: Proposal: Marking HTTP As Non-Secure

Igor Bukanov-2
In reply to this post by Igor Bukanov-2
I.e. just consider that currently a hosting provider has no option to
unconditionally encrypt pages they host for modern browsers as that may
break pages of the users. With encrypted http:// they get such option
delegating the job of fixing warnings about insecure context to the content
producers as it should.

On 14 December 2014 at 19:48, Igor Bukanov <[hidden email]> wrote:

>
> On 14 December 2014 at 19:40, Chris Palmer <[hidden email]> wrote:
>
>>
>> But, again, consider the definition of the origin. If it is possible for
>> securely-transported code to run in the same context as non-securely
>> transported code, the securely-transported code is effectively non-secure.
>>
>
> Yes, but the point is that the page will be shown with the same warnings
> as a plain http page rather then showing a broken page.
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Chris Palmer
In reply to this post by Michael Ströder
On Sun, Dec 14, 2014 at 10:52 AM, Michael Ströder <[hidden email]>
wrote:

> http://open.blogs.nytimes.com/author/eitan-konigsburg/?_r=0.
>
> It does not make sense linking to NYT articles which are behind a paywall.
> Or did you want to show us that the paywall login page is HTTPS? ;-)
> <https://lists.mozilla.org/listinfo/dev-security>
>

I can get to that page without a paywall. Maybe they distinguish based on
client IP (non-US?)? Or maybe you have read you "10 free articles this
month"? :)

But anyway, it's an article about how they challenge news services to go to
HTTPS, presumably including themselves.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Chris Palmer
In reply to this post by Michael Ströder
On Sun, Dec 14, 2014 at 10:47 AM, Michael Ströder <[hidden email]>
wrote:

Chris Palmer wrote:
> > Reducing the number of parties you have to trust from [ the site
> operator,
> > the operators of all networks between you and the site operator ] to
> just [
> > the site operator ] is a huge win.
>
> Yes, I agree. But to really guarantee this you would have to block all the
> shiny SSL facade reverse proxy services out there. ;-)
>

That edges up to the remote attestation problem (which is unsolvable). We
just want the browser to tell the truth about what it can determine.

If the site operator chooses to deploy in a not perfectly safe manner, that
is a separate problem that the community will have to solve by other means.


> I suspect your approach will rather make people rush into using such
> central
> SSL fake services and data is transmitted in clear behind the service. If
> this
> happens those services will be an even more attractive interception point.
> <https://lists.mozilla.org/listinfo/dev-security>
>

We will have to try to deal with that somehow (most likely at "layer 8").
But, are you saying that, for this reason, the status quo is somehow
acceptable or even preferable?
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Chris Palmer
In reply to this post by Igor Bukanov-2
On Sun, Dec 14, 2014 at 10:53 AM, Igor Bukanov <[hidden email]> wrote:

I.e. just consider that currently a hosting provider has no option to
> unconditionally encrypt pages they host for modern browsers as that may
> break pages of the users. With encrypted http:// they get such option
> delegating the job of fixing warnings about insecure context to the content
> producers as it should.
>

I'm sorry; I still don't understand what you mean. Do you mean that you
want browsers to treat some hypothetical encrypted HTTP protocol as if it
were a secure origin, but still allow non-secure embedded content in these
origins?

I would argue strongly against that, and so far not even the "opportunistic
encryption" advocates have argued for that.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Igor Bukanov-2
I would like to see some hypothetical encrypted http:// when a browser
present a page as if it was over https:// if everything of a secure origin
and as if it was served over plain http if not. That is, if a future
browser shows warnings for plain http, so it will show the same warnings
for encrypted http:// with insecure resources.

The point of such encrypted http:// is to guarantee that *enabling
encryption never degrades user experience* compared with the case of plain
http. This will allow for a particular installation to start serving
everything encrypted independently from the job of fixing the content. And
as the page still served as http://, the user training/expectations about
https:// sites no longer applies.

On 14 December 2014 at 20:08, Chris Palmer <[hidden email]> wrote:

>
> On Sun, Dec 14, 2014 at 10:53 AM, Igor Bukanov <[hidden email]> wrote:
>
> I.e. just consider that currently a hosting provider has no option to
>> unconditionally encrypt pages they host for modern browsers as that may
>> break pages of the users. With encrypted http:// they get such option
>> delegating the job of fixing warnings about insecure context to the content
>> producers as it should.
>>
>
> I'm sorry; I still don't understand what you mean. Do you mean that you
> want browsers to treat some hypothetical encrypted HTTP protocol as if it
> were a secure origin, but still allow non-secure embedded content in these
> origins?
>
> I would argue strongly against that, and so far not even the
> "opportunistic encryption" advocates have argued for that.
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Michael Ströder
In reply to this post by Michael Ströder
Chris Palmer wrote:

> On Sun, Dec 14, 2014 at 10:47 AM, Michael Ströder <[hidden email]>
> wrote:
>
> Chris Palmer wrote:
>>> Reducing the number of parties you have to trust from [ the site
>> operator,
>>> the operators of all networks between you and the site operator ] to
>> just [
>>> the site operator ] is a huge win.
>>
>> Yes, I agree. But to really guarantee this you would have to block all the
>> shiny SSL facade reverse proxy services out there. ;-)
>
> That edges up to the remote attestation problem (which is unsolvable). We
> just want the browser to tell the truth about what it can determine.

Telling/attesting something to the browser is meaningless.
You have to tell the user something.
And the user often has a false understanding of technical issues.

> If the site operator chooses to deploy in a not perfectly safe manner, that
> is a separate problem that the community will have to solve by other means.
>
>> I suspect your approach will rather make people rush into using such
>> central
>> SSL fake services and data is transmitted in clear behind the service. If
>> this
>> happens those services will be an even more attractive interception point.
>> <https://lists.mozilla.org/listinfo/dev-security>
>
> We will have to try to deal with that somehow (most likely at "layer 8").
> But, are you saying that, for this reason, the status quo is somehow
> acceptable or even preferable?

During the last years I saw many so-called security mechanisms pushing things
into the wrong direction.

In this case:
Wiretapping is easier if traffic is going through only a few channels. If you
force everybody to speak HTTPS you might endorse leveraging central SSL
reverse proxies leading to even easier traffic interception.
This is probably not what you want.

All in all:
I'm not against this approach in general. But it might push things into the
wrong direction and never reach its good intention.

Ciao, Michael.

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

Re: Proposal: Marking HTTP As Non-Secure

Igor Bukanov-2
On 14 December 2014 at 20:32, Michael Ströder <[hidden email]> wrote:

> if you
> force everybody to speak HTTPS you might endorse leveraging central SSL
> reverse proxies leading to even easier traffic interception.
>

Indeed. In a https-only world ISP may just require for the user to install
their certificate. Still it will be better than the current situation when
it is very cheap to sniff on a neighbor cable-modem link or with a fake GSM
node and revert the situation to the one that was several years ago when
sniffing was realistically possible only on the level of ISP.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Michal Zalewski-2
In reply to this post by Igor Bukanov-2
> I would like to see some hypothetical encrypted http:// when a browser
> present a page as if it was over https:// if everything of a secure origin
> and as if it was served over plain http if not. That is, if a future browser
> shows warnings for plain http, so it will show the same warnings for
> encrypted http:// with insecure resources.

Browsers have flirted with along the lines of your proposal with
non-blocking mixed content icons. Unfortunately, websites are not
static - so the net effect was that if you watched the address bar
constantly, you'd eventually get notified that your previously-entered
data that you thought will be visible only to a "secure" origin has
been already leaked to / exposed to network attackers.

The main point of having a visible and stable indicator for encrypted
sites is to communicate to the user that the site offers a good degree
of resilience against the examination or modification of the exchanged
data by network attackers. (It is a complicated property and it is
often misunderstood as providing clear-cut privacy assurances for your
online habits, but that's a separate topic.)

Any changes that make this indicator disappear randomly at unexpected
times, or make the already-complicated assurances more fragile and
even harder to explain, are probably not the right way to go.

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

Re: Proposal: Marking HTTP As Non-Secure

Igor Bukanov-2
On 14 December 2014 at 20:47, Michal Zalewski <[hidden email]> wrote:

> The main point of having a visible and stable indicator for encrypted
> sites is to communicate to the user that the site offers a good degree
> of resilience against the examination or modification of the exchanged
> data by network attackers.
>

Then browser should show absolutely no indications of secure origin for
encrypted http://. The idea is that encrypted http:// experience would be
equivalent to the current http experience with no indications of security
and no warnings. However, encrypted http:// with insecure elements will
start to produce warnings in the same way a future browser will show
warnings for plain http.

Without something like this I just do not see how a lot of sites could ever
start enabling encryption unconditionally. I.e. currently enabling https
requires to modify content often in a significant way. I would for a site
operator to have an option to enabling encryption unconditionally without
touching the content.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Michal Zalewski-2
> Then browser should show absolutely no indications of secure origin for
> encrypted http://. The idea is that encrypted http:// experience would be
> equivalent to the current http experience with no indications of security
> and no warnings. However, encrypted http:// with insecure elements will
> start to produce warnings in the same way a future browser will show
> warnings for plain http.

As mentioned in my previous response, this gets *really* hairy because
the "has insecure elements" part is not a static property that can be
determined up front; so, you end up with the problem of sudden and
unexpected downgrades and notifying the user only after the
confidentiality or integrity of the previously-stored data has been
compromised.

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

Re: Proposal: Marking HTTP As Non-Secure

Christian Heutger
In reply to this post by Chris Palmer
> Reducing the number of parties you have to trust from [ the site operator, the operators of all networks between you and the site operator ] to just [ the site operator ] is a huge win.

But how can I trust him and who is he? No WHOIS records no imprint, all spoofable, so in what should I trust then? If there is a third-party, who state me, the details given are correct and they have a warranty for misinformation, that’s something I could trust. I also look at online-shopping if there are customer reviews, but I do not recognize them as fully trustable as they may be spoofed, if the shop has a seal like Trusted Shops with a money-back guarantee, I feel good and shop there.

> I think you'll find EV is not as "extended" as you might be hoping.

I know, but it’s the best we currently have. And DV is much worser, finally loosing any trust in HTTPS with it, scaling it down to encryption, nothing else.

> But more importantly, the only way to get minimal server auth, data integrity, and data confidentiality on a mass scale is with something at least as easy to deploy as DV. Indeed, you'll see many of the other messages in this thread are from people concerned that DV isn’t
> easy enough yet! So requiring EV is a non-starter.

I agree on data confidentiality, maybe also on integrity although DV without effort or costs may break that also in any way, but server auth is somehow saying nothing as any server endpoint I called I get, nothing more is authenticated. However, I support the idea of having mass encryption, but before confusing and damaging end users mind on internet security, there need to be a clear differentiation in just encryption and encryption with valid authentication.

> HTTPS is the bare minimum requirement for secure web application *transport*. Is secure transport by itself sufficient to achieve total *application-semantic* security? No. But a browser couldn't determine that level of security anyway. Our goal is for the browser to tell
> as much of the truth as it can programatically determine at run-time.

But wasn’t that the idea of certificates? Seals on websites can be spoofed, WHOIS records can be spoofed, imprints can be spoofed, but spoofing EV certificates, e.g. in combination with solutions like pinning, is a hard job. Considering there would be no browser warning for self-signed certificates, I do not see any advantage in mass developed (finally requiring a full automated process) DV certificates. It’s a bit back to the roots to times, I remember, some website operators offered their self-signed root to be installed in the browser to remove the browser warning.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Peter Bowen
In reply to this post by Chris Palmer
On Sun, Dec 14, 2014 at 11:08 AM, 'Chris Palmer' via Security-dev
<[hidden email]> wrote:

> On Sun, Dec 14, 2014 at 10:53 AM, Igor Bukanov <[hidden email]> wrote:
>
>> I.e. just consider that currently a hosting provider has no option to
>> unconditionally encrypt pages they host for modern browsers as that may
>> break pages of the users. With encrypted http:// they get such option
>> delegating the job of fixing warnings about insecure context to the content
>> producers as it should.
>
>
> I'm sorry; I still don't understand what you mean. Do you mean that you want
> browsers to treat some hypothetical encrypted HTTP protocol as if it were a
> secure origin, but still allow non-secure embedded content in these origins?

I'm also not clear on what Igor intended, but there is a real issue
with browser presentation of URLs using TLS today.  There is no way to
declare "I know that this page will have insecure content, so don't
consider me a secure origin" such that the browser will show a
"neutral" icon rather than a warning icon.  I think there is a strong
impression that a closed lock is better than neutral, but a yellow
warning sign over the lock is worse than neutral.  Today prevents
sites from using HTTPS unless they have a very high confidence that
all resources on the page will come from secure origins.

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

Re: Proposal: Marking HTTP As Non-Secure

chaals
In reply to this post by Chris Palmer
(Ouch. maintaining the cross-posting ;( ).
 
15.12.2014, 11:57, "Christian Heutger" <[hidden email]>:
However, this „change“ could come with marking HTTP as Non-Secure, but just stating HTTPS as secure is the completely wrong sign and will result in more confusion and loosing any trust in any kind of browser padlocks than before.
 
The message someone wrote about "I understand I am using insecure mixed content, please don't make me look worse than someone who doesn't understand that" strikes a chord - I think there is value in supporting the use case.
 
Just a proposal:
 
Mark HTTP as Non-Secure (similar to self-signed) e.g. with a red padlock or sth. similar.
Mark HTTPS as Secure (and only secure in favor of encrypted) e.g. with a yellow padlock or sth. similar
Mark HTTPS with Extended Validation (encrypted and validated) as it is with a green padlock or sth. similar
 
Just a "nit pick" - please don't EVER rely only on colour distinction to communicate anything important. There are a lot of colour-blind people, and on top there are various people who rely on high-contrast modes and the like which effectively strip the colour out.
 
cheers
 
Chaals
 
--
Charles McCathie Nevile - web standards - CTO Office, Yandex
[hidden email] - - - Find more at http://yandex.com
 

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

Re: Proposal: Marking HTTP As Non-Secure

Igor Bukanov-2
In reply to this post by Peter Bowen
On 14 December 2014 at 23:57, Peter Bowen <[hidden email]> wrote:

>  I think there is a strong
> impression that a closed lock is better than neutral, but a yellow
> warning sign over the lock is worse than neutral.
>

The problem is not just a warning sign.

Browsers prevents any active context including iframe served over http from
loading. Thus showing a page with youtube and other videos over https is
not an option unless one fixes the page. Now consider that it is not a
matter of running sed on a set of static files but rather patching the
stuff stored in the database or fixing JS code that inserts the video as
the task of enabling https becomes non-trivial and very content dependent.

So indeed an option to declare that despite proper certificates and
encryption the site should be treated as of insecure origin is needed. This
way the page will be shown as if it was served as before with plain http
with no changes in user experience.  But then it cannot be a https site
since many users still consider that https is enough to assume a secure
site. Hence the idea of encrypted http:// or something that makes user
experience with an encrypted page absolutely the same as she has with plain
http:// down to the browser stripping http:// from the URL.

After considering this I think it will be even fine for a future browser to
show a warning for such
properly-encrypted-but-explicitly-declared-as-insecure in the same way as a
warning will be shown for plain http. And it will be really nice if a site
operator, after activating such user-invisible encryption, can receive
reports from a browser about any violation of the secure origin policy in
the same way how violations of CSP are reported today. This would give nice
possibility of activating encryption without breaking anything, collecting
reports of violated secure origin policy, fixing content and finally
declaring the site explicitly https-only.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Marking HTTP As Non-Secure

Michal Zalewski-2
> So indeed an option to declare that despite proper certificates and
> encryption the site should be treated as of insecure origin is needed. This
> way the page will be shown as if it was served as before with plain http
> with no changes in user experience.  But then it cannot be a https site
> since many users still consider that https is enough to assume a secure
> site. Hence the idea of encrypted http:// or something that makes user
> experience with an encrypted page absolutely the same as she has with plain
> http:// down to the browser stripping http:// from the URL.

Sounds like you're essentially proposing a flavor of opportunistic
encryption for http://, right?

That seems somewhat tangential to Chris' original proposal, and there
is probably a healthy debate to be had about this; it may be also
worthwhile to look at SPDY and QUIC. In general, if you're comfortable
with not providing users with a visible / verifiable degree of
transport security, I'm not sure how the proposal changes this?

By the way, note that nothing is as simple as it seems; opportunistic
encryption is easy to suggest, but it's pretty damn hard to iron out
all the kinks. If there is genuinely no distinction between plain old
HTTP and opportunistically encrypted HTTP, the scheme can be
immediately rendered useless by any active attacker, and suffers from
many other flaws (for example, how do you link from within that
opportunistic scheme to other URLs within your application without
downgrading to http:// or upgrading to "real" https://?). Establishing
a new scheme solves that, but doesn't really address your other
concern - you still need to clean up all links. On top of that, it
opens a whole new can of worms by messing around with SOP.

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