Proposal: Marking HTTP As Non-Secure

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

Re: Proposal: Marking HTTP As Non-Secure

Jeffrey Walton
On Sat, Dec 13, 2014 at 2:05 PM, Christian Heutger
<[hidden email]> wrote:
> I see a big danger in the current trend.

Surely you haven't missed the big danger in plain text traffic. That
traffic gets usuroed and fed into susyems like Xkeyscore for Tailored
Access Operations (TAO). In layman's terms, adversaries are using the
information gathered to gain unauthorized access to systems.

> Expecting everyone having a free
> „secure“ certificate and being in requirement to enable HTTPS it will result
> in nothing won. DV certificates (similar to DANE) do finally say absolute
> nothing about the website operator.

The race to the bottom among CAs is to blame for the quality of
verification by the CAs.

With companies like StartCom, Cacert and Mozilla offering free
certificates, there is no barrier to entry.

Plus, I don't think a certificate needs to say anything about the
operator. They need to ensure the server is authenticated. That is,
the public key bound to the DNS name is authentic.

> They ensure encryption, so I can then be
> phished, be scammed, … encrypted. Big advantage!^^

As I understand it, phishers try to avoid TLS because they count on
the plain text channel to avoid all the browser warnings. Peter
Gutmann discusses this in his Engineering Security book
(https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf).

> Pushing real validation
> (e.g. EV with green adressbar and validated details by an independent third
> party, no breakable, spoofable automatism) vs. no validation is much more
> important and should be focussed on.

You should probably read Gutmann's Engineering Security. See his
discussion of "PKI me harder" in Chapter 1 or 6 (IIRC).

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

Security engineering studies seem to indicate most users don't
understand the icons. It would probably be better if the browsers did
the right thing, and took the users out of the loop. Gutmann talks
about it in detail (with lots of citations).

> Just a proposal:
>
> Mark HTTP as Non-Secure (similar to self-signed) e.g. with a red padlock or
> sth. similar.

+1. In the browser world, plaintext was (still is?) held in higher
esteem then opportunistic encryption. Why the browsers choose to
indicate things this way is a mystery.

> 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

Why green for EV (or why yellow for DV or DANE)? EV does not add any
technical controls. From a security standpoint, DV and EV are
equivalent.

If DNS is authentic, then DANE provides stronger assurances than DV or
EV since the domain operator published the information and the
veracity does not rely on others like CAs (modulo DBOUND).

Not relying on a CA is a good thing since its usually advantageous to
minimize trust (for some definition of "trust"). Plus, CAs don't
really warrant anything, so its not clear what exactly they are
providing to relying parties (they are providing a a signature for
money to the applicant).

Open question: do you think the browsers will support a model other
than the CA Zoo for rooting trust?
_______________________________________________
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

Ryan Sleevi-2
On Dec 15, 2014 1:29 AM, "Jeffrey Walton" <[hidden email]> wrote:

>
> On Sat, Dec 13, 2014 at 2:05 PM, Christian Heutger
> <[hidden email]> wrote:
> > I see a big danger in the current trend.
>
> Surely you haven't missed the big danger in plain text traffic. That
> traffic gets usuroed and fed into susyems like Xkeyscore for Tailored
> Access Operations (TAO). In layman's terms, adversaries are using the
> information gathered to gain unauthorized access to systems.
>
> > Expecting everyone having a free
> > „secure“ certificate and being in requirement to enable HTTPS it will
result
> > in nothing won. DV certificates (similar to DANE) do finally say
absolute

> > nothing about the website operator.
>
> The race to the bottom among CAs is to blame for the quality of
> verification by the CAs.
>
> With companies like StartCom, Cacert and Mozilla offering free
> certificates, there is no barrier to entry.
>
> Plus, I don't think a certificate needs to say anything about the
> operator. They need to ensure the server is authenticated. That is,
> the public key bound to the DNS name is authentic.
>
> > They ensure encryption, so I can then be
> > phished, be scammed, … encrypted. Big advantage!^^
>
> As I understand it, phishers try to avoid TLS because they count on
> the plain text channel to avoid all the browser warnings. Peter
> Gutmann discusses this in his Engineering Security book
> (https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf).
>
> > Pushing real validation
> > (e.g. EV with green adressbar and validated details by an independent
third
> > party, no breakable, spoofable automatism) vs. no validation is much
more

> > important and should be focussed on.
>
> You should probably read Gutmann's Engineering Security. See his
> discussion of "PKI me harder" in Chapter 1 or 6 (IIRC).
>
> > 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.
>
> Security engineering studies seem to indicate most users don't
> understand the icons. It would probably be better if the browsers did
> the right thing, and took the users out of the loop. Gutmann talks
> about it in detail (with lots of citations).
>
> > Just a proposal:
> >
> > Mark HTTP as Non-Secure (similar to self-signed) e.g. with a red
padlock or
> > sth. similar.
>
> +1. In the browser world, plaintext was (still is?) held in higher
> esteem then opportunistic encryption. Why the browsers choose to
> indicate things this way is a mystery.
>
> > 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
>
> Why green for EV (or why yellow for DV or DANE)? EV does not add any
> technical controls. From a security standpoint, DV and EV are
> equivalent.
>

From an SOP point of view, this is true.
However, it is increasingly less true if you're willing to ignore the (near
cataclysmic) SOP failure, as EV gains technical controls such as
certificate transparency and pontentially mandatory stronger security
settings (e.g. secure ciphersuites in modern TLS, OCSP stapling, etc).
Additionally, there are other technical controls (validity periods, key
processing) that do offer distinction.

That is, it is not all procedural changes, and UAs can detect and
differentiate. While the hope is that these will be able to apply to all
sites in the future, any change of this scale takes time.

> If DNS is authentic, then DANE provides stronger assurances than DV or
> EV since the domain operator published the information and the
> veracity does not rely on others like CAs (modulo DBOUND).
>
> Not relying on a CA is a good thing since its usually advantageous to
> minimize trust (for some definition of "trust"). Plus, CAs don't
> really warrant anything, so its not clear what exactly they are
> providing to relying parties (they are providing a a signature for
> money to the applicant).
>
> Open question: do you think the browsers will support a model other
> than the CA Zoo for rooting trust?

Chromium has no plans for this, particularly those based on DNS/DANE, which
are empirically less secure and more operationally fraught with peril. I
would neither take it as foregone that the CA system cannot improve nor am
I confident that any of the known alternatives are either practical or
comparable in security to CAs, let alone superior.
_______________________________________________
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 Michal Zalewski-2
On 15 December 2014 at 10:30, Michal Zalewski <[hidden email]> wrote:

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


Chris' original proposal is a stick. I want to give a site operator also a
carrot. That can be an option to activate encryption that is not visible to
the user and *receive* from the browser all reports about violations of
secure origin policy. This way the operator will know that they can
activate HTTPS without worsening user experience and have information that
helps to fix the content.

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
>

I am not proposing that a user-invisible encryption should stay forever.
Rather it should be treated just as a tool to help site operators to
transition to the proper https so at no stage the user experience would be
worse than continuing to serve pages with plain http.
_______________________________________________
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

Gervase Markham
In reply to this post by Chris Palmer
On 14/12/14 21:41, Christian Heutger wrote:
> But how can I trust him and who is he?

You are trying to solve a different problem than the problem solved by
DV certificates.

Your problem is a reasonable one to want to solve, and EV certificates
solve it to a degree, but it is not a problem we are required to solve
in order to move the world to HTTPS.

> But wasn’t that the idea of certificates?

Maybe originally; but it turns out, there's a lot of value in many
circumstances in domain-name-based endpoint authentication.

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

Daniel Veditz-2
In reply to this post by Igor Bukanov-2
On 12/15/14 2:03 AM, Igor Bukanov wrote:
> Chris' original proposal is a stick. I want to give a site operator also
> a carrot. That can be an option to activate encryption that is not
> visible to the user and *receive* from the browser all reports about
> violations of secure origin policy. This way the operator will know that
> they can activate HTTPS without worsening user experience and have
> information that helps to fix the content.

Serve the HTML page over http: but load all sub-resources over https: as
expected after the transition. Add the following header:

Content-Security-Policy-Report-Only: default-src https:; report-uri <me>

(add "script-src https: 'unsafe-inline' 'unsafe-eval';" if necessary)

This doesn't give you the benefit of encrypting your main HTML content
during the transition as you requested, but it is something that can be
done today. When the reports come back clean enough you can switch the
page content to https too.

