Secure Tomcat with TLS
Two services comprise Incorta: the Loader Service and the Analytics Service. For TLS setup and configuration, you must secure the Analytics Service.
The default installation path for Incorta is:
/home/incorta/IncortaAnalytics
Before beginning, you must identify the path to the Analytics Service.
- Identify the Unique Identifier for the Analytics Service as this value comprises the Analytics Service file system path.
$ cat <INCORTA_NODE_INSTALLATION_PATH>/services/services.index
- Navigate to the Analytics Service directory. Replace
<UUID>
with the value found inservices.index
. If in a cluster environment, the service may be on another Incorta Node host:
$ cd <INCORTA_NODE_INSTALLATION_PATH>IncortaNode/services/<UUID>/
With the directory path identified, you can now secure Tomcat with TLS. Follow these steps:
- Create a self-signed certificate to enable TLS access for Tomcat.
- Enable TLS in Tomcat.
- Use
testssl.sh
or Firefox to test the TLS connection. - Configure ciphers used for Tomcat.
- Identify the ciphers JVM supports.
- Configure
server.xml
to enable TLS with a self-signed certificate (for test purpose only) and test the TLS connection with Firefox. - Enable the Secure Flag in context.xml.
- Configure ciphers to remove weak ciphers.
1. Create a self-signed certificate
You can create a self-signed certificate for testing. For live implementations, use a valid server certificate issued by a CA authority.
Use the java keytool to generate and save a self-signed server certificate to a keystore. Tomcat uses this key in a later step.
keytool -genkeypair -helpkeytool -genkeypair [OPTION]...Generates a key pairOptions:-alias <alias> alias name of the entry to process-keyalg <keyalg> key algorithm name-keysize <keysize> key bit size-sigalg <sigalg> signature algorithm name-destalias <destalias> destination alias-dname <dname> distinguished name-startdate <startdate> certificate validity start date/time-ext <value> X.509 extension-validity <valDays> validity number of days-keypass <arg> key password-keystore <keystore> keystore name-storepass <arg> keystore password-storetype <storetype> keystore type-providername <providername> provider name-providerclass <providerclass> provider class name-providerarg <arg> provider argument-providerpath <pathlist> provider classpath-v verbose output-protected password through protected mechanism
2. Enable TLS/SSL in Tomcat
To enable TLS/SSL in Tomcat:
- Open
server/conf/server.xml
. - In the TLS/SSL port section (hint: search for 8443), add the keystore configuration. Replace
<UUID>
with the value found inservices.index
.
<Connectorport="8443"protocol="HTTP/1.1"SSLEnabled="true"maxThreads="150"scheme="https"URIEncoding="UTF-8"secure="true" clientAuth="false"sslProtocol="TLS"maxHttpHeaderSize="10485760"maxPostSize="10485760"keystoreFile="<INCORTA_NODE_INSTALLATION_PATH>/IncortaNode/services/<UUID>/keystore.jks"keystorePass="incorta123"keyAlias="incorta" />
sslProtocol
defines which versions the server can support. For example, sslProtocol="TLSv1.1, TLSv1.2"
supports both protocols.
3. Test the TLS connection
You can use testssl.sh
or Firefox to text the TLS Connection
Use testssl.sh to test the TLS connection
Use the open source tool testssl.sh
to test the SSL connection.
- Download
testssl.sh
from github: https://github.com/drwetter/testssl.sh. - Run the tool.
Use Firefox to test the TLS connection
If you cannot use testssl.sh
, you can use Firefox to identify which protocol and cipher the browser uses to connect to the server.
- Open Firefox.
- Access
https://localhost:8443/incorta
. - A security warning displays. Select Advanced.
- Select Not Secure in the URL bar at the top. If you use a CA issued certificate, you may see a green lock icon instead of this warning.
- Select Proceed to see the Incorta login page.
- Select the lock icon next to URL bar, then select the arrow next to localhost.
- Select More Information.
- The details of the protocol and certificate information display.
4. Configure ciphers used for Tomcat
SSL is not good enough to secure Tomcat access. To prevent attackers to exploit TLS vulnerabilities, you must configure a cipher set to remove weak ciphers Tomcat uses.
5. Identify the ciphers JVM supports
Cut and Paste to Ciphers.java
in your local env
import java.util.Iterator;import java.util.Map;import java.util.TreeMap;import javax.net.ssl.SSLServerSocketFactory;public class Ciphers{public static void main(String[] args)throws Exception{SSLServerSocketFactory ssf = (SSLServerSocketFactory)SSLServerSocketFactory.getDefault();String[] defaultCiphers = ssf.getDefaultCipherSuites();String[] availableCiphers = ssf.getSupportedCipherSuites();TreeMap ciphers = new TreeMap();for(int i=0; i<availableCiphers.length; ++i )ciphers.put(availableCiphers[i], Boolean.FALSE);for(int i=0; i<defaultCiphers.length; ++i )ciphers.put(defaultCiphers[i], Boolean.TRUE);System.out.println("Default\tCipher");for(Iterator i = ciphers.entrySet().iterator(); i.hasNext(); ) {Map.Entry cipher=(Map.Entry)i.next();if(Boolean.TRUE.equals(cipher.getValue()))System.out.print('*');elseSystem.out.print(' ');System.out.print('\t');System.out.println(cipher.getKey());}}}
Ciphers with starting with * are supported by the Java Virtual Machine (JVM). Unsupported ciphers can be added by the JCE extension.
$ javac Ciphers.java$ java CiphersDefault CipherSSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA* SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHASSL_DHE_DSS_WITH_DES_CBC_SHASSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA* SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHASSL_DHE_RSA_WITH_DES_CBC_SHASSL_DH_anon_EXPORT_WITH_DES40_CBC_SHASSL_DH_anon_WITH_3DES_EDE_CBC_SHASSL_DH_anon_WITH_DES_CBC_SHASSL_RSA_EXPORT_WITH_DES40_CBC_SHA* SSL_RSA_WITH_3DES_EDE_CBC_SHASSL_RSA_WITH_DES_CBC_SHASSL_RSA_WITH_NULL_MD5SSL_RSA_WITH_NULL_SHA* TLS_DHE_DSS_WITH_AES_128_CBC_SHA* TLS_DHE_DSS_WITH_AES_128_CBC_SHA256* TLS_DHE_DSS_WITH_AES_128_GCM_SHA256* TLS_DHE_RSA_WITH_AES_128_CBC_SHA* TLS_DHE_RSA_WITH_AES_128_CBC_SHA256* TLS_DHE_RSA_WITH_AES_128_GCM_SHA256TLS_DH_anon_WITH_AES_128_CBC_SHATLS_DH_anon_WITH_AES_128_CBC_SHA256TLS_DH_anon_WITH_AES_128_GCM_SHA256* TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA* TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_NULL_SHA* TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA* TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_NULL_SHA* TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA* TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA* TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256* TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDH_ECDSA_WITH_NULL_SHA* TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA* TLS_ECDH_RSA_WITH_AES_128_CBC_SHA* TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256* TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256TLS_ECDH_RSA_WITH_NULL_SHATLS_ECDH_anon_WITH_3DES_EDE_CBC_SHATLS_ECDH_anon_WITH_AES_128_CBC_SHATLS_ECDH_anon_WITH_NULL_SHA* TLS_EMPTY_RENEGOTIATION_INFO_SCSVTLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHATLS_KRB5_WITH_3DES_EDE_CBC_MD5TLS_KRB5_WITH_3DES_EDE_CBC_SHATLS_KRB5_WITH_DES_CBC_MD5TLS_KRB5_WITH_DES_CBC_SHA* TLS_RSA_WITH_AES_128_CBC_SHA* TLS_RSA_WITH_AES_128_CBC_SHA256* TLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_NULL_SHA256
6. Configure ciphers in server.xml
There are various TLS Protocols. For more information, review the following table:
Name | Protocol |
---|---|
SSLv2 | SSL version 2 protocol |
SSLv3 | SSL version 3 protocol |
TLSv1 | TLS version 1.0 protocol (defined in RFC 2246) |
TLSv1.1 | TLS version 1.1 protocol (defined in RFC 4346) |
TLSv1.2 | TLS version 1.2 protocol (defined in RFC 5246) |
SSLv2Hello | Currently, the SSLv3, TLSv1, and TLSv1.1 protocols allow you to send SSLv3, TLSv1, and TLSv1.1 hellos encapsulated in an SSLv2 format hello. Some SSL/TLS servers do not support the v2 hello format and require that client hellos conform to the SSLv3 or TLSv1 client hello formats. The SSLv2Hello option controls the SSLv2 encapsulation. If SSLv2Hello is disabled on the client, then all outgoing messages will conform to the SSLv3/TLSv1 client hello format. If SSLv2Hello is disabled on the server, then all incoming messages must conform to the SSLv3/TLSv1 client hello format. |
Follow these steps to configure the ciphers settings:
- In the Cluster Management Console, stop the Analytics Service.
- Backup the
server.xml
file in<INCORTA_NODE_INSTALLATION_PATH>/IncortaNode/services/<UUID>/conf/
. Replace<UUID>
with the value found inservices.index
. - Edit the
server.xml
file. - Manage which ciphers you use for Tomcat by adding a
ciphers
attribute to the connector section ofserver.xml
. - Configure TLS protocols. You can remove
sslProtocol
and use thesslEnabledProtocols
attribute to control SSL protocols. - Replace the values of keystoreFile, keystorePass, and keyAlias with your values. Also, replace
<UUID>
with the value found inservices.index
.
<Connectorport="8443"protocol="HTTP/1.1"SSLEnabled="true"maxThreads="150"scheme="https"URIEncoding="UTF-8"secure="true" clientAuth="false"sslEnabledProtocols="TLSv1.1,TLSv1.2"maxHttpHeaderSize="10485760"maxPostSize="10485760"ciphers="TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDH_ECDSA_WITH_RC4_128_SHA,TLS_ECDH_RSA_WITH_RC4_128_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_EMPTY_RENEGOTIATION_INFO_SCSVF"keystoreFile="<INCORTA_NODE_INSTALLATION_PATH>/IncortaNode/services/<UUID>/keystore.jks"keystorePass="incorta123"keyAlias="incorta" />
7. Enable the Secure Flag in context.xml
By default, Incorta does not set the secure flag on the JSESSIONID and XSRF-TOKEN cookies.
The Secure flag is a Tomcat configuration setting. The flag informs a web browser that a cookie should only be sent to the web server application using HTTPS. Even with HTTPS enabled, if the Secure flag is not set to true, a web browser will send the cookie value over HTTP.
The JSESSIONID cookie contains information that the Incorta Direct Data Platform uses for authentication and authorization. The XSRF_TOKEN cookie contains an encrypted CSRF token for client-side JavaScript calls and is useful in preventing cross-site request forgery attacks.
To enable the Secure Flag, follow these steps:
- Backup the
context.xml
file in:
<INCORTA_NODE_INSTALLATION_PATH>/IncortaNode/services/<UUID>/conf/
Replace <UUID>
with the value found in services.index
.
Edit the
context.xml
file.Add the following entity:
<Environment name="JndiSessionCookieConfigListener/secure" type="java.lang.String" override="false" value="true" />
- Save your changes to the file.
8. Restart the Analytics Service
- In the Cluster Management Console, start the Analytics Service.
- In Chrome or Firefox, visit the Incorta Direct Data Platform sign in page. *All cookies are now being set with secure flag in response. Use Firefox to check which cipher is used for the connection. Weaker ciphers like 3DES ones should not be part of this list to avoid attacks (for example, the sweet32:birthday attack).
- Sign in to Incorta.
For more information on how to secure Tomcat with TLS, see 15 Ways to Secure Apache Tomcat 8.