Re: Basic Auth Prevalence (was Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies)

[Chris H-C]

I concur. 1 in every 12 loads require an HTTP auth prompt? Seems very high.
Visual inspection of the probe implementations [1] [2] show no obvious
faults, so I'm not sure what's going on here.

[1]
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannelAuthProvider.cpp#782
[2]
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpChannel.cpp#1608

On Mon, Jun 13, 2016 at 7:22 AM, David Burns  wrote:

> Is there a way that we can gather if people are using this for testing web
> sites? This might account for those numbers.
>
> For example, there is basic support, and I mean really basic support, in
> Selenium to handle Basic auth and we suggest to people that setting up a
> proxy in the middle to handle that handshake. I suspect in these cases
> people won't have all the necessary security setup if it is behind some
> kind of firewall. Just a thought.
>
> David
>
> On 11 June 2016 at 03:27, Jason Duell  wrote:
>
> > This data also smells weird to me.  8% of pages using basic auth seems
> very
> > very high, and only 0.7% of basic auth being done unencypted seems low.
> >
> > Perhaps we should chat in London (ideally with Honza Bambas) and make
> sure
> > we're getting the telemetry right here.
> >
> > Jason
> >
> > On Fri, Jun 10, 2016 at 2:15 PM, Adam Roach  wrote:
> >
> > > On 4/18/16 09:59, Richard Barnes wrote:
> > >
> > >> Could we just disable HTTP auth for connections not protected with
> TLS?
> > >> At
> > >> least Basic auth is manifestly insecure over an insecure transport.  I
> > >> don't have any usage statistics, but I suspect it's pretty low
> compared
> > to
> > >> form-based auth.
> > >>
> > >
> > > As a follow up from this: we added telemetry to answer the exact
> question
> > > about how prevalent Basic auth over non-TLS connections was. Now that
> 49
> > is
> > > off Nightly, I pulled the stats for our new little counter.
> > >
> > > It would appear telemetry was enabled for approximately 109M page
> > > loads[1], of which approximately 8.7M[2] used HTTP auth -- or
> > approximately
> > > 8% of all pages. (This is much higher than I expected -- approximately
> 1
> > > out of 12 page loads uses HTTP auth? It seems far less dead than we
> > > anticipated).
> > >
> > > 749k of those were unencrypted basic auth[2]; this constitutes
> > > approximately 0.7% of all recorded traffic.
> > >
> > > I'll look at the 49 Aurora stats when it has enough data -- it'll be
> > > interesting to see how much if it is nontrivially different.
> > >
> > > /a
> > >
> > >
> > > [1]
> > >
> >
> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2016-06-06=__none__!__none__!__none___channel_version=nightly%252F49=HTTP_PAGELOAD_IS_SSL_channel_version=null=Firefox=1_keys=submissions_date=2016-05-04=0=1_submission_date=0
> > >
> > > [2]
> > >
> >
> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2016-06-06=__none__!__none__!__none___channel_version=nightly%252F49=HTTP_AUTH_TYPE_STATS_channel_version=null=Firefox=1_keys=submissions_date=2016-05-04=0=1_submission_date=0
> > >
> > >
> > > --
> > > Adam Roach
> > > Principal Platform Engineer
> > > Office of the CTO
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-platform
> > >
> >
> >
> >
> > --
> >
> > Jason
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Basic Auth Prevalence (was Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies)

[David Burns]

Is there a way that we can gather if people are using this for testing web
sites? This might account for those numbers.

For example, there is basic support, and I mean really basic support, in
Selenium to handle Basic auth and we suggest to people that setting up a
proxy in the middle to handle that handshake. I suspect in these cases
people won't have all the necessary security setup if it is behind some
kind of firewall. Just a thought.

David

On 11 June 2016 at 03:27, Jason Duell  wrote:

> This data also smells weird to me.  8% of pages using basic auth seems very
> very high, and only 0.7% of basic auth being done unencypted seems low.
>
> Perhaps we should chat in London (ideally with Honza Bambas) and make sure
> we're getting the telemetry right here.
>
> Jason
>
> On Fri, Jun 10, 2016 at 2:15 PM, Adam Roach  wrote:
>
> > On 4/18/16 09:59, Richard Barnes wrote:
> >
> >> Could we just disable HTTP auth for connections not protected with TLS?
> >> At
> >> least Basic auth is manifestly insecure over an insecure transport.  I
> >> don't have any usage statistics, but I suspect it's pretty low compared
> to
> >> form-based auth.
> >>
> >
> > As a follow up from this: we added telemetry to answer the exact question
> > about how prevalent Basic auth over non-TLS connections was. Now that 49
> is
> > off Nightly, I pulled the stats for our new little counter.
> >
> > It would appear telemetry was enabled for approximately 109M page
> > loads[1], of which approximately 8.7M[2] used HTTP auth -- or
> approximately
> > 8% of all pages. (This is much higher than I expected -- approximately 1
> > out of 12 page loads uses HTTP auth? It seems far less dead than we
> > anticipated).
> >
> > 749k of those were unencrypted basic auth[2]; this constitutes
> > approximately 0.7% of all recorded traffic.
> >
> > I'll look at the 49 Aurora stats when it has enough data -- it'll be
> > interesting to see how much if it is nontrivially different.
> >
> > /a
> >
> >
> > [1]
> >
> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2016-06-06=__none__!__none__!__none___channel_version=nightly%252F49=HTTP_PAGELOAD_IS_SSL_channel_version=null=Firefox=1_keys=submissions_date=2016-05-04=0=1_submission_date=0
> >
> > [2]
> >
> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2016-06-06=__none__!__none__!__none___channel_version=nightly%252F49=HTTP_AUTH_TYPE_STATS_channel_version=null=Firefox=1_keys=submissions_date=2016-05-04=0=1_submission_date=0
> >
> >
> > --
> > Adam Roach
> > Principal Platform Engineer
> > Office of the CTO
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
>
>
>
> --
>
> Jason
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Basic Auth Prevalence (was Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies)

[Gijs Kruitbosch]

On 11/06/2016 03:27, Jason Duell wrote:

This data also smells weird to me.  8% of pages using basic auth seems very
very high, and only 0.7% of basic auth being done unencypted seems low.


Nitpick: it's 0.7% of total traffic - 749k / 8.7 million ~> 8.6% of 
basic auth is over unencrypted connections.


~ Gijs



Perhaps we should chat in London (ideally with Honza Bambas) and make sure
we're getting the telemetry right here.

Jason

On Fri, Jun 10, 2016 at 2:15 PM, Adam Roach  wrote:


On 4/18/16 09:59, Richard Barnes wrote:


Could we just disable HTTP auth for connections not protected with TLS?
At
least Basic auth is manifestly insecure over an insecure transport.  I
don't have any usage statistics, but I suspect it's pretty low compared to
form-based auth.



