Proposal: Marking HTTP As Non-Secure

classic Classic list List threaded Threaded
228 messages Options
1234 ... 12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal: Marking HTTP As Non-Secure

Chris Palmer
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
|  
Report Content as Inappropriate

Re: Proposal: Marking HTTP As Non-Secure

Eduardo Robles Elvira
Hello Chris et al:

I'm a web developer. I did some vendor security-related development
sometime ago inside Konqueror. Some first thoughts:

* In principle, the proposal makes sense to me. Who doesn't want a more
secure web? Kudos for making it possible with ambitious proposals like this.

* The biggest problem I see is that to get an accepted certificate
traditionally you needed to pay. This was a show-stopper for having TLS
certs in small websites. Mozilla, EFF, Cisco, Akamai are trying to fix that
[1] and that StartSSL gives free certificates though. Just stating the
obvious: you either get easy and free "secure" certificates, or this
proposal is going to make some webmasters angry.


Regards,
--
[1]
https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web
--
Eduardo Robles Elvira     @edulix             skype: edulix2
http://agoravoting.org       @agoravoting     +34 634 571 634

On Sat, Dec 13, 2014 at 1:46 AM, Chris Palmer <[hidden email]> 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
|  
Report Content as Inappropriate

Re: Proposal: Marking HTTP As Non-Secure

Chris Palmer
On Fri, Dec 12, 2014 at 5:17 PM, Eduardo Robles Elvira <
[hidden email]> wrote:

* The biggest problem I see is that to get an accepted certificate
> traditionally you needed to pay. This was a show-stopper for having TLS
> certs in small websites. Mozilla, EFF, Cisco, Akamai are trying to fix that
> [1] and that StartSSL gives free certificates though. Just stating the
> obvious: you either get easy and free "secure" certificates, or this
> proposal is going to make some webmasters angry.
>
>>
Oh yes, absolutely. Obviously, Let's Encrypt is a great help, and SSLMate's
ease-of-use and low price is great, and CloudFlare's free SSL helps too.

Hopefully, as operations like those ramp up, it will get increasingly
easier for web developers to switch to HTTPS. We (Chrome) will weigh
changes to the UX very carefully, and with a close eye on HTTPS adoption.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Marking HTTP As Non-Secure

Alex Gaynor
In reply to this post by Chris Palmer
Fantastic news, I'm very glad to see the Chrome Security Team taking
initiative on this.

Existing browsers' behavior of defaulting to, and using a "neutral" UI for,
HTTP is fundamentally an assumption what users want. And it's not an
assumption that is grounded in data.

No ordinary users' mental for communication on the net includes lack of
authenticity, integrity, or confidentially. Plaintext is a blight on the
internet, and this is a fantastic step towards making reality match users
(TOTALLY REASONABLE!) expectations.

Cheers,
Alex

On Fri Dec 12 2014 at 4:46:36 PM 'Chris Palmer' via Security-dev <
[hidden email]> 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
|  
Report Content as Inappropriate

Re: Proposal: Marking HTTP As Non-Secure

Igor Bukanov-2
In reply to this post by Chris Palmer
Free SSL certificates helps, but another problem is that activating SSL not
only generates warnings, but just break the site due to links to insecure
resources. Just consider a case of old pages with a few youtube videos
served using http iframes. Accessing those pages over https stops the
videos from working as browsers blocks access to active insecure context.
And in case of youtube one can fix that, but for other resources it may not
be possible.

So what is required is ability to refer to insecure context from HTTPS
pages without harming user experience. For example, it should be a way to
insert http iframe into https site. Similarly, it would be nice if a
web-developer could refer to scripts, images etc. over http as long as the
script/image tag is accompanied with a secure hash of known context.

On 13 December 2014 at 02:32, Chris Palmer <[hidden email]> wrote:

>
> On Fri, Dec 12, 2014 at 5:17 PM, Eduardo Robles Elvira <
> [hidden email]> wrote:
>
> * The biggest problem I see is that to get an accepted certificate
> > traditionally you needed to pay. This was a show-stopper for having TLS
> > certs in small websites. Mozilla, EFF, Cisco, Akamai are trying to fix
> that
> > [1] and that StartSSL gives free certificates though. Just stating the
> > obvious: you either get easy and free "secure" certificates, or this
> > proposal is going to make some webmasters angry.
> >
> >>
> Oh yes, absolutely. Obviously, Let's Encrypt is a great help, and SSLMate's
> ease-of-use and low price is great, and CloudFlare's free SSL helps too.
>
> Hopefully, as operations like those ramp up, it will get increasingly
> easier for web developers to switch to HTTPS. We (Chrome) will weigh
> changes to the UX very carefully, and with a close eye on HTTPS adoption.
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mathias Bynens
In reply to this post by Chris Palmer
On Sat, Dec 13, 2014 at 1:46 AM, 'Chris Palmer' via blink-dev <
[hidden email]> wrote:

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

