why is my browser prefixing https after the initial redirect from port 8080 to 8443?

[JordanJ]

We've configured Jira over SSL as per the instructions found here: https://confluence.atlassian.com/adminjiraserver0813/running-jira-applications-over-ssl-or-https-1027138529.html

Jira is working as expected at port 8443.  At port 8080, it initially redirects to port 8443. On subsequent attempts, both chrome and edge are prefixing https or even replacing http in the call to 8080.  Since 8080 is not ssl and should only redirect, the call fails.  It will only work once more when I clear the browser cache.  Then it wont work on subsequent tries.

This is what happens:

Step 1) http://jira:8080 --> https://jira:8443 --- As expected

Step 2) http://jira:8080 --> https://jira:8080 --- Chrome prefixes https so the server rejects

Step 3) https://jira:8443                                 --- Jira is accessed as expected

Is there a flag I need to set in tomcat?  I was looking into hsts but to no avail.

thank you

[KellyW · Accepted solution]

HSTS headers (Strict-Transport-Security) are enforced in a few Jira releases (8.5.11, 8.13.3, 8.14.1, 8.15.0) to address some security concerns.

To revert the behaviour back to before, we can add -Dcom.atlassian.jira.strict.transport.security.disabled=true JVM parameter to Jira startup options.

However, we still recommend having proxy server in front of Jira to redirect the traffics to the HTTPS connector (port 8443) or remove the HTTP connector connector to eliminate the redirection.


Notes: The failing redirection is due to the fact that Jira domain is added to HSTS domain security policies as Jira enforced the HSTS headers and it's hosted over non-default HTTP and HTTPS ports. This is prominent when we are using CA-signed SSL certificate (not self-signed SSL certificate as HSTS requires the certificate to be a trusted certificate).

[JordanJ]

Thanks for this.  It's exactly what I was looking for.  I had opened a support ticket with Atlassian but they didn't know about this at the time apparently.

[Dominik Žarković]

Hello @JordanJ

We have this same problem. Where did You add this JVM parameter? 

Thanks

[Nic Brough -Adaptavist-]

For a permanent solution, you can add it to the setenv.sh/bat file in the "bin" directory.

[Dominik Žarković]

We have add it to setenv.sh into JVM_SUPPORT_RECOMMENDED_ARGS but it didn't help. 

[Nic Brough -Adaptavist-]

It's not really supposed to be used in there, try adding it to the standard environment.

If it's not working, then you'll need to show us exactly what you've put into setenv.sh so we can debug it.

[Tomislav Tobijas _Koios_]

Hi @Nic Brough -Adaptavist-

When you say

try adding it to the standard environment

what do you actually mean by it?

Also, here's the screenshot of current setenv.sh file:

[JordanJ]

I think I set these values to false and http

scheme="https" secure="true"

[Nic Brough -Adaptavist-]

It's because the connection is set up to be ssl enabled.  Your browser is detecting that SSL is there, so it's changing the protocol from http to https in order to use it.

Why are you trying to use it on two different ports?

[JordanJ]

Thanks for getting back to me.

I just followed the documentation.  It suggests an ssl port in addition. 

<Connector port="8080" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;" 
    maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false" URIEncoding="UTF-8"
    maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="false" redirectPort="8443"
    acceptCount="100" disableUploadTimeout="true" bindOnInit="false"/>

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
              maxHttpHeaderSize="8192" SSLEnabled="true"
              maxThreads="150" minSpareThreads="25"
              enableLookups="false" disableUploadTimeout="true"
              acceptCount="100" scheme="https" secure="true"
              sslEnabledProtocols="TLSv1.2,TLSv1.3"
              clientAuth="false" useBodyEncodingForURI="true"
              keyAlias="jira" keystoreFile="<Jira_HOME>/jira.jks" keystorePass="changeit" keystoreType="JKS"/>

It seems to work like this just fine in confluence.   This is the ideal scenario since we dont want user's behavior to change.  They can continue using port http://jira:8080 and all their existing shortcuts without worrying about the https prefix.  I did consider just making port 8080 the ssl port, but then we get into the existing shortcuts issue.  We have close to 500 users.

I've tried disabling the hsts flag in tomcat and blocking redirects in chrome but to no avail.

It's also curious why I don't see the same behavior after following the confluence instructions.  https://confluence.atlassian.com/doc/running-confluence-over-ssl-or-https-161203.html

[JordanJ]

Is there an argument that can be added to a config file because this startup argument would get wiped whenever upgrading?

[JordanJ]

I would like to confirm the following.

1. If you try to accomplish the same behavior while logging into the server where Jira is installed, and instead of using JIRA DNS, try using localhost:8080, what is the result?
2. Do you have any firewall, proxy any middle system that could be changing any cookies or HTTP headers between Jira and the hosts?
3. Have we tried to use other browsers to reproduce the issue? What is the result while using Firefox?
4. What is the Chrome version you are using to perform the tests? I'd like to use the same version on my end.

[Aaron Robards]

I have exactly the same issue after updating Jira to 8.15.0 tonight, The in-built Jira redirect from HTTP on 8080 to HTTPS on 8443 was working perfectly fine with this recommended configuration until now.

[Aaron Robards]

On further reading, this appears to relate to HSTS and sites electing to always use HTTPS. This seems to have changed in the latest Jira version?

[JordanJ]

I've found that too and tried disabling hsts on tomcat but could not.  I changed the setting in the web.xml but the value doesn't actually change.  The only thing i could come up with is to use IIS to do redirection so that the request and responding servers are different.

[JordanJ]

Atlassian suggested downgrading tomcat.  I won't be doing that but this was their suggestion. 

[JordanJ]

@Aaron Robards 

Did you find a solution?  I'm working with atlassian support.  Could you describe your env?

I would like to confirm the following.

1. If you try to accomplish the same behavior while logging into the server where Jira is installed, and instead of using JIRA DNS, try using localhost:8080, what is the result?
2. Do you have any firewall, proxy any middle system that could be changing any cookies or HTTP headers between Jira and the hosts?
3. Have we tried to use other browsers to reproduce the issue? What is the result while using Firefox?
4. What is the Chrome version you are using to perform the tests? I'd like to use the same version on my end.

[Aaron Robards]

No solution yet. Our users are having to connect direct to the HTTPS port/URL.

We are running latest version of Jira 8.15.0 with bundled Tomcat 8.5.60 on CentOS 7.9 in a GCP (Google Cloud) VM. We are not using any proxies but of course GCP has it's own firewalls.

The same re-direct configuration was working perfectly on Jira 8.14.0.

I have been testing with latest Chrome (88.0)

I can't really test properly in this environment on the Jira server but confirmed a request to localhost:8080 gives the same response as a request to JIRA DNS URL.

[JordanJ]

Would you be willing to share you server.xml and web.xml

[JordanJ]

I came across this but it doesn't help

https://confluence.atlassian.com/jirakb/unable-to-access-jira-on-http-after-enabling-https-978206879.html