Bugzilla SSL redirect loop

[JJ]

Greetings. I am running Bugzilla 5.0.3 in a docker container & running
an Apache web server in another container which acts as a reverse proxy.

I've seen a fixed bug that addressed a redirect issue when enabling
"ssl_redirect" & supplying a URL in the "sslbase". I am experiencing
this very problem. Directly accessing the "https" URL is working fine,
but once I enable the "ssl_redirect" & "sslbase", a redirect loop occurs.

Is there anything outside of Bugzilla that needs to be done? I've tried
to force port 80 to redirect to 443, but this also creates a redirect loop.

Thanks for the assist.

JJ

[Thorsten Schöning]

Guten Tag JJ,
am Mittwoch, 1. März 2017 um 17:23 schrieben Sie:

> Greetings. I am running Bugzilla 5.0.3 in a docker container & running
> an Apache web server in another container which acts as a reverse proxy.

So who is actually serving your Bugzilla then? If the mentioned Apache
httpd is the/a reverse proxy...

https://en.wikipedia.org/wiki/Reverse_proxy

> I've seen a fixed bug that addressed a redirect issue when enabling
> "ssl_redirect" & supplying a URL in the "sslbase". I am experiencing
> this very problem. Directly accessing the "https" URL is working fine,
> but once I enable the "ssl_redirect" & "sslbase", a redirect loop occurs.

Please provide more details about your actual target HTTPS URL, what
is configured as urlbase and sslbase, what you input in your browser
with and without ssl_redirect enabled, what your browser dev tools show
as actual request and response with and without ssl_redirect etc.

> Is there anything outside of Bugzilla that needs to be done?

Nothing I'm aware of, but of course depends on your actual web server
setup.

> I've tried
> to force port 80 to redirect to 443, but this also creates a redirect loop.

Please be more detailed about what exactly you have done and provide
your e.g. rewrite rules or whatever you used.

Mit freundlichen Grüßen,

Thorsten Schöning

--
Thorsten Schöning E-Mail: Thorsten....@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/

Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

[Thorsten Schöning]

Guten Tag JJ,
am Mittwoch, 1. März 2017 um 17:23 schrieben Sie:

> Directly accessing the "https" URL is working fine,
> but once I enable the "ssl_redirect" & "sslbase", a redirect loop occurs.

This reads a bit like the following, HTTPS can't work only with
urlbase set.

https://bugzilla.mozilla.org/show_bug.cgi?id=550502

[JJ]

Replies in-line below.

On 3/1/2017 09:39, Thorsten Schöning wrote:
> Guten Tag JJ,
> am Mittwoch, 1. März 2017 um 17:23 schrieben Sie:
>

>> Greetings. I am running Bugzilla 5.0.3 in a docker container & running
>> an Apache web server in another container which acts as a reverse proxy.
>
> So who is actually serving your Bugzilla then? If the mentioned Apache
> httpd is the/a reverse proxy...

Bugzilla, *in a separate* docker container, is using an Apache server.

So, one apache server in one docker container, is the proxy & in another
container, Bugzilla is run under Apache (hopefully this makes sense).
Again, both are using apache.

>> I've seen a fixed bug that addressed a redirect issue when enabling
>> "ssl_redirect" & supplying a URL in the "sslbase". I am experiencing

>> this very problem. Directly accessing the "https" URL is working fine,

>> but once I enable the "ssl_redirect" & "sslbase", a redirect loop occurs.
>

> Please provide more details about your actual target HTTPS URL, what
> is configured as urlbase and sslbase, what you input in your browser
> with and without ssl_redirect enabled, what your browser dev tools show
> as actual request and response with and without ssl_redirect etc.
>

URLBase is normal HTTP URL. ie. http://bugzilla.mysite.com
SSLBase is the usual: ie https://bugzilla.mysite.com
ssl_redirect is enabled.

HTTP Headers indicate the site is being redirected to the HTTPS
location, but once there, the apache server for Bugzilla issues
"HTTP/1.1 301 Moved Permanently" & redirects back to HTTPS.

