Closed Bug 796109 Opened 12 years ago Closed 10 years ago

make www.mozilla.org SSL-only (discussion needed)

Categories

(www.mozilla.org :: General, defect)

Product:
www.mozilla.org
Component:
General
Platform:
All
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: nmaul, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: sec-want, Whiteboard: [triaged 20121005][waiting][qa][webdev]) 

As part of stub installer delivery, we'd like to make the entire chain of connections to downloading the stub installer happen over SSL.

One of the steps is that the initial download link should be served up over SSL. That means for ideal security www.mozilla.org should be forced to https://, and should (ideally) set an "HTTP Strict Transport Security" header to try and preserve this as long as is feasible.

Before we just go ahead and do this, does anyone have any concerns about doing so?


One potential issue raised in bug 796057... an HTTPS page that redirects to an HTTP page may be problematic in some browsers. This may not be an issue here, but it's part of the whole chain and thus I think worth mentioning. The download button is technically throwing a javascript redirect, I think. This might be a moot point, but I think it's worth double-checking before we do this.
Blocks: 796103
I'd like to hear from at least opsec, webdev, and QA on this before we make the change, to see if anyone has any concerns about it.

Once all 3 groups are happy doing this, it's a relatively simple change for WebOps to implement it.
Flags: sec-review?
We need to find out if IE would bark at the https > http links if JavaScript makes them pop. If mozilla.org is all https and d.m.o is all https and it hands off to an http CDN, I don't know if it would pop a warning.
I don't have a lot of concern for switching mozilla.org to HTTPS. The only issue that I can think of is the download button and the problem on this is the HTTPS bouncer -> HTTP CDN redirect. That's tracked in bug 796057.

Can we enable HTTPS only on dev and stage so that we can check how this behaves?
Great idea, that's done now... www-dev.allizom.org and www.allizom.org (and as a side effect, all 3 of www-demoX.allizom.org) redirect to HTTPS now.
Flags: sec-review? → sec-review?(jstevensen)
All: We are getting mixed content warnings on IE 6 and 7 when Mozilla.org is HTTPS. We are viewing the network log and we see only HTTPS/:443 traffic and do not see where the mixed content is coming from. The mixed content dialog box is not preventing any downloads, but it may throw some users off and affect the conversion rate.

What if we don't force HTTPS on www.mozilla.org and just force download.mozilla.org? It can't be any worse than what we have now AND we are not creating a scenario where users are presented "scary" warnings in IE and especially when going from HTTPS to HTTP for full installers on the CDN. We shouldn't get a warning from going from HTTP to HTTPS as the inverse is usually what causing the IE warning. 

As for reference, Chrome's page is HTTPS and their downloads are served up via HTTPS/SSL. 

Raymond: As a reference point, can you go to this page in IE 6 and see what the experience is like in terms of any content warnings?

https://www.google.com/intl/en/chrome/browser/
We need to find out what objects are being delivered over non-SSL connections if we hope to solve a mixed-mode warning.