-Dan Veditz
_______________________________________________
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

simonandraspeter
In reply to this post by Chris Palmer
I'm a webmaster and I have switched a good 2 months ago (my website is
really not huge, around 100K unique monthly visitors, it's a one-man
website).
I would say switching was "interesting.
It was easy till I realized I had mixed content on some of my pages ( a
visitor tipped me off, it was embarrassing).
Finding/analyzing and solving that tiny problem was hard. I spent 99% of
the time spent on switching working on that one little problem.

My biggest problem with switching to HTTPS is that it is time and money and
as an independent, non venture backed webmaster my resources are very
limited.

I'm not sure there is a positive ROI in switching for a small webmaster
like me.
My visitors don't care and/or understand what is HTTPS and why is it better
for them.

However, flagging non-secure websites would definitely generate
more awareness.

I definitely - and I think a lot of the small guys, who switched already -
support this 100%.

On Saturday, December 13, 2014 1:46:39 AM UTC+1, Chris Palmer wrote:

>
> Hi everyone,
>
> Apologies to those of you who are about to get this more than once, due to
> the cross-posting. I'd like to get feedback from a wide variety of people:
> UA developers, web developers, and users. The canonical location for this
> proposal is:
> https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
> .
>
> Proposal
>
> We, the Chrome Security Team, propose that user agents (UAs) gradually
> change their UX to display non-secure origins as affirmatively non-secure.
> We intend to devise and begin deploying a transition plan for Chrome in
> 2015.
>
> The goal of this proposal is to more clearly display to users that HTTP
> provides no data security.
>
> Request
>
> We’d like to hear everyone’s thoughts on this proposal, and to discuss
> with the web community about how different transition plans might serve
> users.
>
> Background
>
> We all need data communication on the web to be secure (private,
> authenticated, untampered). When there is no data security, the UA should
> explicitly display that, so users can make informed decisions about how to
> interact with an origin.
>
> Roughly speaking, there are three basic transport layer security states
> for web origins:
>
>
>    -
>    
>    Secure (valid HTTPS, other origins like (*, localhost, *));
>    -
>    
>    Dubious (valid HTTPS but with mixed passive resources, valid HTTPS
>    with minor TLS errors); and
>    -
>    
>    Non-secure (broken HTTPS, HTTP).
>    
>
> For more precise definitions of secure and non-secure, see Requirements
> for Powerful Features <http://www.w3.org/TR/powerful-features/> and Mixed
> Content <http://www.w3.org/TR/mixed-content/>.
>
> We know that active tampering and surveillance attacks, as well as passive
> surveillance attacks, are not theoretical but are in fact commonplace on
> the web.
>
> RFC 7258: Pervasive Monitoring Is an Attack
> <https://tools.ietf.org/html/rfc7258>
>
> NSA uses Google cookies to pinpoint targets for hacking
> <http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/>
>
> Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine
> <http://www.wired.com/2014/10/verizons-perma-cookie/>
>
> How bad is it to replace adSense code id to ISP's adSense ID on free
> Internet?
> <http://stackoverflow.com/questions/25438910/how-bad-is-it-to-replace-adsense-code-id-to-isps-adsense-id-on-free-internet>
>
> Comcast Wi-Fi serving self-promotional ads via JavaScript injection
> <http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/>
>
> Erosion of the moral authority of transparent middleboxes
> <https://tools.ietf.org/html/draft-hildebrand-middlebox-erosion-01>
>
> Transitioning The Web To HTTPS <https://w3ctag.github.io/web-https/>
>
> We know that people do not generally perceive the absence of a warning
> sign. (See e.g. The Emperor's New Security Indicators
> <http://commerce.net/wp-content/uploads/2012/04/The%20Emperors_New_Security_Indicators.pdf>.)
> Yet the only situation in which web browsers are guaranteed not to warn
> users is precisely when there is no chance of security: when the origin is
> transported via HTTP. Here are screenshots of the status quo for non-secure
> domains in Chrome, Safari, Firefox, and Internet Explorer:
>
> [image: Screen Shot 2014-12-11 at 5.08.48 PM.png]
>
> [image: Screen Shot 2014-12-11 at 5.09.55 PM.png]
>
> [image: Screen Shot 2014-12-11 at 5.11.04 PM.png]
>
> [image: ie-non-secure.png]
>
> Particulars
>
> UA vendors who agree with this proposal should decide how best to phase in
> the UX changes given the needs of their users and their product design
> constraints. Generally, we suggest a phased approach to marking non-secure
> origins as non-secure. For example, a UA vendor might decide that in the
> medium term, they will represent non-secure origins in the same way that
> they represent Dubious origins. Then, in the long term, the vendor might
> decide to represent non-secure origins in the same way that they represent
> Bad origins.
>
> Ultimately, we can even imagine a long term in which secure origins are so
> widely deployed that we can leave them unmarked (as HTTP is today), and
> mark only the rare non-secure origins.
>
> There are several ways vendors might decide to transition from one phase
> to the next. For example, the transition plan could be time-based:
>
>
>    1.
>    
>    T0 (now): Non-secure origins unmarked
>    2.
>    
>    T1: Non-secure origins marked as Dubious
>    3.
>    
>    T2: Non-secure origins marked as Non-secure
>    4.
>    
>    T3: Secure origins unmarked
>    
>
> Or, vendors might set thresholds based on telemetry that measures the
> ratios of user interaction with secure origins vs. non-secure. Consider
> this strawman proposal:
>
>
>    1.
>    
>    Secure > 65%: Non-secure origins marked as Dubious
>    2.
>    
>    Secure > 75%: Non-secure origins marked as Non-secure
>    3.
>    
>    Secure > 85%: Secure origins unmarked
>    
>
> The particular thresholds or transition dates are very much up for
> discussion. Additionally, how to define “ratios of user interaction” is
> also up for discussion; ideas include the ratio of secure to non-secure
> page loads, the ratio of secure to non-secure resource loads, or the ratio
> of total time spent interacting with secure vs. non-secure origins.
>
> We’d love to hear what UA vendors, web developers, and users think. Thanks
> for reading!
>
_______________________________________________
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

ferdy.christant
In reply to this post by Chris Palmer
I'm a small website owner and I believe this proposal will upset a lot of
small hosters and website owners. In particular for simple content
websites, https is a burden for them, in time, cost and it not adding much
value. I don't need to be convinced of the security advantages of this
proposal, I'm just looking at the practical aspects of it. Furthermore, as
mentioned here there is the issue of mixed content and plugins you don't
own or control. I sure hope any such warning message is very subtle,
otherwise a lot of traffic will be driven away from websites.

On Saturday, December 13, 2014 1:46:39 AM UTC+1, Chris Palmer wrote:

>
> Hi everyone,
>
> Apologies to those of you who are about to get this more than once, due to
> the cross-posting. I'd like to get feedback from a wide variety of people:
> UA developers, web developers, and users. The canonical location for this
> proposal is:
> https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
> .
>
> Proposal
>
> We, the Chrome Security Team, propose that user agents (UAs) gradually
> change their UX to display non-secure origins as affirmatively non-secure.
> We intend to devise and begin deploying a transition plan for Chrome in
> 2015.
>
> The goal of this proposal is to more clearly display to users that HTTP
> provides no data security.
>
> Request
>
> We’d like to hear everyone’s thoughts on this proposal, and to discuss
> with the web community about how different transition plans might serve
> users.
>
> Background
>
> We all need data communication on the web to be secure (private,
> authenticated, untampered). When there is no data security, the UA should
> explicitly display that, so users can make informed decisions about how to
> interact with an origin.
>
> Roughly speaking, there are three basic transport layer security states
> for web origins:
>
>
>    -
>    
>    Secure (valid HTTPS, other origins like (*, localhost, *));
>    -
>    
>    Dubious (valid HTTPS but with mixed passive resources, valid HTTPS
>    with minor TLS errors); and
>    -
>    
>    Non-secure (broken HTTPS, HTTP).
>    
>
> For more precise definitions of secure and non-secure, see Requirements
> for Powerful Features <http://www.w3.org/TR/powerful-features/> and Mixed
> Content <http://www.w3.org/TR/mixed-content/>.
>
> We know that active tampering and surveillance attacks, as well as passive
> surveillance attacks, are not theoretical but are in fact commonplace on
> the web.
>
> RFC 7258: Pervasive Monitoring Is an Attack
> <https://tools.ietf.org/html/rfc7258>
>
> NSA uses Google cookies to pinpoint targets for hacking
> <http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/>
>
> Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine
> <http://www.wired.com/2014/10/verizons-perma-cookie/>
>
> How bad is it to replace adSense code id to ISP's adSense ID on free
> Internet?
> <http://stackoverflow.com/questions/25438910/how-bad-is-it-to-replace-adsense-code-id-to-isps-adsense-id-on-free-internet>
>
> Comcast Wi-Fi serving self-promotional ads via JavaScript injection
> <http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/>
>
> Erosion of the moral authority of transparent middleboxes
> <https://tools.ietf.org/html/draft-hildebrand-middlebox-erosion-01>
>
> Transitioning The Web To HTTPS <https://w3ctag.github.io/web-https/>
>
> We know that people do not generally perceive the absence of a warning
> sign. (See e.g. The Emperor's New Security Indicators
> <http://commerce.net/wp-content/uploads/2012/04/The%20Emperors_New_Security_Indicators.pdf>.)
> Yet the only situation in which web browsers are guaranteed not to warn
> users is precisely when there is no chance of security: when the origin is
> transported via HTTP. Here are screenshots of the status quo for non-secure
> domains in Chrome, Safari, Firefox, and Internet Explorer:
>
> [image: Screen Shot 2014-12-11 at 5.08.48 PM.png]
>
> [image: Screen Shot 2014-12-11 at 5.09.55 PM.png]
>
> [image: Screen Shot 2014-12-11 at 5.11.04 PM.png]
>
> [image: ie-non-secure.png]
>
> Particulars
>
> UA vendors who agree with this proposal should decide how best to phase in
> the UX changes given the needs of their users and their product design
> constraints. Generally, we suggest a phased approach to marking non-secure
> origins as non-secure. For example, a UA vendor might decide that in the
> medium term, they will represent non-secure origins in the same way that
> they represent Dubious origins. Then, in the long term, the vendor might
> decide to represent non-secure origins in the same way that they represent
> Bad origins.
>
> Ultimately, we can even imagine a long term in which secure origins are so
> widely deployed that we can leave them unmarked (as HTTP is today), and
> mark only the rare non-secure origins.
>
> There are several ways vendors might decide to transition from one phase
> to the next. For example, the transition plan could be time-based:
>
>
>    1.
>    
>    T0 (now): Non-secure origins unmarked
>    2.
>    
>    T1: Non-secure origins marked as Dubious
>    3.
>    
>    T2: Non-secure origins marked as Non-secure
>    4.
>    
>    T3: Secure origins unmarked
>    
>
> Or, vendors might set thresholds based on telemetry that measures the
> ratios of user interaction with secure origins vs. non-secure. Consider
> this strawman proposal:
>
>
>    1.
>    
>    Secure > 65%: Non-secure origins marked as Dubious
>    2.
>    
>    Secure > 75%: Non-secure origins marked as Non-secure
>    3.
>    
>    Secure > 85%: Secure origins unmarked
>    
>
> The particular thresholds or transition dates are very much up for
> discussion. Additionally, how to define “ratios of user interaction” is
> also up for discussion; ideas include the ratio of secure to non-secure
> page loads, the ratio of secure to non-secure resource loads, or the ratio
> of total time spent interacting with secure vs. non-secure origins.
>
> We’d love to hear what UA vendors, web developers, and users think. Thanks
> for reading!
>
_______________________________________________
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

Adrienne Porter Felt-2
If someone thinks their users are OK with their website not having
integrity/authentication/privacy, then why is it problematic that Chrome
will start telling users about it? Presumably these users would still be OK
with it after Chrome starts making the situation more obvious. (And if the
users start disliking it, then perhaps they really were never OK with it in
the first place?)

On Mon, Dec 15, 2014 at 3:28 PM, <[hidden email]> wrote:

>
> I'm a small website owner and I believe this proposal will upset a lot of
> small hosters and website owners. In particular for simple content
> websites, https is a burden for them, in time, cost and it not adding much
> value. I don't need to be convinced of the security advantages of this
> proposal, I'm just looking at the practical aspects of it. Furthermore, as
> mentioned here there is the issue of mixed content and plugins you don't
> own or control. I sure hope any such warning message is very subtle,
> otherwise a lot of traffic will be driven away from websites.
>
> On Saturday, December 13, 2014 1:46:39 AM UTC+1, Chris Palmer wrote:
>
>> Hi everyone,
>>
>> Apologies to those of you who are about to get this more than once, due
>> to the cross-posting. I'd like to get feedback from a wide variety of
>> people: UA developers, web developers, and users. The canonical location
>> for this proposal is: https://www.chromium.org/Home/
>> chromium-security/marking-http-as-non-secure.
>>
>> Proposal
>>
>> We, the Chrome Security Team, propose that user agents (UAs) gradually
>> change their UX to display non-secure origins as affirmatively non-secure.
>> We intend to devise and begin deploying a transition plan for Chrome in
>> 2015.
>>
>> The goal of this proposal is to more clearly display to users that HTTP
>> provides no data security.
>>
>> Request
>>
>> We’d like to hear everyone’s thoughts on this proposal, and to discuss
>> with the web community about how different transition plans might serve
>> users.
>>
>> Background
>>
>> We all need data communication on the web to be secure (private,
>> authenticated, untampered). When there is no data security, the UA should
>> explicitly display that, so users can make informed decisions about how to
>> interact with an origin.
>>
>> Roughly speaking, there are three basic transport layer security states
>> for web origins:
>>
>>
>>    -
>>
>>    Secure (valid HTTPS, other origins like (*, localhost, *));
>>    -
>>
>>    Dubious (valid HTTPS but with mixed passive resources, valid HTTPS
>>    with minor TLS errors); and
>>    -
>>
>>    Non-secure (broken HTTPS, HTTP).
>>
>>
>> For more precise definitions of secure and non-secure, see Requirements
>> for Powerful Features <http://www.w3.org/TR/powerful-features/> and Mixed
>> Content <http://www.w3.org/TR/mixed-content/>.
>>
>> We know that active tampering and surveillance attacks, as well as
>> passive surveillance attacks, are not theoretical but are in fact
>> commonplace on the web.
>>
>> RFC 7258: Pervasive Monitoring Is an Attack
>> <https://tools.ietf.org/html/rfc7258>
>>
>> NSA uses Google cookies to pinpoint targets for hacking
>> <http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/>
>>
>> Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine
>> <http://www.wired.com/2014/10/verizons-perma-cookie/>
>>
>> How bad is it to replace adSense code id to ISP's adSense ID on free
>> Internet?
>> <http://stackoverflow.com/questions/25438910/how-bad-is-it-to-replace-adsense-code-id-to-isps-adsense-id-on-free-internet>
>>
>> Comcast Wi-Fi serving self-promotional ads via JavaScript injection
>> <http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/>
>>
>> Erosion of the moral authority of transparent middleboxes
>> <https://tools.ietf.org/html/draft-hildebrand-middlebox-erosion-01>
>>
>> Transitioning The Web To HTTPS <https://w3ctag.github.io/web-https/>
>>
>> We know that people do not generally perceive the absence of a warning
>> sign. (See e.g. The Emperor's New Security Indicators
>> <http://commerce.net/wp-content/uploads/2012/04/The%20Emperors_New_Security_Indicators.pdf>.)
>> Yet the only situation in which web browsers are guaranteed not to warn
>> users is precisely when there is no chance of security: when the origin is
>> transported via HTTP. Here are screenshots of the status quo for non-secure
>> domains in Chrome, Safari, Firefox, and Internet Explorer:
>>
>> [image: Screen Shot 2014-12-11 at 5.08.48 PM.png]
>>
>> [image: Screen Shot 2014-12-11 at 5.09.55 PM.png]
>>
>> [image: Screen Shot 2014-12-11 at 5.11.04 PM.png]
>>
>> [image: ie-non-secure.png]
>>
>> Particulars
>>
>> UA vendors who agree with this proposal should decide how best to phase
>> in the UX changes given the needs of their users and their product design
>> constraints. Generally, we suggest a phased approach to marking non-secure
>> origins as non-secure. For example, a UA vendor might decide that in the
>> medium term, they will represent non-secure origins in the same way that
>> they represent Dubious origins. Then, in the long term, the vendor might
>> decide to represent non-secure origins in the same way that they represent
>> Bad origins.
>>
>> Ultimately, we can even imagine a long term in which secure origins are
>> so widely deployed that we can leave them unmarked (as HTTP is today), and
>> mark only the rare non-secure origins.
>>
>> There are several ways vendors might decide to transition from one phase
>> to the next. For example, the transition plan could be time-based:
>>
>>
>>    1.
>>
>>    T0 (now): Non-secure origins unmarked
>>    2.
>>
>>    T1: Non-secure origins marked as Dubious
>>    3.
>>
>>    T2: Non-secure origins marked as Non-secure
>>    4.
>>
>>    T3: Secure origins unmarked
>>
>>
>> Or, vendors might set thresholds based on telemetry that measures the
>> ratios of user interaction with secure origins vs. non-secure. Consider
>> this strawman proposal:
>>
>>
>>    1.
>>
>>    Secure > 65%: Non-secure origins marked as Dubious
>>    2.
>>
>>    Secure > 75%: Non-secure origins marked as Non-secure
>>    3.
>>
>>    Secure > 85%: Secure origins unmarked
>>
>>
>> The particular thresholds or transition dates are very much up for
>> discussion. Additionally, how to define “ratios of user interaction” is
>> also up for discussion; ideas include the ratio of secure to non-secure
>> page loads, the ratio of secure to non-secure resource loads, or the ratio
>> of total time spent interacting with secure vs. non-secure origins.
>>
>> We’d love to hear what UA vendors, web developers, and users think.
>> Thanks for reading!
>>
>
_______________________________________________
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

Alex Gaynor
Indeed, the notion that users don't care is based on an ill-founded premise
of informed consent.

Here's a copy-pasted comment I made elsewhere on this topic:

To respect a user's decision, their decision needs to be an informed one,
and it needs to be choice. I don't think there's a reasonable basis to say
either of those are the case with users using HTTP in favor of HTTPS:

First, is it a choice: given that browsers default to HTTP, when no
protocol is explicitly selected, and that many users will access the site
via external links that they don't control, I don't think it's fair to say
that users choose HTTP, they simply get HTTP.

Second, if we did say they'd made a choice, was an informed one. We, as an
industry, have done a very poor job of educating users about the security
implications of actions online. I don't believe most non-technical users
have an understanding of what the implications of the loss of the
Authentication, Integrity, or Confidentiality that coms with preferring
HTTP to HTTPS are.

Given the fact that most users don't proactively consent to having their
content spied upon or mutated in transit, and insofar as they do, it is not
informed consent, I don't believe website authors have any obligation to
provide access to content over dangerous protocols like HTTP.


Alex

On Mon Dec 15 2014 at 3:50:36 PM Adrienne Porter Felt <[hidden email]>
wrote:

> If someone thinks their users are OK with their website not having
> integrity/authentication/privacy, then why is it problematic that Chrome
> will start telling users about it? Presumably these users would still be OK
> with it after Chrome starts making the situation more obvious. (And if the
> users start disliking it, then perhaps they really were never OK with it in
> the first place?)
>
> On Mon, Dec 15, 2014 at 3:28 PM, <[hidden email]> wrote:
>>
>> I'm a small website owner and I believe this proposal will upset a lot of
>> small hosters and website owners. In particular for simple content
>> websites, https is a burden for them, in time, cost and it not adding much
>> value. I don't need to be convinced of the security advantages of this
>> proposal, I'm just looking at the practical aspects of it. Furthermore, as
>> mentioned here there is the issue of mixed content and plugins you don't
>> own or control. I sure hope any such warning message is very subtle,
>> otherwise a lot of traffic will be driven away from websites.
>>
>> On Saturday, December 13, 2014 1:46:39 AM UTC+1, Chris Palmer wrote:
>>
>>> Hi everyone,
>>>
>>> Apologies to those of you who are about to get this more than once, due
>>> to the cross-posting. I'd like to get feedback from a wide variety of
>>> people: UA developers, web developers, and users. The canonical location
>>> for this proposal is: https://www.chromium.org/Home/
>>> chromium-security/marking-http-as-non-secure.
>>>
>>> Proposal
>>>
>>> We, the Chrome Security Team, propose that user agents (UAs) gradually
>>> change their UX to display non-secure origins as affirmatively non-secure.
>>> We intend to devise and begin deploying a transition plan for Chrome in
>>> 2015.
>>>
>>> The goal of this proposal is to more clearly display to users that HTTP
>>> provides no data security.
>>>
>>> Request
>>>
>>> We’d like to hear everyone’s thoughts on this proposal, and to discuss
>>> with the web community about how different transition plans might serve
>>> users.
>>>
>>> Background
>>>
>>> We all need data communication on the web to be secure (private,
>>> authenticated, untampered). When there is no data security, the UA should
>>> explicitly display that, so users can make informed decisions about how to
>>> interact with an origin.
>>>
>>> Roughly speaking, there are three basic transport layer security states
>>> for web origins:
>>>
>>>
>>>    -
>>>
>>>    Secure (valid HTTPS, other origins like (*, localhost, *));
>>>    -
>>>
>>>    Dubious (valid HTTPS but with mixed passive resources, valid HTTPS
>>>    with minor TLS errors); and
>>>    -
>>>
>>>    Non-secure (broken HTTPS, HTTP).
>>>
>>>
>>> For more precise definitions of secure and non-secure, see Requirements
>>> for Powerful Features <http://www.w3.org/TR/powerful-features/> and Mixed
>>> Content <http://www.w3.org/TR/mixed-content/>.
>>>
>>> We know that active tampering and surveillance attacks, as well as
>>> passive surveillance attacks, are not theoretical but are in fact
>>> commonplace on the web.
>>>
>>> RFC 7258: Pervasive Monitoring Is an Attack
>>> <https://tools.ietf.org/html/rfc7258>
>>>
>>> NSA uses Google cookies to pinpoint targets for hacking
>>> <http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/>
>>>
>>> Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine
>>> <http://www.wired.com/2014/10/verizons-perma-cookie/>
>>>
>>> How bad is it to replace adSense code id to ISP's adSense ID on free
>>> Internet?
>>> <http://stackoverflow.com/questions/25438910/how-bad-is-it-to-replace-adsense-code-id-to-isps-adsense-id-on-free-internet>
>>>
>>> Comcast Wi-Fi serving self-promotional ads via JavaScript injection
>>> <http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/>
>>>
>>> Erosion of the moral authority of transparent middleboxes
>>> <https://tools.ietf.org/html/draft-hildebrand-middlebox-erosion-01>
>>>
>>> Transitioning The Web To HTTPS <https://w3ctag.github.io/web-https/>
>>>
>>> We know that people do not generally perceive the absence of a warning
>>> sign. (See e.g. The Emperor's New Security Indicators
>>> <http://commerce.net/wp-content/uploads/2012/04/The%20Emperors_New_Security_Indicators.pdf>.)
>>> Yet the only situation in which web browsers are guaranteed not to warn
>>> users is precisely when there is no chance of security: when the origin is
>>> transported via HTTP. Here are screenshots of the status quo for non-secure
>>> domains in Chrome, Safari, Firefox, and Internet Explorer:
>>>
>>> [image: Screen Shot 2014-12-11 at 5.08.48 PM.png]
>>>
>>> [image: Screen Shot 2014-12-11 at 5.09.55 PM.png]
>>>
>>> [image: Screen Shot 2014-12-11 at 5.11.04 PM.png]
>>>
>>> [image: ie-non-secure.png]
>>>
>>> Particulars
>>>
>>> UA vendors who agree with this proposal should decide how best to phase
>>> in the UX changes given the needs of their users and their product design
>>> constraints. Generally, we suggest a phased approach to marking non-secure
>>> origins as non-secure. For example, a UA vendor might decide that in the
>>> medium term, they will represent non-secure origins in the same way that
>>> they represent Dubious origins. Then, in the long term, the vendor might
>>> decide to represent non-secure origins in the same way that they represent
>>> Bad origins.
>>>
>>> Ultimately, we can even imagine a long term in which secure origins are
>>> so widely deployed that we can leave them unmarked (as HTTP is today), and
>>> mark only the rare non-secure origins.
>>>
>>> There are several ways vendors might decide to transition from one phase
>>> to the next. For example, the transition plan could be time-based:
>>>
>>>
>>>    1.
>>>
>>>    T0 (now): Non-secure origins unmarked
>>>    2.
>>>
>>>    T1: Non-secure origins marked as Dubious
>>>    3.
>>>
>>>    T2: Non-secure origins marked as Non-secure
>>>    4.
>>>
>>>    T3: Secure origins unmarked
>>>
>>>
>>> Or, vendors might set thresholds based on telemetry that measures the
>>> ratios of user interaction with secure origins vs. non-secure. Consider
>>> this strawman proposal:
>>>
>>>
>>>    1.
>>>
>>>    Secure > 65%: Non-secure origins marked as Dubious
>>>    2.
>>>
>>>    Secure > 75%: Non-secure origins marked as Non-secure
>>>    3.
>>>
>>>    Secure > 85%: Secure origins unmarked
>>>
>>>
>>> The particular thresholds or transition dates are very much up for
>>> discussion. Additionally, how to define “ratios of user interaction” is
>>> also up for discussion; ideas include the ratio of secure to non-secure
>>> page loads, the ratio of secure to non-secure resource loads, or the ratio
>>> of total time spent interacting with secure vs. non-secure origins.
>>>
>>> We’d love to hear what UA vendors, web developers, and users think.
>>> Thanks for reading!
>>>
>>  To unsubscribe from this group and stop receiving emails from it, send
> an email to [hidden email].
>
_______________________________________________
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

ferdy.christant
In reply to this post by Adrienne Porter Felt-2
"If someone thinks their users are OK with their website not having
integrity/authentication/privacy"

That is an assumption that doesn't apply to every website. Many websites
don't even have authentication.

"Presumably these users would still be OK with it after Chrome starts
making the situation more obvious."

Or perhaps it doesn't, and it scares them away. Just like with the cookie
bars, where now every user believes all cookies are evil. You assume users
are able to make an informed decision based on such warnings, and I doubt
that.

"Presumably these users would still be OK with it after Chrome starts
making the situation more obvious"

On Tuesday, December 16, 2014 12:50:38 AM UTC+1, Adrienne Porter Felt wrote:

>
> If someone thinks their users are OK with their website not having
> integrity/authentication/privacy, then why is it problematic that Chrome
> will start telling users about it? Presumably these users would still be OK
> with it after Chrome starts making the situation more obvious. (And if the
> users start disliking it, then perhaps they really were never OK with it in
> the first place?)
>
> On Mon, Dec 15, 2014 at 3:28 PM, <[hidden email] <javascript:>>
> wrote:
>>
>> I'm a small website owner and I believe this proposal will upset a lot of
>> small hosters and website owners. In particular for simple content
>> websites, https is a burden for them, in time, cost and it not adding much
>> value. I don't need to be convinced of the security advantages of this
>> proposal, I'm just looking at the practical aspects of it. Furthermore, as
>> mentioned here there is the issue of mixed content and plugins you don't
>> own or control. I sure hope any such warning message is very subtle,
>> otherwise a lot of traffic will be driven away from websites.
>>
>> On Saturday, December 13, 2014 1:46:39 AM UTC+1, Chris Palmer wrote:
>>
>>> Hi everyone,
>>>
>>> Apologies to those of you who are about to get this more than once, due
>>> to the cross-posting. I'd like to get feedback from a wide variety of
>>> people: UA developers, web developers, and users. The canonical location
>>> for this proposal is: https://www.chromium.org/Home/
>>> chromium-security/marking-http-as-non-secure.
>>>
>>> Proposal
>>>
>>> We, the Chrome Security Team, propose that user agents (UAs) gradually
>>> change their UX to display non-secure origins as affirmatively non-secure.
>>> We intend to devise and begin deploying a transition plan for Chrome in
>>> 2015.
>>>
>>> The goal of this proposal is to more clearly display to users that HTTP
>>> provides no data security.
>>>
>>> Request
>>>
>>> We’d like to hear everyone’s thoughts on this proposal, and to discuss
>>> with the web community about how different transition plans might serve
>>> users.
>>>
>>> Background
>>>
>>> We all need data communication on the web to be secure (private,
>>> authenticated, untampered). When there is no data security, the UA should
>>> explicitly display that, so users can make informed decisions about how to
>>> interact with an origin.
>>>
>>> Roughly speaking, there are three basic transport layer security states
>>> for web origins:
>>>
>>>
>>>    -
>>>    
>>>    Secure (valid HTTPS, other origins like (*, localhost, *));
>>>    -
>>>    
>>>    Dubious (valid HTTPS but with mixed passive resources, valid HTTPS
>>>    with minor TLS errors); and
>>>    -
>>>    
>>>    Non-secure (broken HTTPS, HTTP).
>>>    
>>>
>>> For more precise definitions of secure and non-secure, see Requirements
>>> for Powerful Features <http://www.w3.org/TR/powerful-features/> and Mixed
>>> Content <http://www.w3.org/TR/mixed-content/>.
>>>
>>> We know that active tampering and surveillance attacks, as well as
>>> passive surveillance attacks, are not theoretical but are in fact
>>> commonplace on the web.
>>>
>>> RFC 7258: Pervasive Monitoring Is an Attack
>>> <https://tools.ietf.org/html/rfc7258>
>>>
>>> NSA uses Google cookies to pinpoint targets for hacking
>>> <http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/>
>>>
>>> Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine
>>> <http://www.wired.com/2014/10/verizons-perma-cookie/>
>>>
>>> How bad is it to replace adSense code id to ISP's adSense ID on free
>>> Internet?
>>> <http://stackoverflow.com/questions/25438910/how-bad-is-it-to-replace-adsense-code-id-to-isps-adsense-id-on-free-internet>
>>>
>>> Comcast Wi-Fi serving self-promotional ads via JavaScript injection
>>> <http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/>
>>>
>>> Erosion of the moral authority of transparent middleboxes
>>> <https://tools.ietf.org/html/draft-hildebrand-middlebox-erosion-01>
>>>
>>> Transitioning The Web To HTTPS <https://w3ctag.github.io/web-https/>
>>>
>>> We know that people do not generally perceive the absence of a warning
>>> sign. (See e.g. The Emperor's New Security Indicators
>>> <http://commerce.net/wp-content/uploads/2012/04/The%20Emperors_New_Security_Indicators.pdf>.)
>>> Yet the only situation in which web browsers are guaranteed not to warn
>>> users is precisely when there is no chance of security: when the origin is
>>> transported via HTTP. Here are screenshots of the status quo for non-secure
>>> domains in Chrome, Safari, Firefox, and Internet Explorer:
>>>
>>> [image: Screen Shot 2014-12-11 at 5.08.48 PM.png]
>>>
>>> [image: Screen Shot 2014-12-11 at 5.09.55 PM.png]
>>>
>>> [image: Screen Shot 2014-12-11 at 5.11.04 PM.png]
>>>
>>> [image: ie-non-secure.png]
>>>
>>> Particulars
>>>
>>> UA vendors who agree with this proposal should decide how best to phase
>>> in the UX changes given the needs of their users and their product design
>>> constraints. Generally, we suggest a phased approach to marking non-secure
>>> origins as non-secure. For example, a UA vendor might decide that in the
>>> medium term, they will represent non-secure origins in the same way that
>>> they represent Dubious origins. Then, in the long term, the vendor might
>>> decide to represent non-secure origins in the same way that they represent
>>> Bad origins.
>>>
>>> Ultimately, we can even imagine a long term in which secure origins are
>>> so widely deployed that we can leave them unmarked (as HTTP is today), and
>>> mark only the rare non-secure origins.
>>>
>>> There are several ways vendors might decide to transition from one phase
>>> to the next. For example, the transition plan could be time-based:
>>>
>>>
>>>    1.
>>>    
>>>    T0 (now): Non-secure origins unmarked
>>>    2.
>>>    
>>>    T1: Non-secure origins marked as Dubious
>>>    3.
>>>    
>>>    T2: Non-secure origins marked as Non-secure
>>>    4.
>>>    
>>>    T3: Secure origins unmarked
>>>    
>>>
>>> Or, vendors might set thresholds based on telemetry that measures the
>>> ratios of user interaction with secure origins vs. non-secure. Consider
>>> this strawman proposal:
>>>
>>>
>>>    1.
>>>    
>>>    Secure > 65%: Non-secure origins marked as Dubious
>>>    2.
>>>    
>>>    Secure > 75%: Non-secure origins marked as Non-secure
>>>    3.
>>>    
>>>    Secure > 85%: Secure origins unmarked
>>>    
>>>
>>> The particular thresholds or transition dates are very much up for
>>> discussion. Additionally, how to define “ratios of user interaction” is
>>> also up for discussion; ideas include the ratio of secure to non-secure
>>> page loads, the ratio of secure to non-secure resource loads, or the ratio
>>> of total time spent interacting with secure vs. non-secure origins.
>>>
>>> We’d love to hear what UA vendors, web developers, and users think.
>>> Thanks for reading!
>>>
>>
_______________________________________________
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

Ryan Sleevi-2
On Mon, Dec 15, 2014 at 4:10 PM, <[hidden email]> wrote:
>
> "If someone thinks their users are OK with their website not having
> integrity/authentication/privacy"
>
> That is an assumption that doesn't apply to every website. Many websites
> don't even have authentication.
>

I think there may be some confusion.

"Authentication" here does not refer to "Does the user authenticate
themselves to the site" (e.g. do they log in), but "Is the site you're
talking to the site you the site you expected" (or, put differently, "Does
the server authenticate itself to the user").

Without authentication in this sense (e.g. talking to whom you think you're
talking to), anyone can trivially impersonate a server and alter the
responses. This is not that hard, a few examples for you about why
authentication is important, even for sites without logins:

http://newstweek.com/
http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/
http://webpolicy.org/2014/10/24/how-verizons-advertising-header-works/

This is why it's important to know you're talking to the site you're
expecting (Authentication), and that no one has modified that site's
contents (Integrity).
_______________________________________________
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

Donald Stufft
In reply to this post by ferdy.christant

> On Dec 15, 2014, at 7:10 PM, [hidden email] wrote:
>
> "If someone thinks their users are OK with their website not having integrity/authentication/privacy"
>
> That is an assumption that doesn't apply to every website. Many websites don't even have authentication.
>
> "Presumably these users would still be OK with it after Chrome starts making the situation more obvious."
>
> Or perhaps it doesn't, and it scares them away. Just like with the cookie bars, where now every user believes all cookies are evil. You assume users are able to make an informed decision based on such warnings, and I doubt that.
>
> "Presumably these users would still be OK with it after Chrome starts making the situation more obvious"


If users are unable to make an informed choice than I personally believe it’s up to the User Agent to try and pick what choice the user most likely wants. I have a hard time imagining that most users, if given the choice between allowing anyone in the same coffee shop to read what they are reading and not allowing, would willingly choose HTTP over HTTPS.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

_______________________________________________
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

ferdy.christant
In reply to this post by Alex Gaynor
"To respect a user's decision, their decision needs to be an informed one,
and it needs to be choice. I don't think there's a reasonable basis to say
either of those are the case with users using HTTP in favor of HTTPS:"

What if a decision doesn't apply, what if the user is unable to be informed
and make a proper decision? I don't agree that every action should be
decided upon by the end-user, I am much more in favor of education website
owners.

On Tuesday, December 16, 2014 12:53:05 AM UTC+1, Alex Gaynor wrote:

>
> Indeed, the notion that users don't care is based on an ill-founded
> premise of informed consent.
>
> Here's a copy-pasted comment I made elsewhere on this topic:
>
> To respect a user's decision, their decision needs to be an informed one,
> and it needs to be choice. I don't think there's a reasonable basis to say
> either of those are the case with users using HTTP in favor of HTTPS:
>
> First, is it a choice: given that browsers default to HTTP, when no
> protocol is explicitly selected, and that many users will access the site
> via external links that they don't control, I don't think it's fair to say
> that users choose HTTP, they simply get HTTP.
>
> Second, if we did say they'd made a choice, was an informed one. We, as an
> industry, have done a very poor job of educating users about the security
> implications of actions online. I don't believe most non-technical users
> have an understanding of what the implications of the loss of the
> Authentication, Integrity, or Confidentiality that coms with preferring
> HTTP to HTTPS are.
>
> Given the fact that most users don't proactively consent to having their
> content spied upon or mutated in transit, and insofar as they do, it is not
> informed consent, I don't believe website authors have any obligation to
> provide access to content over dangerous protocols like HTTP.
>
>
> Alex
>
> On Mon Dec 15 2014 at 3:50:36 PM Adrienne Porter Felt <[hidden email]
> <javascript:>> wrote:
>
>> If someone thinks their users are OK with their website not having
>> integrity/authentication/privacy, then why is it problematic that Chrome
>> will start telling users about it? Presumably these users would still be OK
>> with it after Chrome starts making the situation more obvious. (And if the
>> users start disliking it, then perhaps they really were never OK with it in
>> the first place?)
>>
>> On Mon, Dec 15, 2014 at 3:28 PM, <[hidden email] <javascript:>>
>> wrote:
>>>
>>> I'm a small website owner and I believe this proposal will upset a lot
>>> of small hosters and website owners. In particular for simple content
>>> websites, https is a burden for them, in time, cost and it not adding much
>>> value. I don't need to be convinced of the security advantages of this
>>> proposal, I'm just looking at the practical aspects of it. Furthermore, as
>>> mentioned here there is the issue of mixed content and plugins you don't
>>> own or control. I sure hope any such warning message is very subtle,
>>> otherwise a lot of traffic will be driven away from websites.
>>>
>>> On Saturday, December 13, 2014 1:46:39 AM UTC+1, Chris Palmer wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> Apologies to those of you who are about to get this more than once, due
>>>> to the cross-posting. I'd like to get feedback from a wide variety of
>>>> people: UA developers, web developers, and users. The canonical location
>>>> for this proposal is: https://www.chromium.org/Home/
>>>> chromium-security/marking-http-as-non-secure.
>>>>
>>>> Proposal
>>>>
>>>> We, the Chrome Security Team, propose that user agents (UAs) gradually
>>>> change their UX to display non-secure origins as affirmatively non-secure.
>>>> We intend to devise and begin deploying a transition plan for Chrome in
>>>> 2015.
>>>>
>>>> The goal of this proposal is to more clearly display to users that HTTP
>>>> provides no data security.
>>>>
>>>> Request
>>>>
>>>> We’d like to hear everyone’s thoughts on this proposal, and to discuss
>>>> with the web community about how different transition plans might serve
>>>> users.
>>>>
>>>> Background
>>>>
>>>> We all need data communication on the web to be secure (private,
>>>> authenticated, untampered). When there is no data security, the UA should
>>>> explicitly display that, so users can make informed decisions about how to
>>>> interact with an origin.
>>>>
>>>> Roughly speaking, there are three basic transport layer security states
>>>> for web origins:
>>>>
>>>>
>>>>    -
>>>>    
>>>>    Secure (valid HTTPS, other origins like (*, localhost, *));
>>>>    -
>>>>    
>>>>    Dubious (valid HTTPS but with mixed passive resources, valid HTTPS
>>>>    with minor TLS errors); and
>>>>    -
>>>>    
>>>>    Non-secure (broken HTTPS, HTTP).
>>>>    
>>>>
>>>> For more precise definitions of secure and non-secure, see Requirements
>>>> for Powerful Features <http://www.w3.org/TR/powerful-features/> and Mixed
>>>> Content <http://www.w3.org/TR/mixed-content/>.
>>>>
>>>> We know that active tampering and surveillance attacks, as well as
>>>> passive surveillance attacks, are not theoretical but are in fact
>>>> commonplace on the web.
>>>>
>>>> RFC 7258: Pervasive Monitoring Is an Attack
>>>> <https://tools.ietf.org/html/rfc7258>
>>>>
>>>> NSA uses Google cookies to pinpoint targets for hacking
>>>> <http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/>
>>>>
>>>> Verizon’s ‘Perma-Cookie’ Is a Privacy-Killing Machine
>>>> <http://www.wired.com/2014/10/verizons-perma-cookie/>
>>>>
>>>> How bad is it to replace adSense code id to ISP's adSense ID on free
>>>> Internet?
>>>> <http://stackoverflow.com/questions/25438910/how-bad-is-it-to-replace-adsense-code-id-to-isps-adsense-id-on-free-internet>
>>>>
>>>> Comcast Wi-Fi serving self-promotional ads via JavaScript injection
>>>> <http://arstechnica.com/tech-policy/2014/09/why-comcasts-javascript-ad-injections-threaten-security-net-neutrality/>
>>>>
>>>> Erosion of the moral authority of transparent middleboxes
>>>> <https://tools.ietf.org/html/draft-hildebrand-middlebox-erosion-01>
>>>>
>>>> Transitioning The Web To HTTPS <https://w3ctag.github.io/web-https/>
>>>>
>>>> We know that people do not generally perceive the absence of a warning
>>>> sign. (See e.g. The Emperor's New Security Indicators
>>>> <http://commerce.net/wp-content/uploads/2012/04/The%20Emperors_New_Security_Indicators.pdf>.)
>>>> Yet the only situation in which web browsers are guaranteed not to warn
>>>> users is precisely when there is no chance of security: when the origin is
>>>> transported via HTTP. Here are screenshots of the status quo for non-secure
>>>> domains in Chrome, Safari, Firefox, and Internet Explorer:
>>>>
>>>> [image: Screen Shot 2014-12-11 at 5.08.48 PM.png]
>>>>
>>>> [image: Screen Shot 2014-12-11 at 5.09.55 PM.png]
>>>>
>>>> [image: Screen Shot 2014-12-11 at 5.11.04 PM.png]
>>>>
>>>> [image: ie-non-secure.png]
>>>>
>>>> Particulars
>>>>
>>>> UA vendors who agree with this proposal should decide how best to phase
>>>> in the UX changes given the needs of their users and their product design
>>>> constraints. Generally, we suggest a phased approach to marking non-secure
>>>> origins as non-secure. For example, a UA vendor might decide that in the
>>>> medium term, they will represent non-secure origins in the same way that
>>>> they represent Dubious origins. Then, in the long term, the vendor might
>>>> decide to represent non-secure origins in the same way that they represent
>>>> Bad origins.
>>>>
>>>> Ultimately, we can even imagine a long term in which secure origins are
>>>> so widely deployed that we can leave them unmarked (as HTTP is today), and
>>>> mark only the rare non-secure origins.
>>>>
>>>> There are several ways vendors might decide to transition from one
>>>> phase to the next. For example, the transition plan could be time-based:
>>>>
>>>>
>>>>    1.
>>>>    
>>>>    T0 (now): Non-secure origins unmarked
>>>>    2.
>>>>    
>>>>    T1: Non-secure origins marked as Dubious
>>>>    3.
>>>>    
>>>>    T2: Non-secure origins marked as Non-secure
>>>>    4.
>>>>    
>>>>    T3: Secure origins unmarked
>>>>    
>>>>
>>>> Or, vendors might set thresholds based on telemetry that measures the
>>>> ratios of user interaction with secure origins vs. non-secure. Consider
>>>> this strawman proposal:
>>>>
>>>>
>>>>    1.
>>>>    
>>>>    Secure > 65%: Non-secure origins marked as Dubious
>>>>    2.
>>>>    
>>>>    Secure > 75%: Non-secure origins marked as Non-secure
>>>>    3.
>>>>    
>>>>    Secure > 85%: Secure origins unmarked
>>>>    
>>>>
>>>> The particular thresholds or transition dates are very much up for
>>>> discussion. Additionally, how to define “ratios of user interaction” is
>>>> also up for discussion; ideas include the ratio of secure to non-secure
>>>> page loads, the ratio of secure to non-secure resource loads, or the ratio
>>>> of total time spent interacting with secure vs. non-secure origins.
>>>>
>>>> We’d love to hear what UA vendors, web developers, and users think.
>>>> Thanks for reading!
>>>>
>>>  To unsubscribe from this group and stop receiving emails from it, send
>> an email to [hidden email] <javascript:>.
>>
>
_______________________________________________
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

ferdy.christant
In reply to this post by Donald Stufft
I think a choice between HTTP and HTTPS by the user doesn't make sense. The
choice is different, it is the choice between staying on a HTTP-only site
or leaving it alltogether.

On Tuesday, December 16, 2014 1:12:31 AM UTC+1, Donald Stufft wrote:

>
>
> On Dec 15, 2014, at 7:10 PM, [hidden email] <javascript:> wrote:
>
> "If someone thinks their users are OK with their website not having
> integrity/authentication/privacy"
>
> That is an assumption that doesn't apply to every website. Many websites
> don't even have authentication.
>
> "Presumably these users would still be OK with it after Chrome starts
> making the situation more obvious."
>
> Or perhaps it doesn't, and it scares them away. Just like with the cookie
> bars, where now every user believes all cookies are evil. You assume users
> are able to make an informed decision based on such warnings, and I doubt
> that.
>
> "Presumably these users would still be OK with it after Chrome starts
> making the situation more obvious"
>
>
> If users are unable to make an informed choice than I personally believe
> it’s up to the User Agent to try and pick what choice the user most likely
> wants. I have a hard time imagining that most users, if given the choice
> between allowing anyone in the same coffee shop to read what they are
> reading and not allowing, would willingly choose HTTP over HTTPS.
>
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>  
>
_______________________________________________
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 Jeffrey Walton
>Surely you haven't missed the big danger in plain text traffic. That
>traffic gets usuroed and fed into susyems like Xkeyscore for Tailored
>Access Operations (TAO). In layman's terms, adversaries are using the
>information gathered to gain unauthorized access to systems.

With DV (weak validation) it then goes encrypted to them, I don¹t see the
advantage. The magic bullet TOR to prevent from being monitored also
showed up, that the expected privacy may be broken. It¹s a good idea but
therefor stepping back from the value of PKIX is the wrong way in my
opinion.

>The race to the bottom among CAs is to blame for the quality of
>verification by the CAs.

Right, so DV need to be deprecated or set to a recognizable lower level,
clearly stating that it¹s only encryption, nothing else.

>With companies like StartCom, Cacert and Mozilla offering free
>certificates, there is no barrier to entry.

And no barrier breaking the value of certificate authorities vs.
self-signed certificates (Cacert is the only good exception, for a good
reason their approach is different).

>Plus, I don't think a certificate needs to say anything about the
>operator. They need to ensure the server is authenticated. That is, the
>public key bound to the DNS name is authentic.

If a certificate doesn¹t tell, what should tell? How should I be sure to
be on www.onlinebanking.de and not www.onlínebanking.de (see the accent)
by getting spoofed or phished? It¹s the same for Facebook.com or
Facebo0k.com, ...

>As I understand it, phishers try to avoid TLS because they count on the
>plain text channel to avoid all the browser warnings. Peter Gutmann
>discusses this in his Engineering Security book
>(https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf).

If there is a free certificate for everyone and everything is https, which
browser warnings should occur?

>Why green for EV (or why yellow for DV or DANE)? EV does not add any
>technical controls. From a security standpoint, DV and EV are equivalent.

That¹s what certificates are for. If we only would want to have
encryption, there would never be any requirement for certificates.
Browsers and servers handle cipher suites, handshakes etc., the
certificate is the digital equivalent to an authorized identity card, and
there for sure DV and EV are different. Security is about confidentiality,
integrity and availability. Confidentiality is the encryption, integrity
is the validation.

>If DNS is authentic, then DANE provides stronger assurances than DV or EV
>since the domain operator published the information and the veracity does
>not rely on others like CAs (modulo DBOUND).

From the pure technical standpoint, yes, from the validation standpoint,
no. DANE has the hazel of compatibility, but it also struggle with harder
mandatory realization of restrictions (online or offline key material, key
sizes, algorithm, debian bug or heart bleed reissue, Š, all the topics,
which recently arised), for pinning validated (EV) certificates, it¹s the
best solution vs. pinning or transparency.

>Not relying on a CA is a good thing since its usually advantageous to
>minimize trust (for some definition of "trust"). Plus, CAs don¹t really
>warrant anything, so its not clear what exactly they are providing to
>relying parties (they are providing a a signature for money to the
>applicant).

As there is not internet governance, they are the only available
alternative. Similar to other agencies existing worldwide, they fetch
money for validation services and warrant for mis-validation. They are
dictated strict rules on how to do and be audited to proof, they follow
this rules. That¹s how auditing currently works in many places and
although it¹s not the optimal system, it¹s the one currently available.

>Open question: do you think the browsers will support a model other than
>the CA Zoo for rooting trust?

If a reliable, usable and manageable concept will be established, for
sure. But as e.g. ISO 27001 establish the same model, there is a company
being paid for stating what they audited is correct and issuing a seal
(being ISO 27001 certified) which end users should trust in.

_______________________________________________
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

Ryan Sleevi-2
On Mon, Dec 15, 2014 at 5:11 PM, Christian Heutger <[hidden email]>
wrote:

>
> >Surely you haven't missed the big danger in plain text traffic. That
> >traffic gets usuroed and fed into susyems like Xkeyscore for Tailored
> >Access Operations (TAO). In layman's terms, adversaries are using the
> >information gathered to gain unauthorized access to systems.
>
> With DV (weak validation) it then goes encrypted to them, I don¹t see the
> advantage. The magic bullet TOR to prevent from being monitored also
> showed up, that the expected privacy may be broken. It¹s a good idea but
> therefor stepping back from the value of PKIX is the wrong way in my
> opinion.
>
> >The race to the bottom among CAs is to blame for the quality of
> >verification by the CAs.
>
> Right, so DV need to be deprecated or set to a recognizable lower level,
> clearly stating that it¹s only encryption, nothing else.
>
> >With companies like StartCom, Cacert and Mozilla offering free
> >certificates, there is no barrier to entry.
>
> And no barrier breaking the value of certificate authorities vs.
> self-signed certificates (Cacert is the only good exception, for a good
> reason their approach is different).
>
> >Plus, I don't think a certificate needs to say anything about the
> >operator. They need to ensure the server is authenticated. That is, the
> >public key bound to the DNS name is authentic.
>
> If a certificate doesn¹t tell, what should tell? How should I be sure to
> be on www.onlinebanking.de and not www.onlínebanking.de
> <http://www.xn--onlnebanking-ufb.de> (see the accent)
> by getting spoofed or phished? It¹s the same for Facebook.com or
> Facebo0k.com, ...
>
> >As I understand it, phishers try to avoid TLS because they count on the
> >plain text channel to avoid all the browser warnings. Peter Gutmann
> >discusses this in his Engineering Security book
> >(https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf).
>
> If there is a free certificate for everyone and everything is https, which
> browser warnings should occur?
>
> >Why green for EV (or why yellow for DV or DANE)? EV does not add any
> >technical controls. From a security standpoint, DV and EV are equivalent.
>
> That¹s what certificates are for. If we only would want to have
> encryption, there would never be any requirement for certificates.
> Browsers and servers handle cipher suites, handshakes etc., the
> certificate is the digital equivalent to an authorized identity card, and
> there for sure DV and EV are different. Security is about confidentiality,
> integrity and availability. Confidentiality is the encryption, integrity
> is the validation.
>
> >If DNS is authentic, then DANE provides stronger assurances than DV or EV
> >since the domain operator published the information and the veracity does
> >not rely on others like CAs (modulo DBOUND).
>
> From the pure technical standpoint, yes, from the validation standpoint,
> no. DANE has the hazel of compatibility, but it also struggle with harder
> mandatory realization of restrictions (online or offline key material, key
> sizes, algorithm, debian bug or heart bleed reissue, Š, all the topics,
> which recently arised), for pinning validated (EV) certificates, it¹s the
> best solution vs. pinning or transparency.
>
> >Not relying on a CA is a good thing since its usually advantageous to
> >minimize trust (for some definition of "trust"). Plus, CAs don¹t really
> >warrant anything, so its not clear what exactly they are providing to
> >relying parties (they are providing a a signature for money to the
> >applicant).
>
> As there is not internet governance, they are the only available
> alternative. Similar to other agencies existing worldwide, they fetch
> money for validation services and warrant for mis-validation. They are
> dictated strict rules on how to do and be audited to proof, they follow
> this rules. That¹s how auditing currently works in many places and
> although it¹s not the optimal system, it¹s the one currently available.
>
> >Open question: do you think the browsers will support a model other than
> >the CA Zoo for rooting trust?
>
> If a reliable, usable and manageable concept will be established, for
> sure. But as e.g. ISO 27001 establish the same model, there is a company
> being paid for stating what they audited is correct and issuing a seal
> (being ISO 27001 certified) which end users should trust in.
>
>
There's a lot of information here that isn't quite correct, but I would
hate to rathole on a discussion of CA security vs the alternatives, which
inevitably arises when one discusses HTTPS in public fora.

I think the discussion here is somewhat orthogonal to the proposal at hand,
and thus might be best if kept to a separate thread.

The question of whether HTTP is equivalent to HTTPS-DV in security or
authenticity is simple - they aren't at all equivalent, an HTTPS-DV
provides vastly superior value over HTTP. So whether or not UAs embrace
HTTPS-EV is separate. But as a UA vendor, I would say HTTPS-DV has far more
appeal for protecting users and providing security than HTTPS-EV, for many
of the reasons you've heard on this thread from others (e.g. the challenges
regarding mixed HTTPS+HTTP is the same as HTTPS-EV + HTTPS-DV).

So, assuming we have HTTP vs HTTPS-EV/HTTPS-DV, how best should UAs
communicate to the user the lack of security guarantees from HTTP.
_______________________________________________
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
> So, assuming we have HTTP vs HTTPS-EV/HTTPS-DV, how best should UAs communicate to the user the lack of security guarantees from HTTP.

I would recommend here as mentioned:

No padlock, red bar or red strike, … => no encryption [and no validation], e.g. similar to SHA1 deprecation in worst situation
Only vs. HTTPS: Padlock => everything fine and not red, „normal“ address bar behavior
With EV differentiation: Padlock, yellow bar, yellow signal, … => only encryption, e.g. similar to current mixed content, …
EV: Validation information, Padlock green bar, no extras, … => similar to current EV

Red-Yellow-Green is recognized all other the world, all traffic signals are like this, explanation on what signal means what can be added to the dialog on click. (Red) strike, (yellow) signal, (green) additional validation information follow also the idea to have people without been able to differentiate colors to understand what happens here.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [blink-dev] Re: Proposal: Marking HTTP As Non-Secure

Peter Kasting
On Mon, Dec 15, 2014 at 5:50 PM, Christian Heutger <[hidden email]>
wrote:

>
>   > So, assuming we have HTTP vs HTTPS-EV/HTTPS-DV, how best should UAs
> communicate to the user the lack of security guarantees from HTTP.
>
>  I would recommend here as mentioned:
>
>  No padlock, red bar or red strike, … => no encryption [and no
> validation], e.g. similar to SHA1 deprecation in worst situation
> Only vs. HTTPS: Padlock => everything fine and not red, „normal“ address
> bar behavior
> With EV differentiation: Padlock, yellow bar, yellow signal, … => only
> encryption, e.g. similar to current mixed content, …
> EV: Validation information, Padlock green bar, no extras, … => similar to
> current EV
>
>  Red-Yellow-Green is recognized all other the world, all traffic signals
> are like this, explanation on what signal means what can be added to the
> dialog on click. (Red) strike, (yellow) signal, (green) additional
> validation information follow also the idea to have people without been
> able to differentiate colors to understand what happens here.
>

Please don't try to debate actual presentation ideas on this list.  How UAs
present various states is something the individual UA's design teams have
much more context and experience doing, so debating that sort of thing here
just takes everyone's time to no benefit, and is likely to rapidly become a
bikeshed in any case.

As the very first message in the thread states, the precise UX changes here
are up to the UA vendors.  What's more useful is to debate the concept of
displaying non-secure origins as non-secure, and how to transition to that
state over time.

PK
_______________________________________________
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 Daniel Veditz-2
On 15 December 2014 at 18:54, Daniel Veditz <[hidden email]> wrote:

> Serve the HTML page over http: but load all sub-resources over https: as
> expected after the transition. Add the following header:
>
> Content-Security-Policy-Report-Only: default-src https:; report-uri <me>
>

This is a nice trick! However, it does not work in general due to the use
of protocolless-links starting with // . Or should those be discouraged?
_______________________________________________
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

Ryan Sleevi-2
On Mon, Dec 15, 2014 at 9:29 PM, Igor Bukanov <[hidden email]> wrote:

>
> On 15 December 2014 at 18:54, Daniel Veditz <[hidden email]> wrote:
>
>> Serve the HTML page over http: but load all sub-resources over https: as
>> expected after the transition. Add the following header:
>>
>> Content-Security-Policy-Report-Only: default-src https:; report-uri <me>
>>
>
> This is a nice trick! However, it does not work in general due to the use
> of protocolless-links starting with // . Or should those be discouraged?
>
>
Sounds like a CSP-bug to me; scheme-relative URLs are awesome, and we
should encourage them (over explicit http://-schemed URLs)
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
123456 ... 12