Proposed Mozilla Hosting - HTTPS by default

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

Proposed Mozilla Hosting - HTTPS by default

Patrick McManus-3
Hi Everyone - This post continues a side conversation on dev-planning which
started last week on yammer. My apologies for the to: line, it carries over
interested folks from the original discussion.

The discussion was whether or not all Mozilla hosted web content should be
available over https by default. I am going to argue that some version of
"HTTPS everywhere is best[*]" should be Mozilla's default position for both
clients and servers. It flows from this that mozilla hosted resources
should be made available over https unless they have a some particular
compelling reason not to be. I'm hoping we can get consensus on the
principle of https hosting by default.

First, I want to thank our ops team for the work they've been doing here -
they have been doing great work getting things migrated to support https
recently. Its been amazing - and it takes time - this is not a criticism of
that process at all. As an example of good news, I recently filed a bug
about the public suffix list not being served with https and they brought
that up to speed much faster than I anticipated. Good stuff. Thank you!

I'm talking about current and future projects that don't have https in
their plans, but imo should. There are several that I could cite as
examples. but I'm going to avoid doing so because I think it misses the
larger point: user's confidentiality is better served by https than by
http. Mozilla can lead on this and Individuals should be able to depend on
us serving their interest. We know that cleartext is being abused out there.

The best supporting argument here is principle 4 of the Manifesto:
Individuals' security and privacy on the Internet are fundamental and must
not be treated as optional. When framed like that the content does not
matter - it is our place to do what we reasonably can to ensure their
privacy during the act of consumption. https protects not only the security
of the data, but it contributes to the confidentiality of the consumer. It
is not perfect (today especially heartbleedingly so), but it is beneficial
for transfers of even public data. By analogy, I am pleased that my public
library does not log my borrowing history on a chalk board in the lobby -
the books hold no secrets, but my choices in consumption are something I
choose to keep confidential. (unless I browbeat you into reading one of my
favorites :))

No doubt we can nitpick the particulars - and there clearly are operational
challenges here chiefly in managing the certs. I'm pretty familiar with all
of the costs and I think we've already shown they are generally
surmountable. But where there is pain I think its really important to
embrace that pain and push for ways to make the open web operate better,
rather than just side stepping the issues. This is important. Let's be
awesome and lead. That's our raison d'etre, right?

-Patrick

[*] I often get a followup question of why firefox doesn't integrate https
everywhere, the EFF add-on. The answer is that its not possible to really
do this rewriting correctly and independently on the client side - but I'm
really fond of the notion.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Mozilla Hosting - HTTPS by default

Benjamin Kerensa
> The best supporting argument here is principle 4 of the Manifesto:
> Individuals' security and privacy on the Internet are fundamental and must
> not be treated as optional. When framed like that the content does not
> matter - it is our place to do what we reasonably can to ensure their
> privacy during the act of consumption. https protects not only the
security
> of the data, but it contributes to the confidentiality of the consumer.

+1 to implementing changes that will enhance users privacy and security
while using sites and services Mozilla offers.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Mozilla Hosting - HTTPS by default

Anne van Kesteren
In reply to this post by Patrick McManus-3
On Thu, Apr 10, 2014 at 5:26 PM, Patrick McManus <[hidden email]> wrote:
> But where there is pain I think its really important to
> embrace that pain and push for ways to make the open web operate better,
> rather than just side stepping the issues. This is important. Let's be
> awesome and lead. That's our raison d'etre, right?

Can we lead with HSTS flags out? :-)


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

Re: Proposed Mozilla Hosting - HTTPS by default

Doug Turner-4
There are other techs like CPS that I want to also cheerlead for.  We need to be leading here.  I encourage you, when rolling out a site, make it a requirement.  As for MoCo stuff, if you get pushback, please reach out to myself or to gal.

Doug
--
Doug Turner


On Thursday, April 10, 2014 at 8:50 AM, Anne van Kesteren wrote:

> On Thu, Apr 10, 2014 at 5:26 PM, Patrick McManus <[hidden email] (mailto:[hidden email])> wrote:
> > But where there is pain I think its really important to
> > embrace that pain and push for ways to make the open web operate better,
> > rather than just side stepping the issues. This is important. Let's be
> > awesome and lead. That's our raison d'etre, right?
> >
>
>
> Can we lead with HSTS flags out? :-)
>
>
> --
> http://annevankesteren.nl/
>
>


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