As a follow up from this: we added telemetry to answer the exact question
about how prevalent Basic auth over non-TLS connections was. Now that 49 is
off Nightly, I pulled the stats for our new little counter.

It would appear telemetry was enabled for approximately 109M page
loads[1], of which approximately 8.7M[2] used HTTP auth -- or approximately
8% of all pages. (This is much higher than I expected -- approximately 1
out of 12 page loads uses HTTP auth? It seems far less dead than we
anticipated).

749k of those were unencrypted basic auth[2]; this constitutes
approximately 0.7% of all recorded traffic.

I'll look at the 49 Aurora stats when it has enough data -- it'll be
interesting to see how much if it is nontrivially different.

/a


[1]
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2016-06-06=__none__!__none__!__none___channel_version=nightly%252F49=HTTP_PAGELOAD_IS_SSL_channel_version=null=Firefox=1_keys=submissions_date=2016-05-04=0=1_submission_date=0

[2]
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2016-06-06=__none__!__none__!__none___channel_version=nightly%252F49=HTTP_AUTH_TYPE_STATS_channel_version=null=Firefox=1_keys=submissions_date=2016-05-04=0=1_submission_date=0


--
Adam Roach
Principal Platform Engineer
Office of the CTO
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform







___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Basic Auth Prevalence (was Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies)

[Jason Duell]

This data also smells weird to me.  8% of pages using basic auth seems very
very high, and only 0.7% of basic auth being done unencypted seems low.

Perhaps we should chat in London (ideally with Honza Bambas) and make sure
we're getting the telemetry right here.

Jason

On Fri, Jun 10, 2016 at 2:15 PM, Adam Roach  wrote:

> On 4/18/16 09:59, Richard Barnes wrote:
>
>> Could we just disable HTTP auth for connections not protected with TLS?
>> At
>> least Basic auth is manifestly insecure over an insecure transport.  I
>> don't have any usage statistics, but I suspect it's pretty low compared to
>> form-based auth.
>>
>
> As a follow up from this: we added telemetry to answer the exact question
> about how prevalent Basic auth over non-TLS connections was. Now that 49 is
> off Nightly, I pulled the stats for our new little counter.
>
> It would appear telemetry was enabled for approximately 109M page
> loads[1], of which approximately 8.7M[2] used HTTP auth -- or approximately
> 8% of all pages. (This is much higher than I expected -- approximately 1
> out of 12 page loads uses HTTP auth? It seems far less dead than we
> anticipated).
>
> 749k of those were unencrypted basic auth[2]; this constitutes
> approximately 0.7% of all recorded traffic.
>
> I'll look at the 49 Aurora stats when it has enough data -- it'll be
> interesting to see how much if it is nontrivially different.
>
> /a
>
>
> [1]
> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2016-06-06=__none__!__none__!__none___channel_version=nightly%252F49=HTTP_PAGELOAD_IS_SSL_channel_version=null=Firefox=1_keys=submissions_date=2016-05-04=0=1_submission_date=0
>
> [2]
> https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2016-06-06=__none__!__none__!__none___channel_version=nightly%252F49=HTTP_AUTH_TYPE_STATS_channel_version=null=Firefox=1_keys=submissions_date=2016-05-04=0=1_submission_date=0
>
>
> --
> Adam Roach
> Principal Platform Engineer
> Office of the CTO
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Jason
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Basic Auth Prevalence (was Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies)

[Adam Roach]

On 4/18/16 09:59, Richard Barnes wrote:

Could we just disable HTTP auth for connections not protected with TLS?  At
least Basic auth is manifestly insecure over an insecure transport.  I
don't have any usage statistics, but I suspect it's pretty low compared to
form-based auth.


As a follow up from this: we added telemetry to answer the exact 
question about how prevalent Basic auth over non-TLS connections was. 
Now that 49 is off Nightly, I pulled the stats for our new little counter.


It would appear telemetry was enabled for approximately 109M page 
loads[1], of which approximately 8.7M[2] used HTTP auth -- or 
approximately 8% of all pages. (This is much higher than I expected -- 
approximately 1 out of 12 page loads uses HTTP auth? It seems far less 
dead than we anticipated).


749k of those were unencrypted basic auth[2]; this constitutes 
approximately 0.7% of all recorded traffic.


I'll look at the 49 Aurora stats when it has enough data -- it'll be 
interesting to see how much if it is nontrivially different.


/a


[1] 
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2016-06-06=__none__!__none__!__none___channel_version=nightly%252F49=HTTP_PAGELOAD_IS_SSL_channel_version=null=Firefox=1_keys=submissions_date=2016-05-04=0=1_submission_date=0


[2] 
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0_date=2016-06-06=__none__!__none__!__none___channel_version=nightly%252F49=HTTP_AUTH_TYPE_STATS_channel_version=null=Firefox=1_keys=submissions_date=2016-05-04=0=1_submission_date=0 




--
Adam Roach
Principal Platform Engineer
Office of the CTO
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

On 4/19/16 1:58 AM, Panos Astithas wrote:

Why should we be the ones to take the web compat hit on this?

>
> is the fundamentally biggest issue.
>

I realize I'm late to this thread and the discussion has moved the original
proposal towards something more refined and hence more likely to succeed,
but I'd still like to make a case for this tradeoff:

We should be the ones doing this, because we want to be known as the most
secure, most private browser.

This is isn't an easy position to reach or maintain. It's not as clear-cut
as the fastest browser, or the less memory-demanding browser, but it is one
we have identified as holding a competitive advantage for.


The challenge is that users experience broken websites (web compat) 
firsthand, but privacy and security are invisible.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Panos Astithas]

On Fri, Apr 15, 2016 at 5:47 PM, Tantek Çelik 
wrote:

> However, As EKR pointed out, Kyle Huey's
>
> > Why should we be the ones to take the web compat hit on this?
>
> is the fundamentally biggest issue.
>

I realize I'm late to this thread and the discussion has moved the original
proposal towards something more refined and hence more likely to succeed,
but I'd still like to make a case for this tradeoff:

We should be the ones doing this, because we want to be known as the most
secure, most private browser.

This is isn't an easy position to reach or maintain. It's not as clear-cut
as the fastest browser, or the less memory-demanding browser, but it is one
we have identified as holding a competitive advantage for. Security and
privacy impact usability, that is a well-known fact, otherwise we'd all be
using Tor by now. So let's iterate on this or other similar proposals,
let's ship them off by default, let's provide great onboarding experiences,
documentation, whatever it takes, but let's not shy away from even trying.
Because what other path has a better chance to help us get to where we want
to be?

Thanks,
Panos
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Matthew N.]

On 2016-04-18 7:59 AM, Richard Barnes wrote:

Could we just disable HTTP auth for connections not protected with TLS?  At
least Basic auth is manifestly insecure over an insecure transport.  I
don't have any usage statistics, but I suspect it's pretty low compared to
form-based auth.


