What to do with ssl="authenticated sessions" + code freeze date for Bugzilla 3.6

[Frédéric Buclin]

Hi all,

At the Bugzilla meeting today, there has been some discussion about what
to do with the "authenticated sessions" value of the ssl parameter now
that you can log in from every page. It seems that it doesn't make sense
to keep this value anymore as all pages must be protected using SSL as
you can potentially use any of them to log in. Does anyone see a valid
reason to not kill this value? This means the ssl parameter would become
a single yes/no to use ssl or not, see bug 329638.

Now something unrelated to SSL, I just wanted to inform you that the
code freeze for Bugzilla 3.6 will happen at the end of September, two
months after the release of Bugzilla 3.4. No new features will be
accepted for 3.6 past this deadline, only bug fixes. So your
contributions should be attached to b.m.o before this date if you expect
to see them implemented for 3.6. And keep in mind that most patches
don't get review+ on the first revision, so include in your timing
enough time to update your patches before the freezing date. ;)

I think that's all for today. :)

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[David Lawrence-3]

On 08/18/2009 08:58 PM, Frédéric Buclin wrote:
> At the Bugzilla meeting today, there has been some discussion about what
> to do with the "authenticated sessions" value of the ssl parameter now
> that you can log in from every page. It seems that it doesn't make sense
> to keep this value anymore as all pages must be protected using SSL as
> you can potentially use any of them to log in. Does anyone see a valid
> reason to not kill this value? This means the ssl parameter would become
> a single yes/no to use ssl or not, see bug 329638.
>
>    

As mentioned in the meeting, we (Red Hat) do not utilize this functionality
since our multiple web servers sit behind a load balancing proxy which does
the automatic redirect to SSL for all requests. So we normally keep the
ssl param set to 'never' now anyway. So I vote yes for this change.

Dave

--
David Lawrence, RHCE  dkl@...
------------------------------------
Red Hat, Inc.    Web: www.redhat.com
1801 Varsity Drive Raleigh, NC 27606

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[David Miller]

David Lawrence wrote on 8/19/09 10:18 AM:

> On 08/18/2009 08:58 PM, Frédéric Buclin wrote:
>> At the Bugzilla meeting today, there has been some discussion about what
>> to do with the "authenticated sessions" value of the ssl parameter now
>> that you can log in from every page. It seems that it doesn't make sense
>> to keep this value anymore as all pages must be protected using SSL as
>> you can potentially use any of them to log in. Does anyone see a valid
>> reason to not kill this value? This means the ssl parameter would become
>> a single yes/no to use ssl or not, see bug 329638.
>
> As mentioned in the meeting, we (Red Hat) do not utilize this functionality
> since our multiple web servers sit behind a load balancing proxy which does
> the automatic redirect to SSL for all requests. So we normally keep the
> ssl param set to 'never' now anyway. So I vote yes for this change.

Same at Mozilla.  We'd always had it set to "never" with the https: in
the urlbase.  Looking at the config now, it looks like it's set to
"always" at the moment, but both urlbase and sslbase are the same.

--
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[David Lawrence-3]

On 08/19/2009 02:02 PM, David Miller wrote:

> David Lawrence wrote on 8/19/09 10:18 AM:
>    
>> On 08/18/2009 08:58 PM, Frédéric Buclin wrote:
>>      
>>> At the Bugzilla meeting today, there has been some discussion about what
>>> to do with the "authenticated sessions" value of the ssl parameter now
>>> that you can log in from every page. It seems that it doesn't make sense
>>> to keep this value anymore as all pages must be protected using SSL as
>>> you can potentially use any of them to log in. Does anyone see a valid
>>> reason to not kill this value? This means the ssl parameter would become
>>> a single yes/no to use ssl or not, see bug 329638.
>>>        
>> As mentioned in the meeting, we (Red Hat) do not utilize this functionality
>> since our multiple web servers sit behind a load balancing proxy which does
>> the automatic redirect to SSL for all requests. So we normally keep the
>> ssl param set to 'never' now anyway. So I vote yes for this change.
>>      
> Same at Mozilla.  We'd always had it set to "never" with the https: in
> the urlbase.  Looking at the config now, it looks like it's set to
> "always" at the moment, but both urlbase and sslbase are the same.
>    

We had it mistakenly once set to ssl == 'always' and any request to the
server got stuck in
an endless looping redirect.

Dave

--
David Lawrence, RHCE  dkl@...
------------------------------------
Red Hat, Inc.    Web: www.redhat.com
1801 Varsity Drive Raleigh, NC 27606

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Wurblzap]

2009/8/19 Frédéric Buclin <lpsolit@...>:
> At the Bugzilla meeting today, there has been some discussion about what
> to do with the "authenticated sessions" value of the ssl parameter now
> that you can log in from every page. It seems that it doesn't make sense
> to keep this value anymore as all pages must be protected using SSL as
> you can potentially use any of them to log in. Does anyone see a valid
> reason to not kill this value? This means the ssl parameter would become
> a single yes/no to use ssl or not, see bug 329638.

I've got two installs with the param set to authenticated_sessions.
Most traffic on them is happening via SSL, though, because the vast
majority of bugs are not public, so people usually are logged in.

So I won't miss the value much, but I like the idea of being able to
browse unencrypted... I gather that we should log in *from* an
encrypted page, though, and since this means every page allows a log
in now, every page must be encrypted. Can you shed some light on why
this is so? Why can't we log in from an unencrypted page, moving to
SSL just when logging in? Is it some man-in-the-middle thing?

   Marc
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Gregary Hendricks]

>>> On 8/19/2009 at 12:18 PM, in message <4A8C41F0.1080300@...>,
David
Lawrence <dkl@...> wrote:
> On 08/19/2009 02:02 PM, David Miller wrote:
> > David Lawrence wrote on 8/19/09 10:18 AM:
> >    
> >> On 08/18/2009 08:58 PM, Frédéric Buclin wrote:
> >>      
> >>> At the Bugzilla meeting today, there has been some discussion
about what
> >>> to do with the "authenticated sessions" value of the ssl
parameter now
> >>> that you can log in from every page. It seems that it doesn't
make sense
> >>> to keep this value anymore as all pages must be protected using
SSL as
> >>> you can potentially use any of them to log in. Does anyone see a
valid
> >>> reason to not kill this value? This means the ssl parameter would
become
> >>> a single yes/no to use ssl or not, see bug 329638.
> >>>        
> >> As mentioned in the meeting, we (Red Hat) do not utilize this
functionality
> >> since our multiple web servers sit behind a load balancing proxy
which does
> >> the automatic redirect to SSL for all requests. So we normally
keep the
> >> ssl param set to 'never' now anyway. So I vote yes for this
change.
> >>      
> > Same at Mozilla.  We'd always had it set to "never" with the https:
in
> > the urlbase.  Looking at the config now, it looks like it's set to

> > "always" at the moment, but both urlbase and sslbase are the same.

> >    
>  
> We had it mistakenly once set to ssl == 'always' and any request to
the  
> server got stuck in
> an endless looping redirect.
>  

We also use a proxy that handles the SSL redirect. In our case urlbase
is set to http and the proxy handles the SSL since we don't want to
encrypt the data between the apache server and the proxy. Authentication
in our system is also handled external to Bugzilla anyway so the reasons
for using SSL are based on bug content. Since that is arbitrary, we
enforce SSL always, but again, this is all handled external to Bugzilla.
If we put https or set sslbase at all, we also see endless redirect
loops.

Greg
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[David Miller]

Gregary Hendricks wrote on 8/19/09 5:46 PM:
> We also use a proxy that handles the SSL redirect. In our case urlbase
> is set to http and the proxy handles the SSL since we don't want to
> encrypt the data between the apache server and the proxy. Authentication
> in our system is also handled external to Bugzilla anyway so the reasons
> for using SSL are based on bug content. Since that is arbitrary, we
> enforce SSL always, but again, this is all handled external to Bugzilla.
> If we put https or set sslbase at all, we also see endless redirect
> loops.

Our proxy also handles the SSL with traffic between the proxy and
bugzilla unencrypted.  Bugzilla's apache is actually listening on ports
80 and 81 for cleartext and encrypted, and the port 81 vhost sets the
HTTPS environment variable so that mod_perl thinks it's SSL.

--
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[David Miller]

Marc Schumann wrote on 8/19/09 4:25 PM:
> I gather that we should log in *from* an
> encrypted page, though, and since this means every page allows a log
> in now, every page must be encrypted. Can you shed some light on why
> this is so? Why can't we log in from an unencrypted page, moving to
> SSL just when logging in? Is it some man-in-the-middle thing?

Yes.  If you got man-in-the-middled on your way to the http page, you'd
never know, and you have no proof the form is going to submit to an
https destination without viewing the source.  If the form is https to
begin with then you have the certificate validation to know you got the
form itself from the trusted source as well.

--
Dave Miller                                   http://www.justdave.net/
System Administrator, Mozilla Corporation      http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System  http://www.bugzilla.org/
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>

[Frédéric Buclin]

Le 19. 08. 09 22:25, Marc Schumann a écrit :
> this is so? Why can't we log in from an unencrypted page, moving to
> SSL just when logging in? Is it some man-in-the-middle thing?

No idea about MITM attacks. Probably justdave, dveditz, jruderman and
some others would know.

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>