Would someone be able to set up Wireshark or some other packet capturing and watch outbound connections to port 80 when using IE6 or 7? I don't know if there's a suitable way to find out this information in old-IE itself.
(In reply to Jake Maul [:jakem] from comment #6)
> We need to find out what objects are being delivered over non-SSL
> connections if we hope to solve a mixed-mode warning.
> 
> Would someone be able to set up Wireshark or some other packet capturing and
> watch outbound connections to port 80 when using IE6 or 7? I don't know if
> there's a suitable way to find out this information in old-IE itself.

Use http://www.fiddler2.com/fiddler2/
(In reply to Brandon Burton [:solarce] from comment #7)
> (In reply to Jake Maul [:jakem] from comment #6)
> > We need to find out what objects are being delivered over non-SSL
> > connections if we hope to solve a mixed-mode warning.
> > 
> > Would someone be able to set up Wireshark or some other packet capturing and
> > watch outbound connections to port 80 when using IE6 or 7? I don't know if
> > there's a suitable way to find out this information in old-IE itself.
> 
> Use http://www.fiddler2.com/fiddler2/

Raymond used fliddler2 on IE6 it and it say it was all served up via port 443. 

Jake: What is the benefit of forcing HTTPS on mozilla.org? We know that the CDNs are not going to be SSL anytime soon. IE only barks at users when going from HTTPS to HTTP and thus we are creating a lousy UX situation for not much gain since it is not end-to-end SSL. We are not using SSL now so it is not worse than what we have now, but it would be if IE users were presented a warning.
I've confirmed with Fiddler2 and Wireshark that IE7 does *not* in fact may any connections to port 80 when accessing https://www.mozilla.org/en-US/, to any server (which is just us and webtrends, but both are always port 443).

However, in the course of investigating this a number of flaws in IE6 and 7's mixed-content detection have become apparent that I was not aware of. Put simply, they mis-detect various things as being insecure, and throw the warning spuriously.


http://stackoverflow.com/questions/5030838/mixed-content-warnings-in-ie7-caused-by-javascript-and-images
"
Other quirks to be aware of: In IE6, we treat "about:blank" as insecure content, as well as "javascript:" and "res:". In IE7, we fixed the "about:blank" case, but we have not (yet) changed javascript and res.
"

http://robm.fastmail.fm/articles/ie7-dataurl.html
https://github.com/Modernizr/Modernizr/issues/218
"data:" URLs are marked as insecure in IE7, but not IE6 or 8+


These appear to be the main concerns regarding mixed-content warnings in IE6 and 7:
about:blank
javascript:
res:
data:

Craig has indicated that we do use data: in some places, so that's a possible culprit in our situation.
@cmore: the benefit to forcing SSL on www.mozilla.org is that it's one less layer to worry about. I'm not qualified to say if skipping it is acceptable, but here's the reasoning:

We want to ensure that the stub installer (really any installer, but particularly stub installer is the goal) that users download is genuine....

1) The mirror it fetches from must obviously must be SSL-aware and trusted by us.

2) The link *to* that mirror (download.mozilla.org) should also be SSL aware and trusted by us... else that proper mirror link could be intercepted and rewritten via a man-in-the-middle attack, directing you to an evil installer.

3) The link to d.m.o (primarily www.mozilla.org, among others) should therefore be trusted as well. If it's not, a man-in-the-middle attack could conceivable alter the download links to point somewhere other than download.mozilla.org, and thus serve a bad installer instead of the official one.

4) Outside of our control is how people are directed to download Firefox in the first place. https://www.mozilla.org/ is best, straight to an official SSL mirror is less good but still secure... self-hosting an installer is not good.

They're just links in a chain. How far up the chain we want to travel is discretionary. #1 is required, #2 is strongly recommended (and already done), #3 is this bug. I believe it's worthwhile, but others might disagree.


The only way to guarantee the integrity of the download is if the whole chain is accessed over SSL.