I also don't have data but I suspect that would break a lot of intranet 
sites where I believe HTTP auth is more common. I think we need to be 
even more careful about compat issues like this since it totally 
prevents you from accessing the service instead of having a somewhat 
broken experience. It seems like something we would want to announce far 
in advance and I suspect there will still be too many affected sites 
even with a years notice. Starting with warnings could help to reduce 
the compat issue down the road if we decide to stop support as not 
everyone will here about our deprecation plans.


Matthew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Richard Barnes]

On Fri, Apr 15, 2016 at 5:45 PM, Matthew N.  wrote:

> On 2016-04-15 7:47 AM, Tantek Çelik wrote:
>
>> What steps can we take in this direction WITHOUT breaking web compat?
>>
>>
>> E.g. since one of the issues raised is that *every* time a user
>> enters/submits a password over HTTP (not secure), it opens them to
>> being sniffed etc., thus it's good to discourage the frequency.
>>
>> Some STRAW PROPOSALS that I expect others here (and UX folks) to
>> easily improve on:
>>
>> 1. Warning (perhaps similar to the invalid red glow) on password
>> inputs in forms with HTTP "action"
>>
>
> We are making progress towards this and Aislinn Grigas from UX worked on a
> design for something like this:
> https://bugzilla.mozilla.org/attachment.cgi?id=8678150
>
> We already started developer-specific warnings in the web console and in
> the address bar of Nightly + Developer Edition:
> https://hacks.mozilla.org/2016/01/login-forms-over-https-please/
>
> There are some dependencies to fix before doing user-facing warnings which
> we're currently working on. You can follow along in the bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1217162
>
> 2. Warning (similarly) on HTTP-auth password dialogs
>>
>
> This is https://bugzilla.mozilla.org/show_bug.cgi?id=1185145 which I
> haven't seen a design for yet but should be less risky to implement than
> for . It is in the Firefox privacy/security team backlog.
>

Could we just disable HTTP auth for connections not protected with TLS?  At
least Basic auth is manifestly insecure over an insecure transport.  I
don't have any usage statistics, but I suspect it's pretty low compared to
form-based auth.

--Richard


> Meta bug related to dealing with insecure login forms:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1217142
>
> Thanks,
> Matthew N.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

On 4/15/16 2:12 AM, Jason Duell wrote:

> Focusing on third-party session cookies is an interesting idea.
> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
> and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
> content problems. Much later, we could consider sessionizing even HTTPS
> third-party cookies.
>

How about we sessionize only 3rd party HTTP cookies from sites that are on
our tracking protection list?  That seems the most targeted way to
encourage ad networks to bump up to HTTPS with a minimal amount of
collateral damage to other users of 3rd party HTTP cookies.


The IAB recently announced a "LEAN Ads" initiative [1]: Light, Encrypted 
(HTTPS), Ad Choice supported, and Non-invasive.


When the IAB agrees ad networks should use HTTPS, clearing HTTP cookies 
from third parties and/or sites on the Tracking Protection list becomes 
an easier sell, policy-wise. We're not talking about blocking cookies or 
content, just reducing the cookie lifetime.



[1] http://www.iab.com/news/lean/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Martin Thomson]

On 17 Apr 2016 2:37 AM, "Haik Aftandilian"  wrote:
>
> Sites might depend on a combination of https and non-https cookies and
then
> act strangely when a user returns to the site with only the https cookies.

This is also known as a security vulnerability. See
https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/zheng
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Haik Aftandilian]

On Fri, Apr 15, 2016 at 7:37 PM, Chris Peterson 
wrote:

> On 4/15/16 7:47 AM, Tantek Çelik wrote:
>
>> What steps can we take in this direction WITHOUT breaking web compat?
>>
>
> Would this feature actually break web compatibility? Or just needlessly
> annoy users?
>
> In his original post, Henri argued that clearing non-HTTPS cookies between
> sessions would not "Break the Web". There would be no user- or
> site-detectable changes mid-session. Clearing cookies between sessions
> could be user-detectable if they get logged out or lose their shopping
> cart. Sites, OTOH, must already handle the cases were a user's cookies are
> lost between sessions. Users could clear their cookies, use Private
> Browsing mode, or log into the site from a different browser or device.
>

​Tanvi brought up this point.

On Thu, Apr 14, 2016 at 12:58 PM, Tanvi Vyas  wrote:
​...​
* Even if login cookies are set over HTTPS, there are sometimes additional
cookies set over HTTP with user data in them (ex: city/zipcode).  Users may
have bad experiences on websites that rely on these secondary HTTP cookies
even if they are still logged in (ex: weather.yahoo.com for a user who is
logged into yahoo.com).
​...​

Sites might depend on a combination of https and non-https cookies and then
act strangely when a user returns to the site with only the https cookies.

Haik​

​​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

On 4/15/16 7:47 AM, Tantek Çelik wrote:

What steps can we take in this direction WITHOUT breaking web compat?


Would this feature actually break web compatibility? Or just needlessly 
annoy users?


In his original post, Henri argued that clearing non-HTTPS cookies 
between sessions would not "Break the Web". There would be no user- or 
site-detectable changes mid-session. Clearing cookies between sessions 
could be user-detectable if they get logged out or lose their shopping 
cart. Sites, OTOH, must already handle the cases were a user's cookies 
are lost between sessions. Users could clear their cookies, use Private 
Browsing mode, or log into the site from a different browser or device.



chris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Matthew N.]

On 2016-04-15 7:47 AM, Tantek Çelik wrote:

What steps can we take in this direction WITHOUT breaking web compat?


E.g. since one of the issues raised is that *every* time a user
enters/submits a password over HTTP (not secure), it opens them to
being sniffed etc., thus it's good to discourage the frequency.

Some STRAW PROPOSALS that I expect others here (and UX folks) to
easily improve on:

1. Warning (perhaps similar to the invalid red glow) on password
inputs in forms with HTTP "action"


We are making progress towards this and Aislinn Grigas from UX worked on 
a design for something like this: 
https://bugzilla.mozilla.org/attachment.cgi?id=8678150


We already started developer-specific warnings in the web console and in 
the address bar of Nightly + Developer Edition: 
https://hacks.mozilla.org/2016/01/login-forms-over-https-please/


There are some dependencies to fix before doing user-facing warnings 
which we're currently working on. You can follow along in the bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1217162



2. Warning (similarly) on HTTP-auth password dialogs


This is https://bugzilla.mozilla.org/show_bug.cgi?id=1185145 which I 
haven't seen a design for yet but should be less risky to implement than 
for . It is in the Firefox privacy/security team backlog.


Meta bug related to dealing with insecure login forms: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1217142


Thanks,
Matthew N.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Jason Duell]

On Fri, Apr 15, 2016 at 2:12 AM, Jason Duell  wrote:

