Redirect to http port 443 after login

RT Users
1

Hello again,

I got some time at work, so I was working on getting our dev instance of RT working on Nginx in stead of apache. So far it works fine and the performance also seems to be better, I just got one issue where I’m not able to track it down:
If I open the login page via https and login, I get redirected to the main RT page with http and port 443. If I correct this manually, everything afterwards seems to work fine again.

After doing a TCPDump between nginx and the fcgi-server I belive that the issue is the RT itself. here the interesting part:

Status: 302 Found
Set-Cookie: RT_SID_MarcanT.443=5a4f2d748678ee3b48ec59d2881d1a57; path=/; HttpOnly
Date: Thu, 10 Dec 2020 17:30:01 GMT
Location: http://rt-dev.marcant.loc:443/
Content-Type: text/html; charset=utf-8
X-Frame-Options: DENY

I already checked the configuration table in the database, its empty. and for the RT_SiteConfig, I also noticed no error here. I have already tried around here a little (of course with clearing the cache and restarting the fcgi-server and nginx every time), but for now it wasnt working.
Even setting $WebPort to some nonsense like 4433 doesnt result in a change.

Any Ideas how to track the problem down?

/edit: fixed the formatting for the tcpdump snippet

2

What is your webport set to when you go to Admin->Tools->System Configuration?

Is Nginx set to listen on 443?

3

Nginx listens on 443. Also if I manually fix the problem in the browser manually, I can continue working via https just fine.

The configuration shows port 4433 like set in the RT_SiteConfig.pm. I just changed the port from 443 to this for testing, but the returned port is the same.

/edit: of course RT_SiteConfig.pm in stead of RT_Site_Config.pm

4

The file is RT_SiteConfig.pm not RT_Site_Config.pm are you editing the first file?

5

Just checked again, RT_SiteConfig.pm. the Site_Config was just a typo.

/edit: Just noticed that the System Configuration has shown me WebURL as “http://rt-dev.marcant.loc:4433”, but since that was not what is delivered after login, it doesnt seem to be the issue. Also changing this via RT_SiteConfig.pm to “https://rt-dev.marcant.loc” made no difference.

6

I believe you should only set:

 `WebPort` and `WebDomain`

Or

`WebBaseURL` and `$WebURL`
7

Just tried both ways while commenting the other stuff out (do the changes, clear mason cache, restart fcgi, restart nginx), same result.

8

Can you share the nginx conf? I haven’t used it before but I would look there

9

Sure, here it is:

server {
    # redirect all HTTP to HTTPS
    listen 80;
    server_name rt-dev.marcant.loc;
    return 301 https://rt-dev.marcant.loc$request_uri;
}
server {
    listen 443 ssl;
    server_name rt-dev.marcant.loc;
    access_log /var/log/nginx/access.log;

    ssl_certificate /etc/pki/tls/certs/rt.marcant.loc.crt;
    ssl_certificate_key /etc/pki/tls/private/rt.marcant.loc.key;

    location / {
            fastcgi_param QUERY_STRING $query_string;
            fastcgi_param REQUEST_METHOD $request_method;
            fastcgi_param CONTENT_TYPE $content_type;
            fastcgi_param CONTENT_LENGTH $content_length;

            fastcgi_param SCRIPT_NAME "";
            fastcgi_param PATH_INFO $uri;
            fastcgi_param REQUEST_URI $request_uri;
            fastcgi_param DOCUMENT_URI $document_uri;
            fastcgi_param DOCUMENT_ROOT $document_root;
            fastcgi_param SERVER_PROTOCOL $server_protocol;

            fastcgi_param GATEWAY_INTERFACE CGI/1.1;
            fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;

            fastcgi_param REMOTE_ADDR $remote_addr;
            fastcgi_param REMOTE_PORT $remote_port;
            fastcgi_param SERVER_ADDR $server_addr;
            fastcgi_param SERVER_PORT $server_port;
            fastcgi_param SERVER_NAME $server_name;
            fastcgi_pass 127.0.0.1:9000;
    }

    location /NoAuth/images {
            root /opt/rt5/share/html;
    }
}

In addition I use the following command to start the RT fcgi-server:

    spawn-fcgi -F 3 -u www-data -g www-data -a 127.0.0.1 -p 9000 -d /opt/rt5/ -- /opt/rt5/sbin/rt-server.fcgi

I’ve done the tcpdump on localhost port 9000, so I only sniffed the communication between fcgi and nginx. Thats the reason why I was assuming that nginx isnt the problem here.

/edit: here is the source for the base config. I just added the necessary https stuff.
https://docs.bestpractical.com/rt/5.0.0/web_deployment.html#nginx

10

Hi, I believe we are seeing the same (or related at least) issue. We’re using RT 4.4.4 and this week ‘all of a sudden’ we are getting browser security errors when submitting any kind of form (comments/replies, advanced search, login), with the responses from RT after a POST pointing to http instead of https. The POSTs themselves appear to correctly be https, and it’s possible the error is a recent behavioral change in Chrome that didn’t exist prior to last week. My coworkers have confirmed they don’t get the security error using Firefox, however this behaviour from RT appears to be incorrect anyway if it’s trying to redirect to HTTP after a POST.

Our WebBaseURL is pointing to https.

Let me know if you need more info, or if you think I should submit this as a new separate issue.

Thanks

11

Hmm what version of Chrome?

12

Version 87.0.4280.88 (Official Build) (64-bit)

I might have an older version, or chromium on another host I can test with… I’ll report back if so

13

Just tested with an older build of chromium and do not see the error there,
Version 83.0.4103.116 (Developer Build) built on Debian 10.4, running on Debian 10.6 (64-bit)

Same host sees the error with latest chrome.

14

Hmm… If you have root access to the RT-Server, you could make a tcpdump in order to see what the RT sends to the browser.
Right now I see two possible problems here:

  1. The new Chrome does something strange or has a bug
  2. The RT gives out wrong data and the new Chrome version “just” lacks the auto correction for this in the new version.
15

I’ll try to duplicate today @Wes are you using Apache or Nginx for your web server?

16

Also it may be worth trying to enable this config if it isn’t already:
https://docs.bestpractical.com/rt/5.0.0/RT_Config.html#WebSecureCookies

17

Just tried. Sounds useful for https only, but sadly hasnt solved the problem.

If you want to test nginx on a new server, this is the tcpdump command I used to sniff the traffic between Nginx and FCGI, including the transmitted html commands:
tcpdump -i lo -A 'port 9000'

18

I think it’s actually a third option, or at last a modification of the second - RT is returning the wrong data, sending a 301 to HTTP despite the base url being HTTPS and the current client protocol also being HTTPS, but this being an error is only a very recent behaviour change in Chrome, so they’re both causing this together but what Chrome is doing isn’t actually wrong. The correct fix would be to find out why RT is changing protocols contrary to explicit config and client request and change its behaviour so it uses the right protocol at all times.

Side note - getting the Chrome team to consider this a bug and backtrack on the change is going to be beyond impossible :stuck_out_tongue: this is no doubt a very intentional and deliberate security hardening change

19

We’re using apache on the RT host and nginx to proxy to it, we are also passing the x-forwarded-for and x-forwarded-proto headers to apache+rt from nginx

20

There’s a bunch of things mentioned here, but I think the most likely case is still the RT web config options are fighting one another.

If we can see the four web config from Admin->Tools->System configuration it’d be able to rule these out.

Earlier on one of the example web URLs was using http but pointed to port 443 so I am not sure how that would resolve