Proposed Mozilla Hosting - HTTPS by default

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

Re: Proposed Mozilla Hosting - HTTPS by default

Zack Weinberg-2
On 2014-04-11 8:28 AM, Henri Sivonen wrote:
> 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?

I didn't have one in mind, which is why I said "might".  As far as I
know all of the still-supported platforms ship with at least one browser
that can do vaguely modern HTTPS, but there might be a situation I don't
know about.

Right now, if I type "www.mozilla.org" into OSX 10.6 Safari (which is
the oldest thing I have convenient), I get an unencrypted page, but the
download-Firefox link on that page points to an HTTPS URL:

https://download.mozilla.org/?product=firefox-28.0-SSL&os=osx&lang=en-US

... and presumably that's working fine, so that's at least evidence in
favor of "we could go ahead and mandate HTTPS."  Yay.

zw

_______________________________________________
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-3
In reply to this post by Julien Vehent-2
On Thu, Apr 10, 2014 at 11:31 PM, Julien Vehent <[hidden email]> wrote:

>
>
> 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.
>
>
that's awesome to hear.



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


[the thread later goes on to clarify that firefox supports stapling right
now.]

the question might best be directed to {sid, brian, david keeler} to give
an update on the plan for ending out of band revocation checking.  But from
a server perspective nothing will be gained by waiting - the performance
carrot is in place right now so I wouldn't wait to synchronize.


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


splendid!

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.
>
>
yes please - cc :hurley too. our latest -draft support is available in
nightly behind a about:config pref, but I'm more than happy to do interop
tests.
_______________________________________________
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 Zack Weinberg-2
On 2014-04-11, at 06:29, Zack Weinberg <[hidden email]> wrote:

> evidence in favor of "we could go ahead and mandate HTTPS."  Yay.

What other evidence do people consider necessary?  Because implementing HSTS, hard redirects and all, would be ideal.
_______________________________________________
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
In reply to this post by Julien Vehent-2
On 4/11/2014 2:40 AM, Julien Vehent wrote:

> On Thu 10.Apr'14 at 23:54:11 -0700, Daniel Veditz wrote:
>> 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.

Why would client plans delay a server roll out? Obviously we'll want our
servers upgraded "no later than" the Firefox changes, but I see no
benefit to waiting just because Firefox isn't ready. Wouldn't it be
easier to upgrade servers as you can get to it rather than have to "big
bang" them all around a particular client release?

-Dan
_______________________________________________
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 Fri 11.Apr'14 at 10:55:32 -0700, Daniel Veditz wrote:
> Why would client plans delay a server roll out?

On Fri 11.Apr'14 at 10:59:50 -0400, Patrick McManus wrote:
> from a server perspective nothing will be gained by waiting - the
> performance carrot is in place right now so I wouldn't wait to
> synchronize.

A bit more context & historical information may answer some of your
questions.

OCSP Stapling has been on our radar since last summer (bug 896078).
Early on, we involved Riverbed in the discussion, and came up with a
roadmap. They delivered support in version 9.5 of Riverbed Stingray (the
official product name for ZLB), released 3 months ago. We did some
initial testing in Labs, and shared results with them. They came back to
us 3 weeks ago with a new release that improves OCSP responses checking.
Now we need to iterate on testing, and schedule deployment in
production.

That is to say: we have been busy. OCSP Stapling is part of a larger
ongoing plan to improve SSL/TLS support on the server side [1], across
several hundreds of services, and many different infrastructures. As you
can imagine, the load balancers at the head of our two major
data-centers are highly critical pieces of equipment, and upgrading
requires preparation, testing, QA, downtime for release and so on. The
risk of impacting the uptime of these services is a strong factor in any
deployment decision. This is the reason behind the conservative, but
steady, progress.

When I mentioned synchronizing OCSP Stapling changes, what I really
meant is creating momentum to focus more people on it, and accelerating
adoption. Riverbed appreciates being part of our plans for Firefox. They
have been hard at work on their SSL stack to support our effort and
better serve their other customers. On the infrastructure side, we need
roadmap visibility as well, so we can prioritize appropriately (there
are many other projects in the queue), and have OCSP Stapling enabled
when Firefox makes it a requirement.

- Julien

[1] https://blog.mozilla.org/security/2013/11/12/navigating-tls/
_______________________________________________
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

Stefan Arentz-5
In reply to this post by Doug Turner-4

On Apr 10, 2014, at 11:54 AM, Doug Turner <[hidden email]> 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.

