Closed Bug 58300 Opened 24 years ago Closed 20 years ago

SSL for bugzilla

Categories

(mozilla.org Graveyard :: Server Operations, task, P3)

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: BenB, Assigned: justdave)

References

Details

(Whiteboard: PLEASE READ comments 14, 16, and 27 before adding comments to this bug) 

Please make bugzilla.mozilla.org available over SSL, i.e. make
<https://bugzilla.mozilla.org> work. This is important to protect passwords,
which in turn protect access to Mozilla vulnerability bugs.
This would require moving to Netscape Enterprise Server (we don't really 
support Apache... especially with SSL) which is OK with me but does anyone have 
time and energy to make bugzilla to work with it?
Risto: what do you mean about having the time and energy to make bugzilla work
with it?  Bugzilla doesn't have to do anything special, as we have no immediate
plans to implement cert-auth, just to allow folks to use encrypted connections.

The server does need to remain Apache, because most Bugzilla instances around
the world use Apache, and we need to be using what our customers use so that
we'll hit any problems that they do.

Apache don't support SSL out-of-the-box. I know it's possible to patch Apache to 
do SSL but AOL IC don't currently support apache. Ie. if you want SSL it has to 
be NES and my statement about energy was that does anyone want to configure 
bugzilla for NES?
Trying to stay polite...

> AOL IC don't currently support apache

dmose just gave a very good reason to use Apache. So, either AOL ICO changes its
policy or it is inappropriate for mozilla.org.

That might be a good reason for mozilla.org but it's not for AOL IC. mozilla.org 
is welcome to support Apache if they want that but we don't have resources to go 
with every possible exception some group comes up with.
Assignee: rko → nobody
Moving to nobody... Apache support is not in IC's radar.
Why can't mozilla.org maintain its own server, incl. software?
Keywords: helpwanted
Keywords: helpwanted
Whiteboard: AOL_IC_project
I can own projects.
Assignee: nobody → rko
I was playing with apache 1.3.20 and mod_ssl 2.84 (with openssl 0.9.6 & php-
4.0.4) just for fun and my own entertainment (results available in 
https://www.kotalampi.com/). It works fine but I didn't take a look how you get 
real server certificates into it yet.

Moving the ticket to Steve.
Assignee: rko → scbrown
At this time, we will not work on this issue. If it ever comes back as an 
active project to us through CRM we will certainly handle it.
Assignee: scbrown → nobody
Whiteboard: AOL_IC_project
MF has its own Ops and its own servers and modern versions of Apache that
actually come with mod_ssl now.

This could be a reality one of these days without too much trouble.

Reassigning to default.
Assignee: nobody → endico
QA Contact: endico → myk
*if* this happens, I'll more than likely be the one to wind up doing it (if not
me, probably Myk, but he's already QA).  Taking.
Assignee: endico → justdave
*** Bug 209595 has been marked as a duplicate of this bug. ***
The *only* thing blocking this at this point is obtaining SSL certificates
signed by a trusted CA.  Everything else will "just work" at this point once the
certificates are dropped in.  Despot is already running on SSL-only, however,
not many people use that, and those that do won't have a problem accepting a
self-signed certificate.  Something as public as Bugzilla needs a CA-signed cert.

*** Bug 251476 has been marked as a duplicate of this bug. ***
https://bugzilla.mozilla.org/  now works.  It's using a self-signed cert though.

Feel free to use it.  I don't feel comfortable redirecting all traffic there
until we have a real cert.
Great to hear, Dave.  However, it may be overkill to send all traffic through
SSL; I would imagine that the processor load could create a serious performance
hit.  The only critical parts are the password entry forms.  So, I think this
bug has two components:

1)  Get bugzilla.mozilla.org a CA signed cert.
2)  Make adjustments to bugzilla so that links to the password entry form https
for the password entry form, and then back again.

It might be sufficient to just configure the web server to redirect 
http://bugzilla.mozilla.org/query.cgi?GoAheadAndLogIn=1 to
https://bugzilla.mozilla.org/query.cgi?GoAheadAndLogIn=1.
does the logincookie not have any sensitive information? (could be, I don't know
how it works)
*** Bug 253116 has been marked as a duplicate of this bug. ***
Unless cookies are cryptographically protected, they would also need the
protection provided by SSL. I don't know if current Bugzilla cookies are safe to
be sent over http.
The login cookie only has a token in it, which is generated when you submit your
password.  So yes, it would in theory be possible to only do SSL when sending
passwords.