Re: Proposed Mozilla Hosting - HTTPS by default

Doug Turner-4
CSP! :)

--
Doug Turner


On Thursday, April 10, 2014 at 8:54 AM, Doug Turner wrote:

> There are other techs like CPS that I want to also cheerlead for.  We need to be leading here.  I encourage you, when rolling out a site, make it a requirement.  As for MoCo stuff, if you get pushback, please reach out to myself or to gal.
>
> Doug
> --
> Doug Turner
>
>
> On Thursday, April 10, 2014 at 8:50 AM, Anne van Kesteren wrote:
>
> > On Thu, Apr 10, 2014 at 5:26 PM, Patrick McManus <[hidden email] (mailto:[hidden email])> wrote:
> > > But where there is pain I think its really important to
> > > embrace that pain and push for ways to make the open web operate better,
> > > rather than just side stepping the issues. This is important. Let's be
> > > awesome and lead. That's our raison d'etre, right?
> > >
> >
> >
> > Can we lead with HSTS flags out? :-)
> >
> >
> > --
> > http://annevankesteren.nl/
> >
> >
> >
>
>

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

Re: Proposed Mozilla Hosting - HTTPS by default

Richard Barnes
In reply to this post by Patrick McManus-3
At the level of motivations, this is all motherhood and apple pie.

What are the next steps?




On Apr 10, 2014, at 11:26 AM, Patrick McManus <[hidden email]> wrote:

> Hi Everyone - This post continues a side conversation on dev-planning which started last week on yammer. My apologies for the to: line, it carries over interested folks from the original discussion.
>
> The discussion was whether or not all Mozilla hosted web content should be available over https by default. I am going to argue that some version of "HTTPS everywhere is best[*]" should be Mozilla's default position for both clients and servers. It flows from this that mozilla hosted resources should be made available over https unless they have a some particular compelling reason not to be. I'm hoping we can get consensus on the principle of https hosting by default.
>
> First, I want to thank our ops team for the work they've been doing here - they have been doing great work getting things migrated to support https recently. Its been amazing - and it takes time - this is not a criticism of that process at all. As an example of good news, I recently filed a bug about the public suffix list not being served with https and they brought that up to speed much faster than I anticipated. Good stuff. Thank you!
>
> I'm talking about current and future projects that don't have https in their plans, but imo should. There are several that I could cite as examples. but I'm going to avoid doing so because I think it misses the larger point: user's confidentiality is better served by https than by http. Mozilla can lead on this and Individuals should be able to depend on us serving their interest. We know that cleartext is being abused out there.
>
> The best supporting argument here is principle 4 of the Manifesto: Individuals’ security and privacy on the Internet are fundamental and must not be treated as optional. When framed like that the content does not matter - it is our place to do what we reasonably can to ensure their privacy during the act of consumption. https protects not only the security of the data, but it contributes to the confidentiality of the consumer. It is not perfect (today especially heartbleedingly so), but it is beneficial for transfers of even public data. By analogy, I am pleased that my public library does not log my borrowing history on a chalk board in the lobby - the books hold no secrets, but my choices in consumption are something I choose to keep confidential. (unless I browbeat you into reading one of my favorites :))
>
> No doubt we can nitpick the particulars - and there clearly are operational challenges here chiefly in managing the certs. I'm pretty familiar with all of the costs and I think we've already shown they are generally surmountable. But where there is pain I think its really important to embrace that pain and push for ways to make the open web operate better, rather than just side stepping the issues. This is important. Let's be awesome and lead. That's our raison d'etre, right?
>
> -Patrick
>
> [*] I often get a followup question of why firefox doesn't integrate https everywhere, the EFF add-on. The answer is that its not possible to really do this rewriting correctly and independently on the client side - but I'm really fond of the notion.
>

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Mozilla Hosting - HTTPS by default

Doug Turner-4
I suspect it is to get IT buy in (I’ll work on that).  They will need to audit the sites that don’t do https, and decommission them or add tls.


--  
Doug Turner


On Thursday, April 10, 2014 at 9:04 AM, Richard Barnes wrote:

> At the level of motivations, this is all motherhood and apple pie.
>  
> What are the next steps?
>  
>  
>  
>  
> On Apr 10, 2014, at 11:26 AM, Patrick McManus <[hidden email] (mailto:[hidden email])> wrote:
>  
> > Hi Everyone - This post continues a side conversation on dev-planning which started last week on yammer. My apologies for the to: line, it carries over interested folks from the original discussion.
> >  
> > The discussion was whether or not all Mozilla hosted web content should be available over https by default. I am going to argue that some version of "HTTPS everywhere is best[*]" should be Mozilla's default position for both clients and servers. It flows from this that mozilla hosted resources should be made available over https unless they have a some particular compelling reason not to be. I'm hoping we can get consensus on the principle of https hosting by default.
> >  
> > First, I want to thank our ops team for the work they've been doing here - they have been doing great work getting things migrated to support https recently. Its been amazing - and it takes time - this is not a criticism of that process at all. As an example of good news, I recently filed a bug about the public suffix list not being served with https and they brought that up to speed much faster than I anticipated. Good stuff. Thank you!
> >  
> > I'm talking about current and future projects that don't have https in their plans, but imo should. There are several that I could cite as examples. but I'm going to avoid doing so because I think it misses the larger point: user's confidentiality is better served by https than by http. Mozilla can lead on this and Individuals should be able to depend on us serving their interest. We know that cleartext is being abused out there.
> >  
> > The best supporting argument here is principle 4 of the Manifesto: Individuals’ security and privacy on the Internet are fundamental and must not be treated as optional. When framed like that the content does not matter - it is our place to do what we reasonably can to ensure their privacy during the act of consumption. https protects not only the security of the data, but it contributes to the confidentiality of the consumer. It is not perfect (today especially heartbleedingly so), but it is beneficial for transfers of even public data. By analogy, I am pleased that my public library does not log my borrowing history on a chalk board in the lobby - the books hold no secrets, but my choices in consumption are something I choose to keep confidential. (unless I browbeat you into reading one of my favorites :))
> >  
> > No doubt we can nitpick the particulars - and there clearly are operational challenges here chiefly in managing the certs. I'm pretty familiar with all of the costs and I think we've already shown they are generally surmountable. But where there is pain I think its really important to embrace that pain and push for ways to make the open web operate better, rather than just side stepping the issues. This is important. Let's be awesome and lead. That's our raison d'etre, right?
> >  
> > -Patrick
> >  
> > [*] I often get a followup question of why firefox doesn't integrate https everywhere, the EFF add-on. The answer is that its not possible to really do this rewriting correctly and independently on the client side - but I'm really fond of the notion.  
>  
>  
> Attachments:  
> - smime.p7s
>  


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

Re: Proposed Mozilla Hosting - HTTPS by default

Zack Weinberg-2
In reply to this post by Patrick McManus-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/10/2014 11:26 AM, Patrick McManus wrote:

> Hi Everyone - This post continues a side conversation on
> dev-planning which started last week on yammer. My apologies for
> the to: line, it carries over interested folks from the original
> discussion.
>
> The discussion was whether or not all Mozilla hosted web content
> should be available over https by default. I am going to argue that
> some version of "HTTPS everywhere is best[*]" should be Mozilla's
> default position for both clients and servers. It flows from this
> that mozilla hosted resources should be made available over https
> unless they have a some particular compelling reason not to be. I'm
> hoping we can get consensus on the principle of https hosting by
> default.

As a security nerd I 100% support this principle.

There may need to be a small handful of exceptions - the only thing
that comes to mind is that the path from 'mozilla.org' to initial
Firefox download *might* need to be accessible over plain HTTP for the
sake of people stuck without any usable HTTPS client.