> On Thu, Apr 14, 2016 at 10:54 PM, Chris Peterson 
> wrote:
>
>>
>> Focusing on third-party session cookies is an interesting idea.
>> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
>> and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
>> content problems. Much later, we could consider sessionizing even HTTPS
>> third-party cookies.
>>
>
> How about we sessionize only 3rd party HTTP cookies from sites that are on
> our tracking protection list?  That seems the most targeted way to
> encourage ad networks to bump up to HTTPS with a minimal amount of
> collateral damage to other users of 3rd party HTTP cookies.
>

(We could presumably keep a list of CDNs too and sessionize those as well)

Jason



> > We seem to have this already: network.cookie.thirdparty.sessionOnly
>
> Correct, that's what it does.
>
> Jason
>
>
>
>>
>> On 4/14/16 1:54 AM, Chris Peterson wrote:
>>
>>> Summary: Treat cookies set over non-secure HTTP as session cookies
>>>
>>> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
>>> cookies without the `secure` flag as session cookies.
>>>
>>> PROS:
>>>
>>> * Security: login cookies set over non-secure HTTP can be sniffed and
>>> replayed. Clearing those cookies at the end of the browser session would
>>> force the user to log in again next time, reducing the window of
>>> opportunity for an attacker to replay the login cookie. To avoid this,
>>> login-requiring sites should use HTTPS for at least their login page
>>> that set the login cookie.
>>>
>>> * Privacy: most ad networks still use non-secure HTTP. Content sites
>>> that use these ad networks are prevented from deploying HTTPS themselves
>>> because of HTTP/HTTPS mixed content breakage. Clearing user-tracking
>>> cookies set over non-secure HTTP at the end of every browser session
>>> would be a strong motivator for ad networks to upgrade to HTTPS, which
>>> would unblock content sites' HTTPS rollouts.
>>>
>>> However, my testing of Henri's original proposal shows that too few
>>> sites set the `secure` cookie flag for this to be practical. Even sites
>>> that primarily use HTTPS, like google.com, omit the `secure` flag for
>>> many cookies set over HTTPS.
>>>
>>> Instead, I propose treating all cookies set over non-secure HTTP as
>>> session cookies, regardless of whether they have the `secure` flag.
>>> Cookies set over HTTPS would be treated as "secure so far" and allowed
>>> to persist beyond the current browser session. This approach could be
>>> tightened so any "secure so far" cookies later sent over non-secure HTTP
>>> could be downgraded to session cookies. Note that Firefox's session
>>> restore will persist "session" cookies between browser restarts for the
>>> tabs that had been open. (This is "eternal session" feature/bug 530594.)
>>>
>>> To test my proposal, I loaded the home pages of the Alexa Top 25 News
>>> sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
>>> over HTTPS and only 7 had the `secure` flag. About 900 were third-party
>>> cookies. Treating non-secure cookies as session cookies means that over
>>> 1100 cookies would be cleared at the end of the browser session!
>>>
>>> CONS:
>>>
>>> * Sites that allow users to configure preferences without logging into
>>> an account would forget the users' preferences if they are not using
>>> HTTPS. For example, companies that have regional sites would forget the
>>> user's selected region at the end of the browser session.
>>>
>>> * Ad networks' opt-out cookies (for what they're worth) set over
>>> non-secure HTTP would be forgotten at the end of the browser session.
>>>
>>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
>>>
>>> Link to standard: N/A
>>>
>>> Platform coverage: All platforms
>>>
>>> Estimated or target release: Firefox 49
>>>
>>> Preference behind which this will be implemented:
>>> network.cookie.lifetime.httpSessionOnly
>>>
>>> Do other browser engines implement this? No
>>>
>>> [1]
>>>
>>> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
>>>
>>> [2] http://www.alexa.com/topsites/category/Top/News
>>>
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
>
> --
>
> Jason
>



-- 

Jason
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Jason Duell]

On Thu, Apr 14, 2016 at 10:54 PM, Chris Peterson 
wrote:

>
> Focusing on third-party session cookies is an interesting idea.
> "Sessionizing" non-HTTPS third-party cookies would encourage ad networks
> and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed
> content problems. Much later, we could consider sessionizing even HTTPS
> third-party cookies.
>

How about we sessionize only 3rd party HTTP cookies from sites that are on
our tracking protection list?  That seems the most targeted way to
encourage ad networks to bump up to HTTPS with a minimal amount of
collateral damage to other users of 3rd party HTTP cookies.

> We seem to have this already: network.cookie.thirdparty.sessionOnly

Correct, that's what it does.

Jason



>
> On 4/14/16 1:54 AM, Chris Peterson wrote:
>
>> Summary: Treat cookies set over non-secure HTTP as session cookies
>>
>> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
>> cookies without the `secure` flag as session cookies.
>>
>> PROS:
>>
>> * Security: login cookies set over non-secure HTTP can be sniffed and
>> replayed. Clearing those cookies at the end of the browser session would
>> force the user to log in again next time, reducing the window of
>> opportunity for an attacker to replay the login cookie. To avoid this,
>> login-requiring sites should use HTTPS for at least their login page
>> that set the login cookie.
>>
>> * Privacy: most ad networks still use non-secure HTTP. Content sites
>> that use these ad networks are prevented from deploying HTTPS themselves
>> because of HTTP/HTTPS mixed content breakage. Clearing user-tracking
>> cookies set over non-secure HTTP at the end of every browser session
>> would be a strong motivator for ad networks to upgrade to HTTPS, which
>> would unblock content sites' HTTPS rollouts.
>>
>> However, my testing of Henri's original proposal shows that too few
>> sites set the `secure` cookie flag for this to be practical. Even sites
>> that primarily use HTTPS, like google.com, omit the `secure` flag for
>> many cookies set over HTTPS.
>>
>> Instead, I propose treating all cookies set over non-secure HTTP as
>> session cookies, regardless of whether they have the `secure` flag.
>> Cookies set over HTTPS would be treated as "secure so far" and allowed
>> to persist beyond the current browser session. This approach could be
>> tightened so any "secure so far" cookies later sent over non-secure HTTP
>> could be downgraded to session cookies. Note that Firefox's session
>> restore will persist "session" cookies between browser restarts for the
>> tabs that had been open. (This is "eternal session" feature/bug 530594.)
>>
>> To test my proposal, I loaded the home pages of the Alexa Top 25 News
>> sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
>> over HTTPS and only 7 had the `secure` flag. About 900 were third-party
>> cookies. Treating non-secure cookies as session cookies means that over
>> 1100 cookies would be cleared at the end of the browser session!
>>
>> CONS:
>>
>> * Sites that allow users to configure preferences without logging into
>> an account would forget the users' preferences if they are not using
>> HTTPS. For example, companies that have regional sites would forget the
>> user's selected region at the end of the browser session.
>>
>> * Ad networks' opt-out cookies (for what they're worth) set over
>> non-secure HTTP would be forgotten at the end of the browser session.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
>>
>> Link to standard: N/A
>>
>> Platform coverage: All platforms
>>
>> Estimated or target release: Firefox 49
>>
>> Preference behind which this will be implemented:
>> network.cookie.lifetime.httpSessionOnly
>>
>> Do other browser engines implement this? No
>>
>> [1]
>>
>> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
>>
>> [2] http://www.alexa.com/topsites/category/Top/News
>>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 