There's probably something to be said for having buglists and show_bug show up
under SSL if they contain secured bugs however.  And that's a little harder to
detect outside of the Bugzilla application.
clarification: the token contained in your login cookie is also tied to your IP
address (or to your class C subnet if you uncheck the box on the login page),
and can only be used from within that IP space.  If your IP changes to something
outside that defined space, you are forced to log in again.
Bugzilla's servers do have SSL setup (just try https://bugzilla.mozilla.org)...
the problem is that mod_redirect (or some other NES equivalent) should redirect
http:// to https:// 
It's also useful to protect bug submissions and changes against attack.
There is more than one problem with the SSL. The cert used for
https://bugzilla.mozilla.org is a self-signed one, making the site vulnerable to
MITM. You need a cert that chains to a root trusted by Mozilla.


I just found this site: http://www.cacert.org/

Perhaps this could be an idea? eGroupWare uses this...

just a thought.
 

(In reply to comment #25)
> There is more than one problem with the SSL. The cert used for
> https://bugzilla.mozilla.org is a self-signed one, making the site vulnerable to
> MITM. You need a cert that chains to a root trusted by Mozilla.
> 
> 


Julien / Mick : please read the existing comments.  Comment 14 and comment 16
answer (most of) the questions you just asked.

SSL certs from Thawte are in process.  This will be live as soon as we get them.

ALL of Bugzilla will get SSL.  This is a big server, it can handle it. :) 
Bugzilla itself puts more strain on the server than the encrypt/decrypt process
ever will.
Whiteboard: PLEASE READ comments 14 and 16 before adding comments to this bug
Whiteboard: PLEASE READ comments 14 and 16 before adding comments to this bug → PLEASE READ comments 14, 16, and 27 before adding comments to this bug
*** Bug 254684 has been marked as a duplicate of this bug. ***
*** Bug 252560 has been marked as a duplicate of this bug. ***
status update: We have our Thawte account verified finally, this is now just
waiting for the paperwork to get done.  Hopefully any day now.
Certs have been installed.  Everyone redirected from http to https.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
When using a certain "well known" browser, a message containing the following 
warning is displayed when accessing bugzilla.mozilla.org :

"The name on the security certificate is invalid or does not match the name
 of the site"

and asks "Do you want to proceed?" with a default answer of "No".


Manually inspecting the certificate shows it as being issued to
(bugzilla|bonsai|tinderbox|despot|mecha).mozilla.org

Presumably the certifying authority allows a regular expression for the 
hostname, but MSIE 6.0 does not?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(In reply to comment #32)

> Presumably the certifying authority allows a regular expression for the 
> hostname, but MSIE 6.0 does not?

We've been running SSL on there as an option (not forcing it) for the last three
months, and nobody noticed this before now?  In fact, I could swear I remember
someone specifically testing it on IE6 and saying it worked (they got the "not
signed by a certifying authority you trust" warning because it was self-signed,
but that was the only dialog).
(In reply to comment #33)
> We've been running SSL on there as an option (not forcing it) for the
> last three months, and nobody noticed this before now?

That'd be with a different certificate though....... can't comment as I didn't 
see it.

> In fact, I could swear I remember
> someone specifically testing it on IE6 and saying it worked (they got the "not
> signed by a certifying authority you trust" warning because it was
> self-signed, but that was the only dialog).

This would be the same dialog... it now starts with the first two items having 
green ticks by them:
"The security certificate is from a trusted certifying authority."
"The security certificate is valid."

It does work, but you have to click-through the dialog which whines about a 
certificate that it thinks looks invalid (once you click "Yes" it then 
considers it valid for the entire session).

All other secure sites I have seen require a different IP address for each 
hostname in order to present the correct cert.


Incidentally, I note that at present this redirection is done even in this case:
> telnet bugzilla.mozilla.org 80
GET / HTTP/1.0
Host: bugzilla.mozilla.org

HTTP/1.1 301 Moved Permanently
Date: Tue, 21 Sep 2004 16:24:50 GMT
[....]


Currently a google search for (e.g.) [ mozilla bug system ] returns 
bugzilla.mozilla.org as the top match. Presumably this will cease to be the 
case when google (and other search engines) see this 301 response.

Similarly, would there be any instances where 3rd party sites or scripts 
request data from b.m.o (perhaps requesting buglists in CSV to be passed to an 
analysis script) that would be broken by getting this response instead of 
expected data? Admittedly this is desirable behaviour for any spambots that 
already learned the s/&#64;/@/ trick, but seems undesirable for any other case.


IMHO the redirection should be limited to cases where:
a) The user is already logged in, or
b) bugzilla wishes to request login details.