zw
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJTRs2lAAoJEJH8wytnaapkqrAQAIgzmuZRF1xY6IcvXBzmZUud
tdT7afgAgoCbUoksICCqIskRg9Kj4aarieKRpek0PvOnhjQJ9kVvu82/RLtQTWIc
VACMg/IQkZe/x+jm9WhTMVeVdjgjkSUr3oXFda7u+NW8BDHan8RyNc/LHMF2CxqM
oVyZ74+v59ctohY+vciQXgezCaUx1C9lTRftfji/HKaUlmrde+OeRnaE3BqxkonI
J94yC6UaVX3NOTAsrK7tz1BIo80YTuCS9NgtXhjiYe/9aUeUDwpYrTdTC1SSaNAE
F0jskZN7crXbiNBeN3FyV5eNJCOMryGF8OtQa8hw6TeDbFzlmRZ/T8LH3zFrFCkR
C6fiZkdMq0f4o52/RyQlsvAYPAfxbeRn+q0rxER83b4TQS0kv4ZlAAP0vD7rF+Ls
WpBdZLeu0fOd08SzjHKGhSOP1fB7uDj1DrFpt5gK3xoP+9vJWrNuXIgUc8j/GjZO
r/JitcfxsQH0Bag3Xf2WNhPa++SLykJMcfT2PRcwEQSBnjjxwvTlrlE2wN4xqk7l
ISDaHZMdzXujZuld4QVR4kxFZVS0v3UGhzyIHyAXwSy+yHMVivoGtM3uIEMPVtb2
KGYYi0RW+hIMngvmUikvziUHI9G5y1xhQ3kei9azKn2Vs+Z+ENRVJepC2a/3QsWF
AoI4nxAlpFIFrjggQWdH
=bJVs
-----END PGP SIGNATURE-----
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Mozilla Hosting - HTTPS by default

Martin Thomson
In reply to this post by Doug Turner-4
On 2014-04-10, at 09:50, Doug Turner <[hidden email]> wrote:

> I suspect it is to get IT buy in (I’ll work on that).  They will need to audit the sites that don’t do https, and decommission them or add tls.

Decommissioning HTTP access entirely might not be possible for some services, as Zack points out.  But we can get people on HTTPS by using HSTS.  By default, HSTS recommends a hard redirect, which is basically equivalent to disabling HTTP.  I think that it was the SSL Everywhere project that used a tiny HTTPS-sourced image on their HTTP pages.  If that is retrieved, the response includes the HSTS header and next time (i.e., when the user navigates), everything is secure.

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

Re: Proposed Mozilla Hosting - HTTPS by default

Richard Barnes

On Apr 10, 2014, at 1:10 PM, Martin Thomson <[hidden email]> wrote:

> On 2014-04-10, at 09:50, Doug Turner <[hidden email]> wrote:
>
>> I suspect it is to get IT buy in (I’ll work on that).  They will need to audit the sites that don’t do https, and decommission them or add tls.
>
> Decommissioning HTTP access entirely might not be possible for some services, as Zack points out.  But we can get people on HTTPS by using HSTS.  By default, HSTS recommends a hard redirect, which is basically equivalent to disabling HTTP.  I think that it was the SSL Everywhere project that used a tiny HTTPS-sourced image on their HTTP pages.  If that is retrieved, the response includes the HSTS header and next time (i.e., when the user navigates), everything is secure.

I don't think Doug was suggesting turning off HTTP, just turning off services that can't also do HTTPS.

In any case, it seems worth doing HTTPS / HSTS if only to get the data on how much this moves over our traffic to HTTPS.


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Mozilla Hosting - HTTPS by default

David E. Ross-3
In reply to this post by Patrick McManus-3
On 4/10/2014 8:26 AM, Patrick McManus wrote:

> Hi Everyone - This post continues a side conversation on dev-planning which
> started last week on yammer. My apologies for the to: line, it carries over
> interested folks from the original discussion.
>
> The discussion was whether or not all Mozilla hosted web content should be
> available over https by default. I am going to argue that some version of
> "HTTPS everywhere is best[*]" should be Mozilla's default position for both
> clients and servers. It flows from this that mozilla hosted resources
> should be made available over https unless they have a some particular
> compelling reason not to be. I'm hoping we can get consensus on the
> principle of https hosting by default.
>
> First, I want to thank our ops team for the work they've been doing here -
> they have been doing great work getting things migrated to support https
> recently. Its been amazing - and it takes time - this is not a criticism of
> that process at all. As an example of good news, I recently filed a bug
> about the public suffix list not being served with https and they brought
> that up to speed much faster than I anticipated. Good stuff. Thank you!
>
> I'm talking about current and future projects that don't have https in
> their plans, but imo should. There are several that I could cite as
> examples. but I'm going to avoid doing so because I think it misses the
> larger point: user's confidentiality is better served by https than by
> http. Mozilla can lead on this and Individuals should be able to depend on
> us serving their interest. We know that cleartext is being abused out there.
>
> The best supporting argument here is principle 4 of the Manifesto:
> Individuals' security and privacy on the Internet are fundamental and must
> not be treated as optional. When framed like that the content does not
> matter - it is our place to do what we reasonably can to ensure their
> privacy during the act of consumption. https protects not only the security
> of the data, but it contributes to the confidentiality of the consumer. It
> is not perfect (today especially heartbleedingly so), but it is beneficial
> for transfers of even public data. By analogy, I am pleased that my public
> library does not log my borrowing history on a chalk board in the lobby -
> the books hold no secrets, but my choices in consumption are something I
> choose to keep confidential. (unless I browbeat you into reading one of my
> favorites :))
>
> No doubt we can nitpick the particulars - and there clearly are operational
> challenges here chiefly in managing the certs. I'm pretty familiar with all
> of the costs and I think we've already shown they are generally
> surmountable. But where there is pain I think its really important to
> embrace that pain and push for ways to make the open web operate better,
> rather than just side stepping the issues. This is important. Let's be
> awesome and lead. That's our raison d'etre, right?
>
> -Patrick
>
> [*] I often get a followup question of why firefox doesn't integrate https
> everywhere, the EFF add-on. The answer is that its not possible to really
> do this rewriting correctly and independently on the client side - but I'm
> really fond of the notion.
>