Or maybe better, reach out to the Cloud Services team, in which Yvan’s team, Web App (& Services) Security, was merged. We actually officially deal with web app security on a day to day basis and are always happy to explain, assist, review, encourage :-)

So I think SSL-MOST-OF-THE-THINGS is a nobel goal and we should absolutely go for it.

But, I think the bigger story has to start sooner and broader, because as Doug says, there are a whole bunch of other technologies, and coding practices, that we need to embrace in a bigger way than we currently do.

Couple of thoughts on that:

* Related to SSL and STS, I think one of the things we are doing mostly wrong now is have development and staging servers that run with a different set of parameters than the production servers. Often we think, oh those headers and SSL that will be IT/Ops responsibility. Nope. That needs to change. Those headers and proper testing with SSL needs to be part of development and staging and day to day development.

* If we can add headers now to existing sites is great, but security cannot be an afterthought. For example, you can’t properly add CSP at the end of the development cycle. You will get burned if you don’t think about CSP *before* you start writing your first line of code or pick you JS frameworks, I think we need more education for teams and individual developers.

* I think we need to move to a situation where we actually *require* new sites and services to conform to a specific set of security and deployment rules. And if you can’t justify why you don’t meet those security expectations, your site or app or api cannot go live. I don’t think we have been strict enough in the past.

I’m not joking about the last part. We really need to be better.

Needless to say, the AppSec team will also have to do some heavy thinking about  improving this situation.

 S.

_______________________________________________
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

Yvan Boily-2
Hi All,

Sorry for the lag time on this, but I have been a proponent for my team taking a stronger engineering focus for quite some time (see our security automation focus and other activities over the last several years), and while we have a broad scope of responsibilities and need to address those, I would very much like to support not just the roll out of HSTS, but CSP initially on our high value properties, but also in all properties.

At the web security meeting tomorrow morning (Cloud Services security team still works on web security for everyone!), we will identify a person to drive a strategy for both STS and CSP, and then pull together people who have commented on this thread to make sure we get the right people involved in pushing both efforts forward.  Rather than saying include me, hold off until tomorrow, and we will post some additional info about getting engaged on these efforts.

Cheers,
Yvan

----- Original Message -----
From: "Stefan Arentz" <[hidden email]>
To: "Doug Turner" <[hidden email]>
Cc: "Anne van Kesteren" <[hidden email]>, "Patrick McManus" <[hidden email]>, [hidden email], [hidden email], "Sid Stamm" <[hidden email]>, "Jake Maul" <[hidden email]>, "mozilla.dev.planning group" <[hidden email]>, "Richard Barnes" <[hidden email]>, "Julien Vehent" <[hidden email]>, "Daniel Veditz" <[hidden email]>, [hidden email], "yboily" <[hidden email]>
Sent: Friday, April 11, 2014 6:46:39 PM
Subject: Re: Proposed Mozilla Hosting - HTTPS by default


On Apr 10, 2014, at 11:54 AM, Doug Turner <[hidden email]> 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.

Or maybe better, reach out to the Cloud Services team, in which Yvan’s team, Web App (& Services) Security, was merged. We actually officially deal with web app security on a day to day basis and are always happy to explain, assist, review, encourage :-)

So I think SSL-MOST-OF-THE-THINGS is a nobel goal and we should absolutely go for it.

But, I think the bigger story has to start sooner and broader, because as Doug says, there are a whole bunch of other technologies, and coding practices, that we need to embrace in a bigger way than we currently do.

Couple of thoughts on that:

* Related to SSL and STS, I think one of the things we are doing mostly wrong now is have development and staging servers that run with a different set of parameters than the production servers. Often we think, oh those headers and SSL that will be IT/Ops responsibility. Nope. That needs to change. Those headers and proper testing with SSL needs to be part of development and staging and day to day development.

* If we can add headers now to existing sites is great, but security cannot be an afterthought. For example, you can’t properly add CSP at the end of the development cycle. You will get burned if you don’t think about CSP *before* you start writing your first line of code or pick you JS frameworks, I think we need more education for teams and individual developers.

* I think we need to move to a situation where we actually *require* new sites and services to conform to a specific set of security and deployment rules. And if you can’t justify why you don’t meet those security expectations, your site or app or api cannot go live. I don’t think we have been strict enough in the past.

I’m not joking about the last part. We really need to be better.

Needless to say, the AppSec team will also have to do some heavy thinking about  improving this situation.

 S.

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