For completeness sake, here’s what a non-secure looks like in Opera:
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Marking HTTP As Non-Secure

Richard Barnes
In reply to this post by Chris Palmer
[limiting to dev.security to minimize cross-posting]

Hey Chris,

Thanks for putting together a good case for this idea.  I think there's a fair degree of interest in this on the Mozilla side.  A couple of comments:

The really critical question for me here is the timeline.  It's pretty much out of the question to deploy an indicator like this today, because it would appear so often.  That's why we're so enthusiastic about things like Let's Encrypt -- to get us to the threshold where there's enough TLS that we can be harder on non-secure sites.  So my preference would be for something like the percentage-based ratchet you describe.

I wonder to what degree this is about transport vs. scheme.  Of course, in HTTP/1.1, the only way you get TLS is with HTTPS.  In HTTP/2, however, the full URL is carried in the request, so HTTP-schemed requests can be sent over TLS connections.  Putting aside for the moment the questions of how they would get there and whether unauthenticated TLS is allowed, suppose a page was requested with an HTTP scheme, but the request went over an authenticated TLS connection.  So it would get all the same COMSEC benefits as HTTPS, just not things like mixed content blocking and referer stripping.  How does that fit into your scheme?  It seems like it could be a useful distinction to make to allow sites to upgrade transports without having to change content.

Thanks again,
--Richard





> On Dec 12, 2014, at 7:46 PM, Chris Palmer <[hidden email]> 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

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

Re: Proposal: Marking HTTP As Non-Secure

ianG-2
In reply to this post by Chris Palmer
On 13/12/2014 00:46 am, 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.


What is your proposal for HTTPS self-signed and HTTPS unknown-CA?  Is
this considered less secure than HTTP or is it considered more secure
than HTTP but less than HTTPS?

Are you also considering ways to get more servers up and running with
certs for zero cost?



iang

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

Re: Proposal: Marking HTTP As Non-Secure

Daniel Veditz-2
On 12/13/14 10:15 AM, ianG wrote:
> Are you also considering ways to get more servers up and running with
> certs for zero cost?

You apparently missed this: https://letsencrypt.org/

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

Re: Proposal: Marking HTTP As Non-Secure

ianG-2
On 14/12/2014 05:37 am, Daniel Veditz wrote:
> On 12/13/14 10:15 AM, ianG wrote:
>> Are you also considering ways to get more servers up and running with
>> certs for zero cost?
>
> You apparently missed this: https://letsencrypt.org/


I didn't miss it -- I wondered what Chrome team's plan was...

If that is "the plan" then they should say that!  Then we can respond to it.



iang

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

Re: Proposal: Marking HTTP As Non-Secure

Michael Ströder
In reply to this post by Chris Palmer
Eduardo Robles Elvira wrote:
> * The biggest problem I see is that to get an accepted certificate
> traditionally you needed to pay. This was a show-stopper for having TLS
> certs in small websites. Mozilla, EFF, Cisco, Akamai are trying to fix that
> [1] and that StartSSL gives free certificates though. Just stating the
> obvious: you either get easy and free "secure" certificates, or this
> proposal is going to make some webmasters angry.

It's not only getting certificates. It's also getting the cert installed. Note
that the majority of web content is not hosted on separate servers maintained
by admins. So "Let's Encrypt" won't help either.

That does not mean that I'm against this proposal. It might give a strong push
into the right direction.

Ciao, Michael.

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

Re: Proposal: Marking HTTP As Non-Secure

Chris Palmer
In reply to this post by Igor Bukanov-2
On Sat, Dec 13, 2014 at 8:56 AM, Igor Bukanov <[hidden email]> wrote:

Free SSL certificates helps, but another problem is that activating SSL not
> only generates warnings, but just break the site due to links to insecure
> resources. Just consider a case of old pages with a few youtube videos
> served using http iframes. Accessing those pages over https stops the
> videos from working as browsers blocks access to active insecure context.
> And in case of youtube one can fix that, but for other resources it may not
> be possible.
>