Jason
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Francois Marier]

On 15/04/16 03:58 AM, Tanvi Vyas wrote:
> So how about a preference that treats all cookies set in a third party
> context as session cookies.  We could restrict this to HTTP, or even
> apply it to third party HTTPS cookies.

We seem to have this already: network.cookie.thirdparty.sessionOnly

Francois
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Chris Peterson]

Thanks for all the feedbck. I anticipated this proposal might not be 
practical with real world sites, so it's better to halt it here. :) I 
should have framed this email as an RFC instead of an intent to ship.


Focusing on third-party session cookies is an interesting idea. 
"Sessionizing" non-HTTPS third-party cookies would encourage ad networks 
and CDNs to use HTTPS, allowing content sites to use HTTPS without mixed 
content problems. Much later, we could consider sessionizing even HTTPS 
third-party cookies.


I'll think about telemetry probes that could be added to better 
understand these scenarios. I'm surprised we don't have much telemetry 
about cookie usage. Monica Chew wrote [1] about a Mozilla study of 
cookies, but that was only 573 users back in 2013.



chris

[1] http://monica-at-mozilla.blogspot.com/2013/10/cookie-counting.html


On 4/14/16 1:54 AM, Chris Peterson wrote:

Summary: Treat cookies set over non-secure HTTP as session cookies

Exactly one year ago today (!), Henri Sivonen proposed [1] treating
cookies without the `secure` flag as session cookies.

PROS:

* Security: login cookies set over non-secure HTTP can be sniffed and
replayed. Clearing those cookies at the end of the browser session would
force the user to log in again next time, reducing the window of
opportunity for an attacker to replay the login cookie. To avoid this,
login-requiring sites should use HTTPS for at least their login page
that set the login cookie.

* Privacy: most ad networks still use non-secure HTTP. Content sites
that use these ad networks are prevented from deploying HTTPS themselves
because of HTTP/HTTPS mixed content breakage. Clearing user-tracking
cookies set over non-secure HTTP at the end of every browser session
would be a strong motivator for ad networks to upgrade to HTTPS, which
would unblock content sites' HTTPS rollouts.

However, my testing of Henri's original proposal shows that too few
sites set the `secure` cookie flag for this to be practical. Even sites
that primarily use HTTPS, like google.com, omit the `secure` flag for
many cookies set over HTTPS.

Instead, I propose treating all cookies set over non-secure HTTP as
session cookies, regardless of whether they have the `secure` flag.
Cookies set over HTTPS would be treated as "secure so far" and allowed
to persist beyond the current browser session. This approach could be
tightened so any "secure so far" cookies later sent over non-secure HTTP
could be downgraded to session cookies. Note that Firefox's session
restore will persist "session" cookies between browser restarts for the
tabs that had been open. (This is "eternal session" feature/bug 530594.)

To test my proposal, I loaded the home pages of the Alexa Top 25 News
sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
over HTTPS and only 7 had the `secure` flag. About 900 were third-party
cookies. Treating non-secure cookies as session cookies means that over
1100 cookies would be cleared at the end of the browser session!

CONS:

* Sites that allow users to configure preferences without logging into
an account would forget the users' preferences if they are not using
HTTPS. For example, companies that have regional sites would forget the
user's selected region at the end of the browser session.

* Ad networks' opt-out cookies (for what they're worth) set over
non-secure HTTP would be forgotten at the end of the browser session.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368

Link to standard: N/A

Platform coverage: All platforms

Estimated or target release: Firefox 49

Preference behind which this will be implemented:
network.cookie.lifetime.httpSessionOnly

Do other browser engines implement this? No

[1]
https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ

[2] http://www.alexa.com/topsites/category/Top/News


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Karl Dubost]

Chris,

Le 14 avr. 2016 à 17:54, Chris Peterson  a écrit :
> Instead, I propose treating all cookies set over non-secure HTTP as session 
> cookies, regardless of whether they have the `secure` flag. […] To test my 
> proposal, I loaded the home pages of the Alexa Top 25 News sites [2].

To test the proposal, I think:

1. It should be on the 1,000 to 10,000 top Alexa Web sites.
2. It should take into account all sites that are just setting preferences over 
HTTP.
   cookies are not always used for username/password but apart of tracking for 
ads, they also are used for keeping the state on some choices such as 
languages, number of results returned, etc (without an account).

If we surprise the users with something giving the impression of a broken user 
experience compared to other browsers. We will get more Web compat reports 
which are not compat report. 

More specifically we have to weight how do we help users?

Some scenario I could see. 
* A preference explaining users that could ask the browser to forget about 
their insecure cookies and explaining the consequences for their user 
experience. And how to switch it off. 
* A common action of all browsers together at the same time (unlikely to happen 
but we can try).





-- 
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Joseph Lorenzo Hall]

The restriction to third-party requests is an interesting suggestion
and might provide some of the benefits Chris mentioned in the original
proposal. Seems like a change done carefully and with others. best,
Joe