In other cases the information is public by definition and I do not see why it 
would require SSL protection.


Even when already logged in, REQUIRING https seems to me to be an overkill for 
most users (who do not have any privilege bits set) - it would be far easier 
for an attacker to just create their own account on b.m.o than to hijack an 
unprivileged user's account.

"Always use SSL" could be a user pref, which policy dictates MUST be enabled 
for any user with bz_secure access. Arguably bugzilla should also use PGP on 
outgoing emails to such users too, but that would definitely be another bug!
A certificate with a subject name like
(bugzilla|bonsai|tinderbox|despot|mecha).mozilla.org
is a Netscape extension.

The standard way is to leave the subject name empty
and put the DNS names bugzilla.mozilla.org,
bonsai.mozilla.org, tinderbox.mozilla.org,
despot.mozilla.org, and mecha.mozilla.org in a
subjectAltName extension.  Note that only recent
Mozilla-based browsers using NSS 3.5.1 or later
support a subjectAltName extension of this form
(https://bugzilla.mozilla.org/show_bug.cgi?id=103752).
So old Netscape Communicator 4.x doesn't support
it, but Mozilla 1.2 or later does.
 
(In reply to comment #34)

> Currently a google search for (e.g.) [ mozilla bug system ] returns 
> bugzilla.mozilla.org as the top match. Presumably this will cease to be the 
> case when google (and other search engines) see this 301 response.

That could be a good thing.  There's a lot of people who link there that should
be linking to www.bugzilla.org instead.

> Similarly, would there be any instances where 3rd party sites or scripts 
> request data from b.m.o (perhaps requesting buglists in CSV to be passed to an 
> analysis script) that would be broken by getting this response instead of 
> expected data? Admittedly this is desirable behaviour for any spambots that 
> already learned the s/&#64;/@/ trick, but seems undesirable for any other
> case.

Yeah, it already broke some of the ircbots, most of them have already been fixed.

> IMHO the redirection should be limited to cases where:
> a) The user is already logged in, or
> b) bugzilla wishes to request login details.
> 
> In other cases the information is public by definition and I do not see why it 
> would require SSL protection.

The problem with this is it requires application-level support to do the
redirecting back and forth between http and https, and Bugzilla doesn't support
that yet.  That's bug 260682.
Apologies for polluting this bug with a bunch of other issues (comment 34) - 
I'll take any valid points from that into other bugs in due course...

However, the main point is that, as described in my comment 32 and explained in 
Comment #35 From Wan-Teh Chang, bugzilla.mozilla.org does not have a valid SSL 
certificate since it relies on a netscape extension that is not supported by 
other browsers.

While it is only a minor annoyance to have to click past the security dialog 
each time the site is visited, I would suggest that anything which would train 
users to ignore a security warning is a bad idea. Since there is no secure 
information available to the vast majority of Bugzilla users, surely regular 
http access should be available at least until there is a VALID certificate 
available, in order to avoid training some users into bad habits?
This bug is fixed.  Please file a new bug for the issue of support for the
certificate in IE.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
According to comment #35, the current certificate is using a non-standard
extension.  I would suggest that filing a bug against a third-party product for
failing to support a non-standard extension has little merit.  Rather, if a new
bug is entered, it should be filed against the SSL certificate, to have it use
the subjectAltName field.
> if a new bug is entered, it should be filed against the SSL certificate,
> to have it use the subjectAltName field.

Right.
If/when that new bug about the SSL cert is filed, somebody please cc me 
on that bug, and add a comment to this bug pointing to that one.
I want to make sure mozilla avoids the usual mistake when first using 
subject alt names in a cert.  
Thanks.
(In reply to comment #41)
> If/when that new bug about the SSL cert is filed, somebody please cc me 
> on that bug, and add a comment to this bug pointing to that one.

Done - see bug 261900
Blocks: 261900
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.