Would your site certificate chain to a generally-available, commercial
root?  Or do you propose that Mozilla create its own root for this?  In
the latter case, how would someone without a Mozilla-based browser -- a
browser whose developer chooses not to include the Mozilla root --
access your site?

--

David E. Ross
<http://www.rossde.com/>

On occasion, I filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam, flames, and trolling from that source.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Mozilla Hosting - HTTPS by default

Patrick McManus
I'm not making a special proposal about the cert - I would expect they
would come from normal broadly acceptable CAs and minted in the usual fee
for signature kind of way.


On Thu, Apr 10, 2014 at 2:58 PM, David E. Ross <[hidden email]>wrote:

> On 4/10/2014 8:26 AM, Patrick McManus wrote:
> > Hi Everyone - This post continues a side conversation on dev-planning
> which
> > started last week on yammer. My apologies for the to: line, it carries
> over
> > interested folks from the original discussion.
> >
> > The discussion was whether or not all Mozilla hosted web content should
> be
> > available over https by default. I am going to argue that some version of
> > "HTTPS everywhere is best[*]" should be Mozilla's default position for
> both
> > clients and servers. It flows from this that mozilla hosted resources
> > should be made available over https unless they have a some particular
> > compelling reason not to be. I'm hoping we can get consensus on the
> > principle of https hosting by default.
> >
> > First, I want to thank our ops team for the work they've been doing here
> -
> > they have been doing great work getting things migrated to support https
> > recently. Its been amazing - and it takes time - this is not a criticism
> of
> > that process at all. As an example of good news, I recently filed a bug
> > about the public suffix list not being served with https and they brought
> > that up to speed much faster than I anticipated. Good stuff. Thank you!
> >
> > I'm talking about current and future projects that don't have https in
> > their plans, but imo should. There are several that I could cite as
> > examples. but I'm going to avoid doing so because I think it misses the
> > larger point: user's confidentiality is better served by https than by
> > http. Mozilla can lead on this and Individuals should be able to depend
> on
> > us serving their interest. We know that cleartext is being abused out
> there.
> >
> > The best supporting argument here is principle 4 of the Manifesto:
> > Individuals' security and privacy on the Internet are fundamental and
> must
> > not be treated as optional. When framed like that the content does not
> > matter - it is our place to do what we reasonably can to ensure their
> > privacy during the act of consumption. https protects not only the
> security
> > of the data, but it contributes to the confidentiality of the consumer.
> It
> > is not perfect (today especially heartbleedingly so), but it is
> beneficial
> > for transfers of even public data. By analogy, I am pleased that my
> public
> > library does not log my borrowing history on a chalk board in the lobby -
> > the books hold no secrets, but my choices in consumption are something I
> > choose to keep confidential. (unless I browbeat you into reading one of
> my
> > favorites :))
> >
> > No doubt we can nitpick the particulars - and there clearly are
> operational
> > challenges here chiefly in managing the certs. I'm pretty familiar with
> all
> > of the costs and I think we've already shown they are generally
> > surmountable. But where there is pain I think its really important to
> > embrace that pain and push for ways to make the open web operate better,
> > rather than just side stepping the issues. This is important. Let's be
> > awesome and lead. That's our raison d'etre, right?
> >
> > -Patrick
> >
> > [*] I often get a followup question of why firefox doesn't integrate
> https
> > everywhere, the EFF add-on. The answer is that its not possible to really
> > do this rewriting correctly and independently on the client side - but
> I'm
> > really fond of the notion.
> >
>
> Would your site certificate chain to a generally-available, commercial
> root?  Or do you propose that Mozilla create its own root for this?  In
> the latter case, how would someone without a Mozilla-based browser -- a
> browser whose developer chooses not to include the Mozilla root --
> access your site?
>
> --
>
> David E. Ross
> <http://www.rossde.com/>
>
> On occasion, I filter and ignore all newsgroup messages
> posted through GoogleGroups via Google's G2/1.0 user agent
> because of spam, flames, and trolling from that source.
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Mozilla Hosting - HTTPS by default

