Browser redirects other applications to HTTPS when using the same domain/subdomain as Jira

Summary

Other applications deployed on the same Jira DNS are being forced to HTTPs by the browser when Jira is using SSL, even if they don't use SSL.

Environment

• Jira 8.13.0 and later.

• The diagnosis/resolution steps were tested with Google Chrome browser.

Diagnosis

• Another application is using the same DNS as Jira with a difference in the port/context path.

• Accessing the application on http://dns:<port>/<context_path> in the browser redirects to https://dns:<port>/<context_path>.

• There is a similar issue that was raised to stop an automatic redirect from “http://” to “https://” in Chrome . Running the resolution steps does not help:

  1. Go to chrome://net-internals/#hsts. Enter lawejen001.azure01.csp.local under Delete domain security policies and press the Delete button.

  2. Now go to chrome://settings/clearBrowserData, tick the box Cached images and files and press click the button Clear data.

  3. Try to reproduce the issue in the Chrome browser.

• Checking HAR files from Jira, we can confirm that the Strict-Transport-Security header is being set by Jira in the response header:

  

Cause

This issue is caused by the HTTP Strict Transport Security (HSTS) header being added by Jira since Jira version 8.13.0.

This is what happens when an HSTS enabled website is accessed from the browser :

• The first time your site is accessed using HTTPS and it returns the Strict-Transport-Security header, the browser records this information, so that future attempts to load the site using HTTP will automatically use HTTPS instead.

• When a website with HSTS is accessed, the Strict Transport Security header informs the browser that it should never load a site using HTTP and should automatically convert all attempts to access the site using HTTP to HTTPS requests instead.

• The browser will only get the HTTPS version of the page, so when a user types in an HTTP URL of the page, the browser remembers the HTTPS version and goes directly to the HTTPS version.

• When a browser knows that a domain has enabled HSTS, it does two things:

  • Always uses an HTTPS:// connection, even when clicking on an HTTP:// link or after typing a domain into the location bar without specifying a protocol.

  • Removes the ability for users to click through warnings about invalid certificates.

You may verify if HSTS is enabled for a specific domain on the browser by following these steps:

1. Go to chrome://net-internals/#hsts

2. In the Query HSTS/PKP domain section enter the domain (without the port). If it is returned found, then all domains will redirect to HTTPS regardless of the port. For example:

   

Removing thison a specific browser using the Delete domain security policies (https://howchoo.com/chrome/stop-chrome-from-automatically-redirecting-https ) will help locally but it's not a viable solution company-wide as each user needs to do this manually.

Notes: There are other reasons for HTTP to HTTPS restrictions such as redirect directives added in <Application_Install>/conf/web.xml or <Application_install>/atlassian-jira/WEB-INF/web.xml files. There are cases where the security constraints (like the directive "Restricted URLs") caused HTTPS redirection. Check these files against stock versions and ensure there are no directives that redirect traffic.

Refer the KB article Browser redirects other applications to HTTPS when using the same domain/subdomain as Jira for resolution steps if other applications deployed on the same Jira DNS are being forced to HTTPs by the browser.

Solution

In order to resolve this issue, here are the possible alternatives:

Option 1

• Use a different domain for the other application.

Option 2

• Configure the other application to work on SSL.

Option 3

You can disable HSTS in Jira following HSTS configuration blocks Jira from redirect HTTP to HTTPs connections

Basically, you need to add this line to the JVM parameter for Jira Setting properties and options on startup and restart Jira:

Please note that this will not solve the problem immediately because the browser still has the HSTS header and it needs to be removed. For that, the users need to do the following:

1. Access chrome://net-internals/#hsts

2. Check if the header is still present

3. If yes, users will need to delete it

4. Then query again and confirm it's Not found

5. Finally, clear the browser cache and it should work fine now for the other websites.