Yes, unfortunately we have a collective action problem. (
http://en.wikipedia.org/wiki/Collective_action#Collective_action_problem)
But just because it's hard, doesn't mean we don't have try. I'd suggest
that embedders ask embeddees to at least make HTTPS available, even if not
the default.

Also, keep in mind that this proposal is only to mark HTTP as non-secure —
HTTP will still work, and you can still host your site over HTTP.


> So what is required is ability to refer to insecure context from HTTPS
> pages without harming user experience.
>

No, because that reduces or eliminates the security guarantee of HTTPS.


> For example, it should be a way to insert http iframe into https site.
> Similarly, it would be nice if a web-developer could refer to scripts,
> images etc. over http as long as the script/image tag is accompanied with a
> secure hash of known context.
>

Same thing here. The security guarantee of HTTPS is the combination of
server authentication, data integrity, and data confidentiality. It is not
a good user experience to take away confidentiality without telling users.
And, unfortunately, we cannot effectively communicate that nuance. We have
enough trouble effectively communicating the secure/non-secure distinction
as it is.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Marking HTTP As Non-Secure

Alex Gaynor
Chris,

Is there a plan for HTTP to eventually have an interstitial, the way HTTPS
with a bogus cert does?

Alex

On Sun Dec 14 2014 at 9:59:22 AM 'Chris Palmer' via Security-dev <
[hidden email]> wrote:

> On Sat, Dec 13, 2014 at 8:56 AM, Igor Bukanov <[hidden email]> wrote:
>
> Free SSL certificates helps, but another problem is that activating SSL
>> not only generates warnings, but just break the site due to links to
>> insecure resources. Just consider a case of old pages with a few youtube
>> videos served using http iframes. Accessing those pages over https stops
>> the videos from working as browsers blocks access to active insecure
>> context. And in case of youtube one can fix that, but for other resources
>> it may not be possible.
>>
>
> Yes, unfortunately we have a collective action problem. (
> http://en.wikipedia.org/wiki/Collective_action#Collective_action_problem)
> But just because it's hard, doesn't mean we don't have try. I'd suggest
> that embedders ask embeddees to at least make HTTPS available, even if not
> the default.
>
> Also, keep in mind that this proposal is only to mark HTTP as non-secure —
> HTTP will still work, and you can still host your site over HTTP.
>
>
>> So what is required is ability to refer to insecure context from HTTPS
>> pages without harming user experience.
>>
>
> No, because that reduces or eliminates the security guarantee of HTTPS.
>
>
>> For example, it should be a way to insert http iframe into https site.
>> Similarly, it would be nice if a web-developer could refer to scripts,
>> images etc. over http as long as the script/image tag is accompanied with a
>> secure hash of known context.
>>
>
> Same thing here. The security guarantee of HTTPS is the combination of
> server authentication, data integrity, and data confidentiality. It is not
> a good user experience to take away confidentiality without telling users.
> And, unfortunately, we cannot effectively communicate that nuance. We have
> enough trouble effectively communicating the secure/non-secure distinction
> as it is.
>
> 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
|  
Report Content as Inappropriate

Re: Proposal: Marking HTTP As Non-Secure

Chris Palmer
In reply to this post by Richard Barnes
On Sat, Dec 13, 2014 at 10:07 AM, Richard Barnes <[hidden email]>
wrote:

The really critical question for me here is the timeline.  It's pretty much
> out of the question to deploy an indicator like this today, because it
> would appear so often.  That's why we're so enthusiastic about things like
> Let's Encrypt -- to get us to the threshold where there's enough TLS that
> we can be harder on non-secure sites.  So my preference would be for
> something like the percentage-based ratchet you describe.
>

We are thinking the same thing, yeah.


> I wonder to what degree this is about transport vs. scheme.  Of course, in
> HTTP/1.1, the only way you get TLS is with HTTPS.  In HTTP/2, however, the
> full URL is carried in the request, so HTTP-schemed requests can be sent
> over TLS connections.  Putting aside for the moment the questions of how
> they would get there and whether unauthenticated TLS is allowed, suppose a
> page was requested with an HTTP scheme, but the request went over an
> authenticated TLS connection.  So it would get all the same COMSEC benefits
> as HTTPS, just not things like mixed content blocking and referer
> stripping.  How does that fit into your scheme?  It seems like it could be
> a useful distinction to make to allow sites to upgrade transports without
> having to change content.
>

What matters is the security isolation status of the *origin*. If the
origin is (HTTP, example.com, 80), and there is some hypothetical
STARTTLS-like upgrade to TLS, that's nice. But the origin is still (HTTP,
example.com, 80), and non-securely-transported script could still execute
in the same context.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Marking HTTP As Non-Secure

Chris Palmer
In reply to this post by ianG-2
On Sat, Dec 13, 2014 at 10:15 AM, ianG <[hidden email]> wrote:

What is your proposal for HTTPS self-signed and HTTPS unknown-CA?  Is this
> considered less secure than HTTP or is it considered more secure than HTTP
> but less than HTTPS?
>

We are not proposing a change to the status quo for these scenarios.

The only way to make self-signed or unknown issuer certificates even barely
acceptable is to pin their keys on first use. But then you have to explain
to hundreds of millions of people how to recover when the keys change, and
how to distinguish legitimate key change from illegitimate. I don't think
we know how to do that yet.

Are you also considering ways to get more servers up and running with certs
> for zero cost?
> <https://lists.mozilla.org/listinfo/dev-security>
>

Yes, of course. But we have nothing to announce on that front just yet.

In the meantime, there is:

* CloudFlare
* SSLMate
* Let's Encrypt coming soon
* Non-custom-domain hosting like appspot.com and github.io
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Marking HTTP As Non-Secure

Chris Palmer
In reply to this post by Chris Palmer
On Sat, Dec 13, 2014 at 11:05 AM, Christian Heutger <[hidden email]>
wrote:

 I see a big danger in the current trend. 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.
>

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.


> They ensure encryption, so I can then be phished, be scammed, … encrypted.
> Big advantage!^^ 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.
>

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

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.

Additionally, the web origin concept is (scheme, host, port). Crucially,
EV-issued names are not distinct origins from DV-issued names, and
proposals to enforce such a distinction in browsers have not gotten any
traction because they are not super feasible (for a variety of reasons).


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

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.

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

Re: Proposal: Marking HTTP As Non-Secure

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

It's not only getting certificates. It's also getting the cert installed.
> Note
> that the majority of web content is not hosted on separate servers
> maintained
> by admins. So "Let's Encrypt" won't help either.
>

It's true that getting a certificate, and then installing it, are 2
separate problems. But it's not accurate to say that helping solve only 1
of the 2 problems does not help. It does help.

If your hosting provider doesn't have a way for you to install your
certificate for your site, file a bug with them. It's a problem they should
fix (e.g. hosted WordPress). I expect the availability of that feature will
be a market differentiator in the short term...
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Marking HTTP As Non-Secure

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

>
> Yes, unfortunately we have a collective action problem. (
> http://en.wikipedia.org/wiki/Collective_action#Collective_action_problem)
> But just because it's hard, doesn't mean we don't have try. I'd suggest
> that embedders ask embeddees to at least make HTTPS available, even if not
> the default.
>
> Also, keep in mind that this proposal is only to mark HTTP as non-secure —
> HTTP will still work, and you can still host your site over HTTP.
>

If serving context over HTTPS generates broken pages, the insensitive of
enabling encryption is very low. 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.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Marking HTTP As Non-Secure

Chris Palmer
In reply to this post by Alex Gaynor
On Sun, Dec 14, 2014 at 10:00 AM, Alex Gaynor <[hidden email]> wrote:

Is there a plan for HTTP to eventually have an interstitial, the way HTTPS
> with a bogus cert does?


We (Chrome) have no current plan to do that. In the Beautiful Future when
some huge percentage of pageviews are shown via secure transport, it might
or might not make sense to interstitial HTTP then. I kind of doubt that it
will be a good idea, but who knows. We'll see.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 8:02 AM, Michael Ströder <[hidden email]>
> wrote:
>> It's not only getting certificates. It's also getting the cert
>> installed. Note that the majority of web content is not hosted on
>> separate servers maintained by admins. So "Let's Encrypt" won't help
>> either.
>
> It's true that getting a certificate, and then installing it, are 2
> separate problems. But it's not accurate to say that helping solve only 1
> of the 2 problems does not help.

I did *not* say solving 1 of 2 does not help. I just said there is also a 2.
major problem to be solved.

> If your hosting provider doesn't have a way for you to install your
> certificate for your site, file a bug with them. It's a problem they should
> fix (e.g. hosted WordPress).

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.

> I expect the availability of that feature will
> be a market differentiator in the short term...

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

Ciao, Michael.

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