Mike Hommey
In reply to this post by Patrick McManus-3
On Thu, Apr 10, 2014 at 11:26:22AM -0400, Patrick McManus wrote:

> Hi Everyone - This post continues a side conversation on dev-planning which
> started last week on yammer. My apologies for the to: line, it carries over
> interested folks from the original discussion.
>
> The discussion was whether or not all Mozilla hosted web content should be
> available over https by default. I am going to argue that some version of
> "HTTPS everywhere is best[*]" should be Mozilla's default position for both
> clients and servers. It flows from this that mozilla hosted resources
> should be made available over https unless they have a some particular
> compelling reason not to be. I'm hoping we can get consensus on the
> principle of https hosting by default.

Is performance a compelling reason? Because here's the problem: HTTPS adds a
significant overhead. Just connecting to www.mozilla.org takes more than 500ms
from where I am when connecting via HTTP takes about 120, because of the
additional roundtrips that SSL/TLS requires. I guess it's worse on 3G.

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

Re: Proposed Mozilla Hosting - HTTPS by default

Richard Barnes

On Apr 10, 2014, at 6:37 PM, Mike Hommey <[hidden email]> wrote:

> On Thu, Apr 10, 2014 at 11:26:22AM -0400, Patrick McManus wrote:
>> Hi Everyone - This post continues a side conversation on dev-planning which
>> started last week on yammer. My apologies for the to: line, it carries over
>> interested folks from the original discussion.
>>
>> The discussion was whether or not all Mozilla hosted web content should be
>> available over https by default. I am going to argue that some version of
>> "HTTPS everywhere is best[*]" should be Mozilla's default position for both
>> clients and servers. It flows from this that mozilla hosted resources
>> should be made available over https unless they have a some particular
>> compelling reason not to be. I'm hoping we can get consensus on the
>> principle of https hosting by default.
>
> Is performance a compelling reason? Because here's the problem: HTTPS adds a
> significant overhead. Just connecting to www.mozilla.org takes more than 500ms
> from where I am when connecting via HTTP takes about 120, because of the
> additional roundtrips that SSL/TLS requires. I guess it's worse on 3G.
>
> Mike
If it helps at all, users that connect multiple times should only get that cost the first time they connect.  (Thanks to TLS session restart.)

This is something we're trying to fix in TLS 1.3.

--Richard
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