On Thu, Apr 14, 2016 at 4:32 PM, Martin Thomson  wrote:
> I would like to see other browsers on board before taking on these risks.
>
> And a lot more testing.
>
> For instance, is there a way to collect telemetry on the impact of
> such a change without actually implementing it?  Does restricting it
> to 3rd party requests change things?
>
> On Fri, Apr 15, 2016 at 1:42 AM, Benjamin Smedberg
>  wrote:
>> I don't see how we can do this by default without harming our users. We can
>> be confident that this will break persistent login for lots of sites. I
>> appreciate the goal of moving HTTPS forward, but we are not in a position
>> where we our marketshare would force changes to the web ecosystem.
>>
>> Before turning this on by default, could we try exposing this to advanced
>> users (perhaps via test pilot or a similar extension), and try out some UI
>> options so that users have some ability to override this?
>>
>> Or could we explore doing this first only for 3rd-party requests.
>>
>> I oppose this proposal as written.
>>
>> --BDS
>>
>>
>> On Thu, Apr 14, 2016 at 4:54 AM, Chris Peterson 
>> wrote:
>>
>>> Summary: Treat cookies set over non-secure HTTP as session cookies
>>>
>>> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
>>> cookies without the `secure` flag as session cookies.
>>>
>>> PROS:
>>>
>>> * Security: login cookies set over non-secure HTTP can be sniffed and
>>> replayed. Clearing those cookies at the end of the browser session would
>>> force the user to log in again next time, reducing the window of
>>> opportunity for an attacker to replay the login cookie. To avoid this,
>>> login-requiring sites should use HTTPS for at least their login page that
>>> set the login cookie.
>>>
>>> * Privacy: most ad networks still use non-secure HTTP. Content sites that
>>> use these ad networks are prevented from deploying HTTPS themselves because
>>> of HTTP/HTTPS mixed content breakage. Clearing user-tracking cookies set
>>> over non-secure HTTP at the end of every browser session would be a strong
>>> motivator for ad networks to upgrade to HTTPS, which would unblock content
>>> sites' HTTPS rollouts.
>>>
>>> However, my testing of Henri's original proposal shows that too few sites
>>> set the `secure` cookie flag for this to be practical. Even sites that
>>> primarily use HTTPS, like google.com, omit the `secure` flag for many
>>> cookies set over HTTPS.
>>>
>>> Instead, I propose treating all cookies set over non-secure HTTP as
>>> session cookies, regardless of whether they have the `secure` flag. Cookies
>>> set over HTTPS would be treated as "secure so far" and allowed to persist
>>> beyond the current browser session. This approach could be tightened so any
>>> "secure so far" cookies later sent over non-secure HTTP could be downgraded
>>> to session cookies. Note that Firefox's session restore will persist
>>> "session" cookies between browser restarts for the tabs that had been open.
>>> (This is "eternal session" feature/bug 530594.)
>>>
>>> To test my proposal, I loaded the home pages of the Alexa Top 25 News
>>> sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
>>> over HTTPS and only 7 had the `secure` flag. About 900 were third-party
>>> cookies. Treating non-secure cookies as session cookies means that over
>>> 1100 cookies would be cleared at the end of the browser session!
>>>
>>> CONS:
>>>
>>> * Sites that allow users to configure preferences without logging into an
>>> account would forget the users' preferences if they are not using HTTPS.
>>> For example, companies that have regional sites would forget the user's
>>> selected region at the end of the browser session.
>>>
>>> * Ad networks' opt-out cookies (for what they're worth) set over
>>> non-secure HTTP would be forgotten at the end of the browser session.
>>>
>>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
>>>
>>> Link to standard: N/A
>>>
>>> Platform coverage: All platforms
>>>
>>> Estimated or target release: Firefox 49
>>>
>>> Preference behind which this will be implemented:
>>> network.cookie.lifetime.httpSessionOnly
>>>
>>> Do other browser engines implement this? No
>>>
>>> [1]
>>> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
>>> [2] http://www.alexa.com/topsites/category/Top/News
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
> 

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Tanvi Vyas]

On the surface, this seems like a great idea and privacy win - it gets 
rid of all those pesky tracking cookies!  But under the covers there are 
a lot of issues, as mentioned by previous replies and summarized below:


* Puts the user's password at greater risk, since the user has to enter 
it and potentially send it over HTTP more often. Incentivizes users to 
use shorter and easier passwords, since they have to enter them more 
frequently. And makes them more susceptible to phishing and password 
reuse attacks.
* Bad user experience, where websites don't remember who the user is or 
what their preferred language/country is.
* Even if login cookies are set over HTTPS, there are sometimes 
additional cookies set over HTTP with user data in them (ex: 
city/zipcode).  Users may have bad experiences on websites that rely on 
these secondary HTTP cookies even if they are still logged in (ex: 
weather.yahoo.com for a user who is logged into yahoo.com).
* Special casing login cookies would be very tricky.  A number of sites 
don't label their password fields with type="password". Sites who have 
second factor auth will go through an interstitial between the login 
page and setting the login cookie (though I suppose the sites that have 
2FA are over HTTPS).


I'm afraid doing this by default will drive away users and open up more 
security issues.  We could have an about:config pref for it that some 
users may elect to set.  But instead, we should experiment with applying 
this to third parties as Benjamin suggested.  We already have a 
preferences to disable third party cookies, but perhaps that is too 
restrictive for most users.  We also have a preference to disable third 
party cookies from sites that are never first party, but that gives 
popular sites a competitive advantage in advertising.


So how about a preference that treats all cookies set in a third party 
context as session cookies.  We could restrict this to HTTP, or even 
apply it to third party HTTPS cookies.  This will solve the pesky 
tracking cookies problem, but won't break insecure logins[1] or site 
preferences.  It won't force users to enter their passwords more 
frequently.  Since third party cookies aren't completely blocked, it 
shouldn't break sites the way the third party cookie pref sometimes does 
now.


~Tanvi

On 4/14/16 1:54 AM, Chris Peterson wrote:

Summary: Treat cookies set over non-secure HTTP as session cookies

Exactly one year ago today (!), Henri Sivonen proposed [1] treating 
cookies without the `secure` flag as session cookies.


PROS:

* Security: login cookies set over non-secure HTTP can be sniffed and 
replayed. Clearing those cookies at the end of the browser session 
would force the user to log in again next time, reducing the window of 
opportunity for an attacker to replay the login cookie. To avoid this, 
login-requiring sites should use HTTPS for at least their login page 
that set the login cookie.


* Privacy: most ad networks still use non-secure HTTP. Content sites 
that use these ad networks are prevented from deploying HTTPS 
themselves because of HTTP/HTTPS mixed content breakage. Clearing 
user-tracking cookies set over non-secure HTTP at the end of every 
browser session would be a strong motivator for ad networks to upgrade 
to HTTPS, which would unblock content sites' HTTPS rollouts.


However, my testing of Henri's original proposal shows that too few 
sites set the `secure` cookie flag for this to be practical. Even 
sites that primarily use HTTPS, like google.com, omit the `secure` 
flag for many cookies set over HTTPS.


Instead, I propose treating all cookies set over non-secure HTTP as 
session cookies, regardless of whether they have the `secure` flag. 
Cookies set over HTTPS would be treated as "secure so far" and allowed 
to persist beyond the current browser session. This approach could be 
tightened so any "secure so far" cookies later sent over non-secure 
HTTP could be downgraded to session cookies. Note that Firefox's 
session restore will persist "session" cookies between browser 
restarts for the tabs that had been open. (This is "eternal session" 
feature/bug 530594.)


To test my proposal, I loaded the home pages of the Alexa Top 25 News 
sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were 
set over HTTPS and only 7 had the `secure` flag. About 900 were 
third-party cookies. Treating non-secure cookies as session cookies 
means that over 1100 cookies would be cleared at the end of the 
browser session!


CONS:

* Sites that allow users to configure preferences without logging into 
an account would forget the users' preferences if they are not using 
HTTPS. For example, companies that have regional sites would forget 
the user's selected region at the end of the browser session.


* Ad networks' opt-out cookies (for what they're worth) set over 
non-secure HTTP would be forgotten at the end of the browser session.