(Note that I say "guarantee", but it's really not guaranteed even then... if you access http://www.mozilla.org/ but your DNS is being hijacked, you could go to a totally different site, never get an SSL redirect, and be served a bad installer. That's a DNS-SEC issue, and out of scope for what we're trying to do here.)
Here's an off-the-wall idea, since it's looking like fixing the mixed-content warnings on IE6 and 7 are non-trivial to fix... what if we redirect to https://www.mozilla.org/ for only a subset of browsers? Chrome, Safari, IE8+, Firefox... or maybe the inverse, redirect for everything but IE6/7.

We could probably implement this with User-Agent sniffing in Apache or Zeus (load balancer), but it might be better done in the code... I know UA sniffing is non-ideal for browser detection.

This seems better than not redirecting at all, but is perhaps not good enough. Opsec would have to weigh in on that decision, I think.
(In reply to Jake Maul [:jakem] from comment #11)
> Here's an off-the-wall idea, since it's looking like fixing the
> mixed-content warnings on IE6 and 7 are non-trivial to fix... what if we
> redirect to https://www.mozilla.org/ for only a subset of browsers? Chrome,
> Safari, IE8+, Firefox... or maybe the inverse, redirect for everything but
> IE6/7.
> 
> We could probably implement this with User-Agent sniffing in Apache or Zeus
> (load balancer), but it might be better done in the code... I know UA
> sniffing is non-ideal for browser detection.
> 
> This seems better than not redirecting at all, but is perhaps not good
> enough. Opsec would have to weigh in on that decision, I think.

I was just thinking about the same thing. If the stub installer is on an SSL resource, we should be fine with not getting mixed content issue. The issue is that if you are running IE 6-7 on non-en-US browsers and you download Firefox, you will get the full installer from a non-SSL CDN connection. What if we only forced SSL for en-US + Windows for the time being? 

Raymond and Craig found out how the mixed content issue is happening on Mozilla.org and it has to do with data:uri's in IE6 considered non-secure by default and we have an idea on how to resolve it. Regardless of that situation, we are going to have the "leading an https" error in IE when a download redirects to a non-SSL CDN.
Assignee: server-ops-webops → nmaul
Flags: needinfo?
Whiteboard: [triaged 20121005][waiting][opsec][qa][webdev]
I'm catching up on everything that happened so maybe I'm missing a part.

In general, I'm not in favor of introducing specific browser cases. We've seen in the past that this is just asking for trouble. This introduces a lot of paths to test for QA. So we should try and fix those data: uris as much as we can.
Flags: needinfo?
I'm catching up on this now.

Defintely in favor of moving www.mozilla.org to SSL. However, we need to discuss how to handle IE6/7. I'll circle back with mcoates on this.
We discovered the SSL issues with IE6/7 was because of data:uri issues that craigcook is resolving in tabzilla. The other issue is that redirects to a non-SSL CDN will pop an IE warning which is not a good UX.
(In reply to Chris More [:cmore] from comment #15)
> The other issue is that redirects to a
> non-SSL CDN will pop an IE warning which is not a good UX.

This might be a decent argument for serving *all* installers over SSL, which is easily possible... however someone would need to go through bouncer and tick the new "SSL only" checkbox for every installer product, and someone would need to sign off on the financial impact.

To be clear, this primarily affects people who don't have a stub installer for their locale/platform. SI-eligible users will get an SSL mirror, avoiding that particular mixed-content issue. Once SI is usable for all locales on Windows, that should largely resolve almost completely. Other browsers/platforms may have similarly bad UX in this scenario, but I am not aware of any at this time.
(In reply to Jake Maul [:jakem] from comment #16)
> (In reply to Chris More [:cmore] from comment #15)
> > The other issue is that redirects to a
> > non-SSL CDN will pop an IE warning which is not a good UX.
> 
> This might be a decent argument for serving *all* installers over SSL, which
> is easily possible... however someone would need to go through bouncer and
> tick the new "SSL only" checkbox for every installer product, and someone
> would need to sign off on the financial impact.
> 
> To be clear, this primarily affects people who don't have a stub installer
> for their locale/platform. SI-eligible users will get an SSL mirror,
> avoiding that particular mixed-content issue. Once SI is usable for all
> locales on Windows, that should largely resolve almost completely. Other
> browsers/platforms may have similarly bad UX in this scenario, but I am not
> aware of any at this time.

Yeah, this change is more of a financial than technical issue. We can do it end-to-end, but people need to agree if the cost is worth the added security.
(In reply to Chris More [:cmore] from comment #17)
> Yeah, this change is more of a financial than technical issue. We can do it
> end-to-end, but people need to agree if the cost is worth the added security.


Let's revisit after stub installer is finished.  While this is desirable it is unrelated to SI and we shouldn't over complicate the current focus.
Removing stub installer blocker for clarity.
No longer blocks: 796103
Blocks: 801970
Blocks: 358384
Keywords: sec-want
(In reply to Jake Maul [:jakem] from comment #11)
> Here's an off-the-wall idea, since it's looking like fixing the
> mixed-content warnings on IE6 and 7 are non-trivial to fix... what if we
> redirect to https://www.mozilla.org/ for only a subset of browsers? Chrome,
> Safari, IE8+, Firefox... or maybe the inverse, redirect for everything but
> IE6/7.

Search engines and users of other browsers will will increasingly give HTTPS links to IE users.  So we'll need to work around the IE bug anyway.  Is there a bug for that?
CraigCook: Is there a bug for making the tabzilla stuff include real images instead of data URI's to get around the IE content issues?
(In reply to Chris More [:cmore] from comment #12)
> Regardless of that
> situation, we are going to have the "leading an https" error in IE when a
> download redirects to a non-SSL CDN.

Sorry for butting in, but I don't understand how any redirect HTTPS -> HTTP is consistent with the goal of delivering the installer over HTTPS. The only part of the download that should be served over HTTP (not HTTPS) is the download of the MAR, which is done but the stub installer itself, not by any browser. Everything else is supposed to be HTTPS, as far as I understand the goal.

(In reply to Jake Maul [:jakem] from comment #10)
> (Note that I say "guarantee", but it's really not guaranteed even then... if
> you access http://www.mozilla.org/ but your DNS is being hijacked, you could
> go to a totally different site, never get an SSL redirect, and be served a
> bad installer. That's a DNS-SEC issue, and out of scope for what we're
> trying to do here.)

You can avoid this in Firefox and Chrome by having www.mozilla.org addded to their preloaded HSTS lists. Then the redirect http -> https will happen internally. However, you must be really committed to HSTS on those domains--in particular, you should not have ANY mixed content other than images and HTML5 audio/video.

Before making www.mozilla.org HSTS, make sure you are happy with the SSL behavior of YouTube embeddings, whatever traffic analytics we're using, and similar. (Does Google guarantee that YouTube videos can be embedded using only SSL.)

Also note that Firefox itself is getting much more strict about mixed content soon (hopefully for Firefox 19); see bug 782654.
(In reply to Brian Smith (:bsmith) from comment #22)
> (In reply to Chris More [:cmore] from comment #12)
> > Regardless of that
> > situation, we are going to have the "leading an https" error in IE when a
> > download redirects to a non-SSL CDN.
> 
> Sorry for butting in,

No problem! That's why I opened this bug in the first place. :)

> but I don't understand how any redirect HTTPS -> HTTP
> is consistent with the goal of delivering the installer over HTTPS. The only
> part of the download that should be served over HTTP (not HTTPS) is the
> download of the MAR, which is done but the stub installer itself, not by any
> browser. Everything else is supposed to be HTTPS, as far as I understand the
> goal.

The immediate goal is to deliver *stub* installer over HTTPS... not all full installers. Since stub installer is Windows-only (and currently en-US only as well), there's a large chunk of installer downloads that would still happen over HTTP.

Comment 16, 17, and 18 deal with this specifically.


> (In reply to Jake Maul [:jakem] from comment #10)
> > (Note that I say "guarantee", but it's really not guaranteed even then... if
> > you access http://www.mozilla.org/ but your DNS is being hijacked, you could
> > go to a totally different site, never get an SSL redirect, and be served a
> > bad installer. That's a DNS-SEC issue, and out of scope for what we're
> > trying to do here.)
> 
> You can avoid this in Firefox and Chrome by having www.mozilla.org addded to
> their preloaded HSTS lists. Then the redirect http -> https will happen
> internally. However, you must be really committed to HSTS on those
> domains--in particular, you should not have ANY mixed content other than
> images and HTML5 audio/video.

I don't know what % of our installer downloads come from Firefox pave-over installs or from Chrome. I would speculate that most alternative browser downloads are going to come from the platform-default-browser... IE, Safari, Konqueror, etc... which means ultimately we simply cannot guarantee this until everyone has a preloaded list and www.mozilla.org is on all of them. Even then it's no guarantee your current browser hasn't been messed with by malware.

There are a lot of loopholes in the chain and none of the solutions really plug all of them.

In any case, HSTS and a preloaded list entry would definitely come along for the ride, if/when we were to implement an http->https redirect. For now it's just a question of what will it take to make that feasible.
Moving this to www.mozilla.org product, as it's out of IT's hands for the time being. My impression is that there's a decent amount of webdev work that needs to happen before it's feasible to force HTTPS.
Component: Server Operations: Web Operations → General
Product: mozilla.org → www.mozilla.org
Assignee: nmaul → nobody
QA Contact: cshields
What kind of webdev work?  (Or, who would know?)
Tabzilla's data URI's blocker for mozilla.org forced SSL is resolved and not blocking this anymore: https://github.com/mozilla/tabzilla/pull/45

We will need to evaluate what other parts of mozilla.org will need to be changed to be able to have the server force SSL and not throw errors.

This is lowered priority due to focusing on bedrock infrastructure changes.
Flags: sec-review?(jstevensen)
Whiteboard: [triaged 20121005][waiting][opsec][qa][webdev] → [triaged 20121005][waiting][qa][webdev]
Blocks: mozorg-redirects
As a short-term solution, can we set a Strict-Transport-Security header on mozilla.org, which will instruct clients to start using HTTPS? This is compatible with all modern versions of Firefox/Chrome. IE ignores it the header, so it shouldn't cause any incompatibilities there.
Ok, we may be ready to go here. All the blockers of bug 358384 are now resolved. Are we ready to force SSL on mozilla.org now? If not, there should be a bug filed on why we can't.

pmac/jgmize: ?
Flags: needinfo?(pmac)
No longer blocks: 358384
Depends on: 358384
Blocks: 938566
Blocks: 358384
No longer depends on: 358384
As far as I know we are indeed unblocked. I'll look a bit harder and try to verify, but in theory I agree with you; that we're in a position to just do it and fix things as we discover them.
Flags: needinfo?(pmac)
pmac: find anything? Maybe we should just force SSL and monitor Google Analytics, input.mozilla.org, and new relic for errors. If you are good, can you file a webops bug to have the change made and have it block this bug? thx!
Flags: needinfo?(pmac)
I'm thinking maybe we just do this in bedrock. We could force the whole thing, but I'm a lot less confident in the PHP side being good for SSL than bedrock. Do you know if we need the PHP side to be as well? If it's not as big a deal, maybe we can ignore that part until it's gone?
Flags: needinfo?(pmac)
(In reply to Paul McLanahan [:pmac] from comment #32)
> I'm thinking maybe we just do this in bedrock. We could force the whole
> thing, but I'm a lot less confident in the PHP side being good for SSL than
> bedrock. Do you know if we need the PHP side to be as well? If it's not as
> big a deal, maybe we can ignore that part until it's gone?

I would be fine with doing it on bedrock and making the non-SSL php pages another reason to get rid of them. Once PHP is no more, would you move this logic to apache and out of bedrock? The only php page that really should be SSL when we make bedrock SSL-only is http://www.mozilla.org/en-US/products/download.html?product=firefox-30.0-SSL&os=osx&lang=en-US.

Non-direct bedrock buttons still point to the /locale/products/download.html page, which is on php and I would like to avoid going from HTTPS to HTTP on that particular php page. What about if we force bedrock to SSL and then do an apache rule specifically for the /locale/products/download.html page?
Flags: needinfo?(pmac)
That's a great point Chris. Let's just do the whole thing and file bugs for the broken bits. I can't imagine that it's much, and I just tested the /products/download.html page and it's fine over SSL.

So we can do the Apache thing in the bedrock codebase since we have apache config files in there. I'll get a PR for this in ASAP.
Flags: needinfo?(pmac)
Or I guess Ops can/should do it in Zeus. I'll file the bug.
Depends on: 1032971
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Depends on: 1068413
You need to log in before you can comment on or make changes to this bug.