smime.p7s (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Mozilla Hosting - HTTPS by default

Patrick McManus-3
In reply to this post by Mike Hommey
On Thu, Apr 10, 2014 at 6:37 PM, Mike Hommey <[hidden email]> wrote:

>
> > clients and servers. It flows from this that mozilla hosted resources
> > should be made available over https unless they have a some particular
> > compelling reason not to be. I'm hoping we can get consensus on the
> > principle of https hosting by default.
>
> Is performance a compelling reason?


imo in the general case client performance is not a reason to avoid https.
As an existence proof - If google can run search over primarily https,
then  mozilla.org ought to be able to handle the performance implications
too.

pro tips for servers:
* embrace OCSP stapling. This saves a whole separate http transaction
during the first handshake to a domain, generally at least 200ms. Often a
lot more.  A quick look shows it enabled on mozorg.cdn.mozilla.net but not
yet on mozilla.org
* Get ready for http/2 in early fall. Its going to completely eliminate
lots of handshakes, which are by far the slowest part of https. Setup
domains using wildcard certs when ever possible to encourage coalescing of
connections across origins.
* If you have big certs (a quick look shows that we do) make sure the
servers are using TCP IW10. It looks like ours are from a spot check.
* use NPN or ALPN and a ephemeral cipher suite to encourage false start -
even if you're just serving HTTP/1

If a server does this, there is just a 1 rtt  penalty on time to first byte
for https compared to http - and thanks to http/2 we will ramp up the
subresources MUCH faster. We could do this with spdy now, but given the
relative imminent standardization of http/2 waiting for that makes sense.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Mozilla Hosting - HTTPS by default

Reed Loden
https://istlsfastyet.com

~reed

On Thu, 10 Apr 2014 21:42:27 -0400
Patrick McManus <[hidden email]> wrote:

> On Thu, Apr 10, 2014 at 6:37 PM, Mike Hommey <[hidden email]> wrote:
>
> >
> > > clients and servers. It flows from this that mozilla hosted resources
> > > should be made available over https unless they have a some particular
> > > compelling reason not to be. I'm hoping we can get consensus on the
> > > principle of https hosting by default.
> >
> > Is performance a compelling reason?
>
>
> imo in the general case client performance is not a reason to avoid https.
> As an existence proof - If google can run search over primarily https,
> then  mozilla.org ought to be able to handle the performance implications
> too.
>
> pro tips for servers:
> * embrace OCSP stapling. This saves a whole separate http transaction
> during the first handshake to a domain, generally at least 200ms. Often a
> lot more.  A quick look shows it enabled on mozorg.cdn.mozilla.net but not
> yet on mozilla.org
> * Get ready for http/2 in early fall. Its going to completely eliminate
> lots of handshakes, which are by far the slowest part of https. Setup
> domains using wildcard certs when ever possible to encourage coalescing of
> connections across origins.
> * If you have big certs (a quick look shows that we do) make sure the
> servers are using TCP IW10. It looks like ours are from a spot check.
> * use NPN or ALPN and a ephemeral cipher suite to encourage false start -
> even if you're just serving HTTP/1
>
> If a server does this, there is just a 1 rtt  penalty on time to first byte
> for https compared to http - and thanks to http/2 we will ramp up the
> subresources MUCH faster. We could do this with spdy now, but given the
> relative imminent standardization of http/2 waiting for that makes sense.
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Mozilla Hosting - HTTPS by default

Julien Vehent-2
In reply to this post by Patrick McManus-3
Hi Patrick,

Jake and I spent a lot of time over the last year working on improving
the server side SSL at Mozilla. Most of it is captured in bug 901393 and
subs, and this wiki page: https://wiki.mozilla.org/Security/Server_Side_TLS

I added a few comments on the specifics below.

- Julien

On Thu 10.Apr'14 at 21:42:27 -0400, Patrick McManus wrote:

> On Thu, Apr 10, 2014 at 6:37 PM, Mike Hommey <[hidden email]> wrote:
>
> >
> > > clients and servers. It flows from this that mozilla hosted resources
> > > should be made available over https unless they have a some particular
> > > compelling reason not to be. I'm hoping we can get consensus on the
> > > principle of https hosting by default.
> >
> > Is performance a compelling reason?
>
>
> imo in the general case client performance is not a reason to avoid https.
> As an existence proof - If google can run search over primarily https,
> then  mozilla.org ought to be able to handle the performance implications
> too.

Google gets fast ECDHE performance using OpenSSL and optimized NIST
curves [1]. Our SSL termination, Riverbed Stingray (ZLB), doesn't yet support
ECDHE. But we have an ongoing relationship with the dev team at Riverbed
to get it deployed later this year.

[1] http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html

> pro tips for servers:
> * embrace OCSP stapling. This saves a whole separate http transaction
> during the first handshake to a domain, generally at least 200ms. Often a
> lot more.  A quick look shows it enabled on mozorg.cdn.mozilla.net but not
> yet on mozilla.org

Brian Smith had a plan for deploying OCSP Stapling in Firefox. Do you
know what happened to that? Can you share a timeline?

On the infra side, we have a version of ZLB that supports OCSP Stapling
that is deployed in Mozilla Labs. This version is not yet deployed on
our main production, but it's in the pipe. Since it's a major version
upgrade, Jake and his team at webops need to allocate extra time for
testing and deployment.

It would be truly awesome to synchronize the deploy of OCSP Stapling
on the infra side, with the release in Firefox. Let's work together on
that.

> * Get ready for http/2 in early fall. Its going to completely eliminate
> lots of handshakes, which are by far the slowest part of https. Setup
> domains using wildcard certs when ever possible to encourage coalescing of
> connections across origins.

The folks at Riverbed have expressed interest in working with us to test
and deploy HTTP/2 asap. I'm happy to introduce you to them if you'd like.

> * If you have big certs (a quick look shows that we do) make sure the
> servers are using TCP IW10. It looks like ours are from a spot check.
> * use NPN or ALPN and a ephemeral cipher suite to encourage false start -
> even if you're just serving HTTP/1
>
> If a server does this, there is just a 1 rtt  penalty on time to first byte
> for https compared to http - and thanks to http/2 we will ramp up the
> subresources MUCH faster. We could do this with spdy now, but given the
> relative imminent standardization of http/2 waiting for that makes sense.

As far as SPDY goes, I don't think Riverbed will implement it this year.
I *think* they want to focus on HTTP/2. But that's a guess.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Proposed Mozilla Hosting - HTTPS by default

Daniel Veditz-2
On 4/10/2014 8:31 PM, Julien Vehent wrote:
> Brian Smith had a plan for deploying OCSP Stapling in Firefox. Do you
> know what happened to that? Can you share a timeline?

AFAIK we've supported stapling for a while. Mozilla 25 it looks like
(surprising, thought it was earlier)
https://bugzilla.mozilla.org/show_bug.cgi?id=700698

There are still some revocation improvements in the works but stapling
shouldn't be a worry.

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

Re: Proposed Mozilla Hosting - HTTPS by default

Julien Vehent-2
On Thu 10.Apr'14 at 23:54:11 -0700, Daniel Veditz wrote:

> On 4/10/2014 8:31 PM, Julien Vehent wrote:
> >Brian Smith had a plan for deploying OCSP Stapling in Firefox. Do you
> >know what happened to that? Can you share a timeline?
>
> AFAIK we've supported stapling for a while. Mozilla 25 it looks like
> (surprising, thought it was earlier)
> https://bugzilla.mozilla.org/show_bug.cgi?id=700698
>
> There are still some revocation improvements in the works but stapling
> shouldn't be a worry.

Right, I should have been more clear. The proposed change was to make
OCSP Stapling a requirement to the green bar of EV certificates, in
order to drive adoption, and disable classic OCSP entirely since it's
not really used. On the infra side, we discussed supporting that change
by having OCSP Stapling enabled on as many Mozilla properties as
possible when the change goes live.

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

Re: Proposed Mozilla Hosting - HTTPS by default

Henri Sivonen-2
In reply to this post by Zack Weinberg-2
> On 04/10/2014 11:26 AM, Patrick McManus wrote:
>> The discussion was whether or not all Mozilla hosted web content
>> should be available over https by default. I am going to argue that
>> some version of "HTTPS everywhere is best[*]" should be Mozilla's
>> default position for both clients and servers. It flows from this
>> that mozilla hosted resources should be made available over https
>> unless they have a some particular compelling reason not to be. I'm
>> hoping we can get consensus on the principle of https hosting by
>> default.

I support this. I even think "by default" is putting it too mildly. I
think the only thing port 80 should do is to redirect to https and the
https side should use HSTS with includeSubDomains. (It follows that if
we want to host non-https test cases, we should probably have a
different domain for hosting those.)

On Thu, Apr 10, 2014 at 7:58 PM, Zack Weinberg <[hidden email]> wrote:
> There may need to be a small handful of exceptions - the only thing
> that comes to mind is that the path from 'mozilla.org' to initial
> Firefox download *might* need to be accessible over plain HTTP for the
> sake of people stuck without any usable HTTPS client.

In what circumstance would that be the case, realistically?

As long as we support XP, we should make sure that the download path
works in IE on XP. For IE8 on XP, it means making sure to enable TLS
1.0 and TLS_RSA_WITH_3DES_EDE_CBC_SHA on the download path. For IE6 on
XP, it means also enabling SSL3. If the https download path has those
enabled, I don't see a reason to have a non-https download path from
www.mozilla.org.

(Yes, I'm aware that instead of TLS_RSA_WITH_3DES_EDE_CBC_SHA one
might instead enable TLS_RSA_WITH_RC4_128_SHA to avoid 3DES being used
as a DoS vector, but enabling RC4 at all these days seems wrong.)
--
Henri Sivonen
[hidden email]
https://hsivonen.fi/
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12