252676 - configure update.mozilla.org to use ssl

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[chris hofmann]

this is to track getting the server, setting up tomcat, getting certs, reviewing
the security set up, etc...  for firefox 1.0

Comment 1

[chris hofmann]

it would be good if we could get aviary1.0 flags on this bug to help in tracking

Comment 2

[Daniel (Leaf) Nunes]

tomcat is running on rodan (currently still update.mozilla.org); i'll try and
get a thawte cert bundle for these services.

For update, do we want *everything* over ssl, or just certain pages (requiring
auth for packages to be uploaded, for instance)?

Comment 3

[alanjstr]

Once you're logged in, at least for UMO admin, you don't get re-authentiicated.
 I'd say only the login piece and the profile editor should be secured.

Comment 4

[Daniel Veditz [:dveditz]]

Is that really how http-auth works? I think the browser is sending the
authentication on each page on your behalf.

In any case, whether it's sending the auth or some session token, due to the fix
for bug 226278 you can't authenticate over SSL and then interact over non-SSL,
it'll request re-authentication which defeats the purpose of using SSL in the
first place (to prevent password stealing as remote admins maintain the site on
wireless or campus networks, etc.).

In addition to the admin interface, the update SOAP interface must be secured so
that an attacker can't hack a victim's DNS and send them bogus "you need an
update" data.  Possibly easiest just to secure the entire site (the large
package downloads themselves come from the ftp server).

Comment 5

[alanjstr]

We're not using http auth for the backend, except as a temporary measure.  I
don't think the regular site should be secured, since that would be unnecessary
strain on the cpu.  

Comment 6

[Wolf [:wolf]]

The developer/admin back-end uses cookie-based sessions.. not HTTP-Auth. There's
HTTP Auth protecting the work-in-progress version that's up now, which is not
the final version that'll be up for Firefox 1.0, so the few who need access to
it, can get in, and keep out the masses.

The easiest is probably to secure the whole site, most users would access the
regular front-end on the regular HTTP port anyway, just have to make sure that
the back-end on the non-SSL port redirects to the SSL, so that the SSL version
is the only access point.

Comment 7

[Daniel Veditz [:dveditz]]

There are two issues, securing admin access is only one (risk: hackers steal a
password and hack our repository). The other is that the update URL every client
will regularly ping must be SSL to prevent DNS spoofers from redirecting some
population (a campus network? an internet cafe?) to a set of fake updates.

Obviously we also need to sign the updates to prevent hacking of the ftp mirrors
or redirecting those links, but that's in a separate bug.

Comment 8

[Wolf [:wolf]]

*** Bug 254448 has been marked as a duplicate of this bug. ***

Comment 9

[Wolf [:wolf]]

Iguana, the new update.mozilla.org server has SSL enabled. As Firefox has chosen
to drop the need for tomcat and go with RDF over HTTPS, that's all thats
required for this bug to be fixed. Since leaf is gone, I'm going to mark this
bug fixed on his behalf, as SSL now works. If I'm incorrect in resolving this
bug, please reopen. Thanks.