Bug: 

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Haik Aftandilian]

On Thu, Apr 14, 2016 at 1:54 AM, Chris Peterson 
wrote:

> Summary: Treat cookies set over non-secure HTTP as session cookies
>
> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
> cookies without the `secure` flag as session cookies.
>
> PROS:
>
> * Security: login cookies set over non-secure HTTP can be sniffed and
> replayed. Clearing those cookies at the end of the browser session would
> force the user to log in again next time, reducing the window of
> opportunity for an attacker to replay the login cookie. To avoid this,
> login-requiring sites should use HTTPS for at least their login page that
> set the login cookie.
>

​Wouldn't that only be true for sites that limit users to one login session
at a time? For sites that allow more than one login session​, when the user
logs in again each time, the original session cookie would not be
invalidated until the site decides to forget it. So if an attacker sniffed
the login cookie, they could replay it even after the user logged in again.
I know I have persistent logins to some sites on more than one computer,
but don't know how typical that is.

Haik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Eric Rescorla]

This seems like the right question.

-Ekr

On Thu, Apr 14, 2016 at 9:17 AM, Kyle Huey  wrote:

> Why should we be the ones to take the web compat hit on this?
>
> - Kyle
> On Apr 14, 2016 1:55 AM, "Chris Peterson"  wrote:
>
> > Summary: Treat cookies set over non-secure HTTP as session cookies
> >
> > Exactly one year ago today (!), Henri Sivonen proposed [1] treating
> > cookies without the `secure` flag as session cookies.
> >
> > PROS:
> >
> > * Security: login cookies set over non-secure HTTP can be sniffed and
> > replayed. Clearing those cookies at the end of the browser session would
> > force the user to log in again next time, reducing the window of
> > opportunity for an attacker to replay the login cookie. To avoid this,
> > login-requiring sites should use HTTPS for at least their login page that
> > set the login cookie.
> >
> > * Privacy: most ad networks still use non-secure HTTP. Content sites that
> > use these ad networks are prevented from deploying HTTPS themselves
> because
> > of HTTP/HTTPS mixed content breakage. Clearing user-tracking cookies set
> > over non-secure HTTP at the end of every browser session would be a
> strong
> > motivator for ad networks to upgrade to HTTPS, which would unblock
> content
> > sites' HTTPS rollouts.
> >
> > However, my testing of Henri's original proposal shows that too few sites
> > set the `secure` cookie flag for this to be practical. Even sites that
> > primarily use HTTPS, like google.com, omit the `secure` flag for many
> > cookies set over HTTPS.
> >
> > Instead, I propose treating all cookies set over non-secure HTTP as
> > session cookies, regardless of whether they have the `secure` flag.
> Cookies
> > set over HTTPS would be treated as "secure so far" and allowed to persist
> > beyond the current browser session. This approach could be tightened so
> any
> > "secure so far" cookies later sent over non-secure HTTP could be
> downgraded
> > to session cookies. Note that Firefox's session restore will persist
> > "session" cookies between browser restarts for the tabs that had been
> open.
> > (This is "eternal session" feature/bug 530594.)
> >
> > To test my proposal, I loaded the home pages of the Alexa Top 25 News
> > sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
> > over HTTPS and only 7 had the `secure` flag. About 900 were third-party
> > cookies. Treating non-secure cookies as session cookies means that over
> > 1100 cookies would be cleared at the end of the browser session!
> >
> > CONS:
> >
> > * Sites that allow users to configure preferences without logging into an
> > account would forget the users' preferences if they are not using HTTPS.
> > For example, companies that have regional sites would forget the user's
> > selected region at the end of the browser session.
> >
> > * Ad networks' opt-out cookies (for what they're worth) set over
> > non-secure HTTP would be forgotten at the end of the browser session.
> >
> > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
> >
> > Link to standard: N/A
> >
> > Platform coverage: All platforms
> >
> > Estimated or target release: Firefox 49
> >
> > Preference behind which this will be implemented:
> > network.cookie.lifetime.httpSessionOnly
> >
> > Do other browser engines implement this? No
> >
> > [1]
> >
> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
> > [2] http://www.alexa.com/topsites/category/Top/News
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Jonas Sicking]

I have two concerns with this.

First off, it means that users might need to actively log in to
websites more often. This is a really big hassle for users, especially
on mobile. We did some studies when we did FirefoxOS between the
differences between native versions and web version of various apps
(where both were available). One of the biggest differences, and which
was annoying to no end, was that web versions tend to ask for users to
log in more often, whereas native versions only asked you to log on
once on initial launch. Making this worse seems like a bad thing.

This also has security implications since asking users to type
username/password more often makes them more prone to phishing
attacks.

The second concern is that it might make users more reluctant to
restart their browser in order to install an update. This also has
obvious security implications.

/ Jonas



On Thu, Apr 14, 2016 at 1:54 AM, Chris Peterson  wrote:
> Summary: Treat cookies set over non-secure HTTP as session cookies
>
> Exactly one year ago today (!), Henri Sivonen proposed [1] treating cookies
> without the `secure` flag as session cookies.
>
> PROS:
>
> * Security: login cookies set over non-secure HTTP can be sniffed and
> replayed. Clearing those cookies at the end of the browser session would
> force the user to log in again next time, reducing the window of opportunity
> for an attacker to replay the login cookie. To avoid this, login-requiring
> sites should use HTTPS for at least their login page that set the login
> cookie.
>
> * Privacy: most ad networks still use non-secure HTTP. Content sites that
> use these ad networks are prevented from deploying HTTPS themselves because
> of HTTP/HTTPS mixed content breakage. Clearing user-tracking cookies set
> over non-secure HTTP at the end of every browser session would be a strong
> motivator for ad networks to upgrade to HTTPS, which would unblock content
> sites' HTTPS rollouts.
>
> However, my testing of Henri's original proposal shows that too few sites
> set the `secure` cookie flag for this to be practical. Even sites that
> primarily use HTTPS, like google.com, omit the `secure` flag for many
> cookies set over HTTPS.
>
> Instead, I propose treating all cookies set over non-secure HTTP as session
> cookies, regardless of whether they have the `secure` flag. Cookies set over
> HTTPS would be treated as "secure so far" and allowed to persist beyond the
> current browser session. This approach could be tightened so any "secure so
> far" cookies later sent over non-secure HTTP could be downgraded to session
> cookies. Note that Firefox's session restore will persist "session" cookies
> between browser restarts for the tabs that had been open. (This is "eternal
> session" feature/bug 530594.)
>
> To test my proposal, I loaded the home pages of the Alexa Top 25 News sites
> [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set over
> HTTPS and only 7 had the `secure` flag. About 900 were third-party cookies.
> Treating non-secure cookies as session cookies means that over 1100 cookies
> would be cleared at the end of the browser session!
>
> CONS:
>
> * Sites that allow users to configure preferences without logging into an
> account would forget the users' preferences if they are not using HTTPS. For
> example, companies that have regional sites would forget the user's selected
> region at the end of the browser session.
>
> * Ad networks' opt-out cookies (for what they're worth) set over non-secure
> HTTP would be forgotten at the end of the browser session.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
>
> Link to standard: N/A
>
> Platform coverage: All platforms
>
> Estimated or target release: Firefox 49
>
> Preference behind which this will be implemented:
> network.cookie.lifetime.httpSessionOnly
>
> Do other browser engines implement this? No
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
> [2] http://www.alexa.com/topsites/category/Top/News
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Kyle Huey]

