Got TLSv1.2?

[#1]

If you're terminating SSL on your Jira server, something administrators miss quite often is setting the ciphers to secure and disabling protocols such as TLSv.1.0 and 1.1.

How to check your settings?

First, go to SSLLabs and drop in your Jira url.  Give it a test.   You'll get a cool looking report card on how you're doing and what you need to do to fix things.

Second, review your server.xml file.  On your Jira application server, this is typically located under the Jira_Home directory in the conf folder.    Scroll down that file and check your connector settings, you'll see something like:

<Connector 
SSLEnabled="true"

if you don't see a line that says "ciphers=".....", you may have a problem.

How to fix it?

So you got a B on your SSLLabs score, and your connector settings in your server.xml look kind of lame.    Lets fix it.

Open back up your server.xml file and lets force sslprotocol to TLS1.2 and lets setup some secure cipher usage.  The final product should look something like:

<Connector 
SSLEnabled="true" acceptCount="100" clientAuth="false" 
connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" 
keyAlias="AwesomeKey" keystoreFile="keystore" keystorePass="rockingpassword" keystoreType="JKS"
maxHttpHeaderSize="8192" maxSpareThreads="75" maxThreads="150" minSpareThreads="25" port="443" 
protocol="org.apache.coyote.http11.Http11NioProtocol"
ciphers="HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA:!3DES:!DHE:!DH"
scheme="https" secure="true" sslProtocol="TLSv1.2" sslEnabledProtocols="TLSv1.2" useBodyEncodingForURI="true"
/>

 Obviously, use your own keystore folder and keystore password.

Next, run the SSLLabs test again:

You've done it!

Congratulations, you're now one bit more secure.   

Now a few notes of caution.  Always test this sort of change on your staging environment first, and I've done this on Jira 7.4+. 

Can I use this configuration on Confluence?

Yes, absolutely.... go for it... but do it in your staging server.xml first, please :)

I use Bitbucket, what's its TLSv1.2 Setting?

BitBucket uses a slightly different configuration.  Look in the bitbucket.properties file found in Bitbucket\shared\ folder.  The configuration  lines you need will look like:

server.port=443
server.scheme=https
server.ssl.protocol=TLSv1.2
server.ssl.enabled=true
server.ssl.ciphers=HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA:!3DES:!DHE:!DH

Last, last note... remember any time you change these config files, you need to restart your instance.  So, service stop/start/restart or restart your application server.

[Daniel Eads {unmonitored account}]

It's possible to get an A (A+ in fact) with older TLS still enabled so you're not killing non-modern clients. Our networking guys insist on using some awful Cisco WAAS product that only supports TLS 1.0! So we have to leave some things I'd rather have off enabled.

And yet, here's our box:

The key to doing this safely (and avoiding downgrade attacks) is a good reverse proxy like nginx and the ssl_prefer_server_ciphers on; directive that we have ourselves on line 47 of this config here. Check out the full repo to get all the files you need for a ballin nginx setup (but generate some new DH primes ;) ). But for sure, get rid of those awful export grade ciphers.

[Gregory Van Den Ham]

Awesome, thanks for this.   I certainly agree - installing a Web Application Firewall and doing ssl offload is certainly better and better performing, especially in busy environments.   SSLLabs has some score limiters in place, for instance TLSv1.0 will limit your protocol score to 90%, 1.1 will limit you to 95% and I think that's what we see in your scorecard accurately.

Just as a note, as an industry - TLSv.1.0 is going away.  If you deal with PCI, Office365, and Salesforce for example in your org, you know it must be gone soon and clients that touch this data must support higher protocols with heavy preference to TLSv1.2.

My recommendation is really if you're stuck and can't deploy a higher protocol you should consider mitigating risk and remove applications not supporting TLSv1.2 from public facing.

[Timothy]

Adding some information here.

I certainly agree - installing a Web Application Firewall and doing ssl offload is certainly better and better performing, especially in busy environments. 

This is what most of setups are done and I would like to recommend the following. The OP discusses about how to achieve a good rating via Tomcat and SpringBoot.

This is what I generally base my security settings off. Give the Mozilla SSL Configurator a go:

• https://mozilla.github.io/server-side-tls/ssl-config-generator

The configurator gives users a number of configurations for different proxies like Apache, nginx and ELBs. If the environment is suitable, we generally recommend a reverse proxy in front of the Atlassian application (or any application for that matter) to offload SSL. Using them gives users a a wider set of security configurations to set and control.

Edit: Grammar and spelling.

[Boris Berenberg - Atlas Authority]

Great to see technical posts like this, as well as community members contributing their configs back.