>> Is there anything outside of Bugzilla that needs to be done?
>
> Nothing I'm aware of, but of course depends on your actual web server
> setup.
>
>> I've tried
>> to force port 80 to redirect to 443, but this also creates a redirect loop.
>
> Please be more detailed about what exactly you have done and provide
> your e.g. rewrite rules or whatever you used.

Initially, I tried this:
<VirtualHost *:80>
ServerName bugzilla.myhost.com
Redirect permanent / https://bugzilla.myhost.com/
</VirtualHost>

<VirtualHost *:443>
ProxyPreserveHost On
ProxyRequests Off
ServerName bugzilla.myhost.com
ServerAlias bugzilla.myhost.com
ProxyPass / https://172.17.0.3/
ProxyPassReverse / https://172.17.0.3/
</VirtualHost>

It is now configured below. With this configuration, I can successfully
access both SSL & non-SSL sites *when "ssl_redirect" is disabled &
"sslbase" is blank. So, it would seem configuration of proxy & bugzilla
apache server is correct(?).

<VirtualHost *:80>
ProxyPreserveHost On
ProxyRequests Off
ServerName bugzilla.myhost.com
ServerAlias bugzilla.myhost.com
ProxyPass / http://172.17.0.3/
ProxyPassReverse / http://172.17.0.3/
</VirtualHost>

<VirtualHost *:443>
ProxyPreserveHost On
ProxyRequests Off
ServerName bugzilla.myhost.com
ServerAlias bugzilla.myhost.com
ProxyPass / https://172.17.0.3/
ProxyPassReverse / https://172.17.0.3/
</VirtualHost>

Thank you very much for the assistance.

[Thorsten Schöning]

Guten Tag JJ,
am Mittwoch, 1. März 2017 um 19:05 schrieben Sie:

> So, one apache server in one docker container, is the proxy & in another
> container, Bugzilla is run under Apache (hopefully this makes sense).

I don't see how this makes sense. What is the benefit you are
expecting from such setup? It's obviously not working already and
makes things unnecessary complex in my opinion.

httpd as a reverse proxy in most cases is used to handle TLS and cover
things like internal Java application servers like Tomcat. But why
would you want to hide Bugzilla with its own httpd instance behind
another httpd?

Who are you expecting to handle things like TLS? If it's the reverse
proxy, it acts like a MITM and you simply wouldn't need any TLS for
Bugzilla. Depending on how you setup your two httpd instances, you
couldn't even use it at all and see exactly the problem you have
currently: Your reverse proxy terminates TLS and forwards plain HTTP
to Bugzilla which is configured to use HTTPS, so sends a redirect,
which your reverse proxy forwards to your client, which your client
processes and sends another request to your reverse proxy, which
terminates TLS again and forwards HTTP to your Bugzilla, which... :-)

If the reverse is fully transparent and TLS is actually handled by the
Bugzilla container, your reverse proxy only sees encrypted content and
is of no use at all. So why not remove it entirely and publish only
one httpd?

> It is now configured below.

Maybe I'm understanding you wrong, but providing the configuration for
one httpd instance if you use two is insufficient and exactly what I
mean with unnecessary complex.

> With this configuration, I can successfully
> access both SSL & non-SSL sites *when "ssl_redirect" is disabled &
> "sslbase" is blank. So, it would seem configuration of proxy & bugzilla
> apache server is correct(?).

I'm not using a reverse proxy setup like I understand yours, but I
think your assumption is wrong and instead proves what I'm saying:
From my understanding, without "sslbase" Bugzilla is never using
HTTPS, because either urlbase or sslbase are rendered in the
templates, mails and such. So if you are able to access Bugzilla using
HTTPS, it's pretty much because your reverse proxy terminates TLS and
forwards HTTP to Bugzilla, which simply works with your setup.

If you enable ssl_redirect and sslbase, you get the loop your are
seeing and I explained above. Make perfect sense to me, so get rid of
your reverse proxy and focus on one httpd instance and publish that.

Mit freundlichen Grüßen,

Thorsten Schöning