Why should we be the ones to take the web compat hit on this?

- Kyle
On Apr 14, 2016 1:55 AM, "Chris Peterson"  wrote:

> Summary: Treat cookies set over non-secure HTTP as session cookies
>
> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
> cookies without the `secure` flag as session cookies.
>
> PROS:
>
> * Security: login cookies set over non-secure HTTP can be sniffed and
> replayed. Clearing those cookies at the end of the browser session would
> force the user to log in again next time, reducing the window of
> opportunity for an attacker to replay the login cookie. To avoid this,
> login-requiring sites should use HTTPS for at least their login page that
> set the login cookie.
>
> * Privacy: most ad networks still use non-secure HTTP. Content sites that
> use these ad networks are prevented from deploying HTTPS themselves because
> of HTTP/HTTPS mixed content breakage. Clearing user-tracking cookies set
> over non-secure HTTP at the end of every browser session would be a strong
> motivator for ad networks to upgrade to HTTPS, which would unblock content
> sites' HTTPS rollouts.
>
> However, my testing of Henri's original proposal shows that too few sites
> set the `secure` cookie flag for this to be practical. Even sites that
> primarily use HTTPS, like google.com, omit the `secure` flag for many
> cookies set over HTTPS.
>
> Instead, I propose treating all cookies set over non-secure HTTP as
> session cookies, regardless of whether they have the `secure` flag. Cookies
> set over HTTPS would be treated as "secure so far" and allowed to persist
> beyond the current browser session. This approach could be tightened so any
> "secure so far" cookies later sent over non-secure HTTP could be downgraded
> to session cookies. Note that Firefox's session restore will persist
> "session" cookies between browser restarts for the tabs that had been open.
> (This is "eternal session" feature/bug 530594.)
>
> To test my proposal, I loaded the home pages of the Alexa Top 25 News
> sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
> over HTTPS and only 7 had the `secure` flag. About 900 were third-party
> cookies. Treating non-secure cookies as session cookies means that over
> 1100 cookies would be cleared at the end of the browser session!
>
> CONS:
>
> * Sites that allow users to configure preferences without logging into an
> account would forget the users' preferences if they are not using HTTPS.
> For example, companies that have regional sites would forget the user's
> selected region at the end of the browser session.
>
> * Ad networks' opt-out cookies (for what they're worth) set over
> non-secure HTTP would be forgotten at the end of the browser session.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
>
> Link to standard: N/A
>
> Platform coverage: All platforms
>
> Estimated or target release: Firefox 49
>
> Preference behind which this will be implemented:
> network.cookie.lifetime.httpSessionOnly
>
> Do other browser engines implement this? No
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
> [2] http://www.alexa.com/topsites/category/Top/News
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Benjamin Smedberg]

I don't see how we can do this by default without harming our users. We can
be confident that this will break persistent login for lots of sites. I
appreciate the goal of moving HTTPS forward, but we are not in a position
where we our marketshare would force changes to the web ecosystem.

Before turning this on by default, could we try exposing this to advanced
users (perhaps via test pilot or a similar extension), and try out some UI
options so that users have some ability to override this?

Or could we explore doing this first only for 3rd-party requests.

I oppose this proposal as written.

--BDS


On Thu, Apr 14, 2016 at 4:54 AM, Chris Peterson 
wrote:

> Summary: Treat cookies set over non-secure HTTP as session cookies
>
> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
> cookies without the `secure` flag as session cookies.
>
> PROS:
>
> * Security: login cookies set over non-secure HTTP can be sniffed and
> replayed. Clearing those cookies at the end of the browser session would
> force the user to log in again next time, reducing the window of
> opportunity for an attacker to replay the login cookie. To avoid this,
> login-requiring sites should use HTTPS for at least their login page that
> set the login cookie.
>
> * Privacy: most ad networks still use non-secure HTTP. Content sites that
> use these ad networks are prevented from deploying HTTPS themselves because
> of HTTP/HTTPS mixed content breakage. Clearing user-tracking cookies set
> over non-secure HTTP at the end of every browser session would be a strong
> motivator for ad networks to upgrade to HTTPS, which would unblock content
> sites' HTTPS rollouts.
>
> However, my testing of Henri's original proposal shows that too few sites
> set the `secure` cookie flag for this to be practical. Even sites that
> primarily use HTTPS, like google.com, omit the `secure` flag for many
> cookies set over HTTPS.
>
> Instead, I propose treating all cookies set over non-secure HTTP as
> session cookies, regardless of whether they have the `secure` flag. Cookies
> set over HTTPS would be treated as "secure so far" and allowed to persist
> beyond the current browser session. This approach could be tightened so any
> "secure so far" cookies later sent over non-secure HTTP could be downgraded
> to session cookies. Note that Firefox's session restore will persist
> "session" cookies between browser restarts for the tabs that had been open.
> (This is "eternal session" feature/bug 530594.)
>
> To test my proposal, I loaded the home pages of the Alexa Top 25 News
> sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
> over HTTPS and only 7 had the `secure` flag. About 900 were third-party
> cookies. Treating non-secure cookies as session cookies means that over
> 1100 cookies would be cleared at the end of the browser session!
>
> CONS:
>
> * Sites that allow users to configure preferences without logging into an
> account would forget the users' preferences if they are not using HTTPS.
> For example, companies that have regional sites would forget the user's
> selected region at the end of the browser session.
>
> * Ad networks' opt-out cookies (for what they're worth) set over
> non-secure HTTP would be forgotten at the end of the browser session.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
>
> Link to standard: N/A
>
> Platform coverage: All platforms
>
> Estimated or target release: Firefox 49
>
> Preference behind which this will be implemented:
> network.cookie.lifetime.httpSessionOnly
>
> Do other browser engines implement this? No
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
> [2] http://www.alexa.com/topsites/category/Top/News
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Xidorn Quan]

On Thu, Apr 14, 2016 at 6:54 PM, Chris Peterson 
wrote:

>
> Do other browser engines implement this? No
>

I have no particular thought about the idea itself, but it seems to me this
is a breaking change to the web.

As it's a major breaking change, I don't think we should do this without
support and action from other browser vendors.

We should at least ask Chrome to coincide with us in the same time frame.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform