|
Hardening the MarkLogic App Server HTTPS connection
14 October 2022 09:21 AM
|
|
IntroductionRecent exploits in the TLS protocol, such as POODLE, FREAK, LogJam, and SLOTH, have rendered TLSv1.0, TLSv1.1 and SSLv3 largely obsolete. Additionally, standards councils such as PCI (Payment Card Industry) and NIST (National Institute of Standards & Technology) are moving to disallow the use of these protocols. This article will describe the MarkLogic configuration changes needed to harden a MarkLogic HTTP Application Server so that only secure versions of TLSv1.2 are used and where clients attempting to connect with TLSv1.1 or earlier protocols are rejected. ConfigurationThe TLS protocol versions accepted and the Cipher suites selected are controlled by the specification list set in the "SSL Ciphers" field on the HTTP App Server Configuration panel: The format of the specification list follows the OpenSSL format described in the OpenSSL Cipher suite documentation and comprises one or more colon ":" separated ciphers strings which control which cipher suites are enabled or disabled. The default specification used by MarkLogic enables ALL ciphers except those that are considered of LOW encryption and places them in order of @STRENGTH ALL:!LOW:@STRENGTH While sufficient for a lot of needs, the default settings still allow for cipher negotiations that are no longer considered secure or weak signature algorithms, such as MD2 and MD5. The following cipher specification string enhances security by only permitting High strength ciphers and disabling weak or vulnerable ciphers. EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!EDH:!RC4 For sites requiring even higher levels of security, restricting the ciphers available to a specific list can provide a more advanced level of control of the ciphers used. For example, the following cipher suite list restricts algorithms to those used by TLSv1.2 only. You should therefore disable all other TLS protocols as described below before using this setting in MarkLogic. DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256 The following string restricts the algorithms available by only permitting TLSv1.2 ciphers using a 256bit key. However, while this increases security even further, it is at risk of being incompatible with many browsers and applications and should only be used after thorough testing. DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
At this stage, while the MarkLogic HTTP Application Server is now using more robust security, it will still permit a client to connect using TLSv1.0 or TLsv1.1. To comply with PCI DSS 3.2 and other recommended security standards, compliant sites must stop using TLSv1.0 before 30th June 2018 while NIST SP 800-52 requires that sites only use TLSv1.1 with a recommendation to use TLSv1.2 where possible. Note: Since this article was written, the MarkLogic server has added an administrator function to disable individual SSL and TLS protocol versions. If you are still running MarkLogic version 8.0-5 or earlier, you can continue to use the solution outlined below. Otherwise, users of MarkLogic 9 or later should use the new AppServer Set SSL Disabled Protocols function to control which SSL and TLS protocol versions are available. The following XQuery code, when run against the Security Database, will disable all but TLSv1.2 on MarkLogic 9 or later.
xquery version "1.0-ml"; import module namespace admin = "http://marklogic.com/xdmp/admin" let $config := admin:get-configuration()
Run the following Xquery code to confirm the weaker TLS Protocols have been disabled
xquery version "1.0-ml"; import module namespace admin = "http://marklogic.com/xdmp/admin" at "/MarkLogic/admin.xqy"; Output Warning: Disabling all but TLSv1.2 and restricting available ciphers may break connectivity with applications and browsers configured to use SSLv3, TLSv1.0 or TLSv1.1. MarkLogic recommends that you test thoroughly in a lower QA environment before disabling any algorithms and protocols in a production environment. HTTP Strict-Transport-Security The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) informs browsers that the site should only be accessed using HTTPS and that any future attempts to access it using HTTP should automatically be converted to HTTPS. Set the "enable hsts header" to True to enable HSTS for the AppServer when dictated by your Security requirements. TLSv1.2 and browser support (MarkLogic 8 only) For TLSv1.2, older browsers should be upgraded to current versions. These changes may require users accessing your application to upgrade older browsers such as Firefox < 27.0 or Internet Explorer < 11.0, as these versions do not support TLSv1.2 by default. The MarkLogic App Server utilizes OpenSSL, which does not explicitly support enabling or disabling a specific TLS protocol version. However, you effectively get the same outcome by disabling all cipher suites associated with a particular version. SSLv3, TLSv1.0 & TLSv1.1 share the same common ciphers, so adding "!SSLv3" and "!TLSv1.0 "to the cipher specification will cause all client connection attempts using any of these protocols to fail, including "TLSv1.1". EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!EDH:!RC4:!SSLv3:!TLSv1.0 Testing using the OpenSSL s_client utility shows that attempts to connect using TLSv1.0 fail with SSL alert 40, indicating no common cipher was available. openssl s_client -connect 192.168.99.100:8010 -debug -tls1 While connecting using TLSv1.2 is successful. openssl s_client -connect 192.168.99.100:8010 -debug -tls1_2 Further reading
On MarkLogic Security Certification | |
 (6 vote(s)) |