Howto get an A+ rating for Access Manager against SSL Labs

Howto get an A+ rating for Access Manager against SSL Labs

NetIQ technical services gets a lot of requests from customers reporting poor ratings when evaluated by SSLLABs tool (https://www.ssllabs.com/). The following document outlines some changes that will hopefully help move you towards an A+ rating.

ssllabs-image-1
 

Changes Needed on Access Manager Appliance or Access Gateway Appliance




  1. You must have a certificate using SHA 256 to obtain an A+ on the SSL labs tester.


  2. Disable weak ciphers (SSLCipherSuite) and protocols (SSLProtocol) with known vulnerabilities by adding the following Advanced Options (https://www.netiq.com/documentation/access-manager-41/admin/data/b3kjnio.html) to the Access Gateway configuration screen. By simply adding these statements, the SSLLABs rating should change to an A-. More details on each option is available from http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslciphersuite and http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslprotocol respectively.




    # disable weak ciphers
    SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!DES:!RC4:ALL:!EDH:
    # Only allow TLS protocol version 1.0, 1.1 and 1.2
    SSLProtocol -SSLV3 -SSLV2 +TLSv1.2 +TLSv1.1 +TLSv1



    Note:



    • It is possible to monitor the ciphers and SSL protocols associated with the incoming requests using custom mod_ssl logging described in the "Custom Log Format" section of http://httpd.apache.org/docs/2.2/mod/mod_ssl.html.

      It may be that some SSL clients start off negotiating with protocols that an administrator wants to disable, but these clients can typically upgrade to higher protocols.


    • If you plan to support IE6 or older clients, you may need to add additional cipher suites (RC4 for example). Doing so will reduce your rating.




  3. Enable Perfect Forward Secrecy (PFS) to go from A- to A rating.



    When an SSL handshake is performed, SSL information regarding what the browser/client and server are capable of doing is exchanged, validation occurs, and an SSL session key that meets both the client’s and server’s criteria is established. Once this session key is established, all subsequent communication between the client and your site is encrypted and thus secured. Historically, the most common method for negotiating the session key involved the RSA public-key cryptosystem. The RSA approach uses the server’s public key to protect the session key parameters created by the client once they are sent over to the server. The server is able to decrypt this handshake with its corresponding private key. If an attacker ever gets hold of the server’s private key, they can decrypt your SSL session and any saved SSL sessions. This is an approach that allows wireshark or ssldump tools to decrypt saved SSL communication using an exported server certificate with private key (https://www.novell.com/coolsolutions/appnote/19321.html).



    On the other hand, when Perfect Forward Secrecy is enabled, there is no link between your server’s private key and each session key. If an attacker ever gets access to your server’s private key, the attacker cannot use the private key to decrypt any of your archived sessions, thereby increasing security.



    To enable Perfect Forward Secrecy, you must do the following:




    1. Make sure the right selection of ciphers are enabled eg. place ECDHE (Elliptic Curve Diffie-Hellman) suites at the top of list, followed by the DHE (Diffie-Hellman) suites.



    2. Configure servers to enable other non-DH-key-exchange cipher suites from the list of cipher suites offered by the SSL Client.




    Apache simplifies the process with the SSLHonorCipherOrder directive at http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslhonorcipherorder. This directive indicates that Apache must respect the order of the encryption processes in SSLCipherSuite ie. that the first match found must be used. With the SSLCipherSuite list above and this directive in place, PFS will be achieved.



    # enable PFS using above cipher list with SSLHonorCipherOrder 
    SSLHonorCipherOrder on


  4. Add HTTP Strict Transport Security (https://www.owasp.org/index.php/HTTP_Strict_Transport_Security) header to get A+ status.



    HTTP Strict Transport Security (HSTS) is a web security policy mechanism which is necessary to protect secure HTTPS websites against downgrade attacks Often implemented as part of a man in the middle attack like Poodle), and which greatly simplifies protection against cookie hijacking. It allows web servers to declare that web browsers (or other complying user agents) should only interact with it using secure HTTPS connections, and never via the insecure HTTP protocol.



    HSTS simply sets a cookie in each response from the secure HTTP Web server. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.



    To enable




    1. edit the /etc/opt/novell/apache2/conf/httpd.conf and

    2. enable mod_headers library by uncommenting the line with libexec/mod_headers.so as shown
      LoadModule headers_module libexec/mod_headers.so

    3. add the 'header set' directive to add the HSTS header at the bottom of the file
      Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"



  5. To test and confirm your rating, go to the following URL, replacing $domain_name with the name of your domain.



    https://www.ssllabs.com/ssltest/analyze.html?d=$domain_name



    Note only will this show you your taing, but it will also return additional information on why we did not get 100% in each field eg.



    ssllabs-image-2



     

    ssllabs-image-3





Changes Needed on the Identity Server



The default rating with the NAM Identity Server out of the box is a C. The fact that the SSL protocols are not locked down, and that we support some weaker ciphers are the main reason for this.



ssllabs-image-4



To address the main concerns reported against the Identity Server, perform the following tasks:




  1. verify following parameters exist in the /opt/novell/nam/idp/conf/server.xml IDP connector with the right values.


    sslProtocol="TLSv1.2" sslEnabledProtocols="SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2"

    The goal is to disable SSLv2 and SSLv3 protocols as they have many known vulnerabilities. Many SSL clients however, notably JDK 6, use the SSLv2Hello protocol to handshake with the server. Using this protocol does not mean you are using SSL 2.0 or 3.0 for that matter; it is merely a handshake to determine which protocol to use and is the reason that it is included in the enabled protocols list.



  2. modify /opt/novell/nam/idp/conf/tomcat.conf and make sure the following lines exist to prevent SSL re-negotiations to take place.


    JAVA_OPTS="${JAVA_OPTS} -Dsun.security.ssl.allowUnsafeRenegotiation=false"
    #JAVA_OPTS="${JAVA_OPTS} -Djavax.net.debug=handshake,sslctx"
    JAVA_OPTS="${JAVA_OPTS} -Djdk.tls.rejectClientInitiatedRenegotiation=true"
    JAVA_OPTS="${JAVA_OPTS} -Djdk.tls.ephemeralDHKeySize=2048”


    Note: the -Djavax.net.debug is used to log the SSL handshake details to the catalina log file. This is only used during testing to view the incoming cipher requests from browsers, so that we do not restrict ciphers that could prevent a successful handshake from completing thereby impacting users.



  3. Updated JCE (no change) - Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 8 Download at http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html



    This is required to enable strong 256-bit or higher ciphers. Failure to do this will result in incomplete SSL handshakes when these string ciphers are used. For details on installing this extension, reference https://www.netiq.com/documentation/access-manager-41/bestpractices/data/bz9w3au.html



  4. Remove following weak ciphers from the default list of ciphers



    TLS_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA and removed all RC4 Ciphers listed as well.



    The complete connector looks as follows:



    <Connector NIDP_Name="connector" SSLEnabled="true" URIEncoding="utf-8" acceptCount="100" address="147.2.16.246" ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_SHA" clientAuth="false" disableUploadTimeout="true" enableLookups="false" keystoreFile="/opt/novell/devman/jcc/certs/idp/connector.keystore" keystorePass="zfF19571avcM2gJ" maxThreads="600" minSpareThreads="5" port="8443" scheme="https" secure="true" sslImplementationName="com.novell.nidp.common.util.net.server.NIDPSSLImplementation" sslProtocol="TLSv1.2" sslEnabledProtocols="SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2" />


    This gets is to an A-. Note that RC4 ciphers should not be used, but we may need them for older Internet Explorer on Windows XP. If you have these browsers still active in your setup, you will need to maintain the RC4 ciphers.



    ssllabs-image-5



    Need to get PFS enabled ... need to remove some Diffie Hellman ciphers, and add the useServerCipherSuitesOrder directive.



  5. Removed TLS_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA but still got A-


  6. Add with useServerCipherSuitesOrder entry (set to true) to get A rating.





The new connector details are shown below:



<Connector NIDP_Name="connector" SSLEnabled="true" URIEncoding="utf-8" acceptCount="100" address="147.2.16.246" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA" clientAuth="false" disableUploadTimeout="true" enableLookups="false" keystoreFile="/opt/novell/devman/jcc/certs/idp/connector.keystore" keystorePass="zfF19571avcM2gJ" maxThreads="600" minSpareThreads="5" port="8443" scheme="https" secure="true" sslImplementationName="com.novell.nidp.common.util.net.server.NIDPSSLImplementation" useServerCipherSuitesOrder="true" sslProtocol="TLSv1.2" sslEnabledProtocols="SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2" />
Labels (1)

DISCLAIMER:

Some content on Community Tips & Information pages is not officially supported by Micro Focus. Please refer to our Terms of Use for more detail.
Comments
Thanks Neil
very useful post!
It seems like it's now getting dropped to an A because of the Strict-Transport-Security getting sent numerous times from the proxy instead of once. Is there a way to prevent the header from being sent multiple times?
Question: does this affect the websites and applications that are configured to use NAM? Do they have to have the same level of security enabled as well?
Or is this just for the security level of NAM?
Should really now be:

# disable weak ciphers
SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!DES:!3DES:!RC4:ALL:!EDH:
# Only allow TLS protocol version 1.1 and 1.2
SSLProtocol -SSLV2 -SSLV3 -TLSv1 +TLSv1.1 +TLSv1.2

And also need to correctly configure DNS CAA records.
you are a gentleman Ben .. as they add checks and our product evolves, some of the checks in original doc are outdated. This feedback will help others. Thansk!
Hi Tom, just saw this. The Apache module adds a HSTS header, as does the ESP so when we proxy ESP through AG, we get it double. You can go and manually comment out the HSTS addition in NovellAGSettings.conf to avoid this. We will fix this in 4.4.1.
this really applies to the NAM security level ie. comms in and out of the NAM components (eg. browser to AG/IDP, as well as comms from AG/IDP to web servers, LDAP stores, other AGs/IDP). As a best practice, you would need to apply same level of security to Web servers just to keep the traffic into these servers as secure as possible.
And in less than a blink of an eye, they've defined RSA as weak:

# disable weak ciphers
SSLCipherSuite !aNULL:!eNULL:!EXPORT:!DSS:!DES:!RSA:!3DES:!RC4:ALL:!EDH:
# Only allow TLS protocol version 1.1 and 1.2
SSLProtocol -SSLV2 -SSLV3 -TLSv1 +TLSv1.1 +TLSv1.2
for some reason I cannot leave a comment on your last POST below Ben. Do you kno wwhat RSA cipher it was exactly ... I can understand RC4-SHA, or export level RSA ciphersute being weak but RSA has some strong ciphers too eg. run openssl to dump ciphers on your secured platforms and you should see quite a few returned:

root@nam4:~> openssl ciphers -v|grep RSA
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP Au=RSA Enc=AES(256) Mac=SHA1
DH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH/RSA Au=DH Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DH-RSA-AES256-SHA256 TLSv1.2 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DH-RSA-AES256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DH-RSA-CAMELLIA256-SHA SSLv3 Kx=DH/RSA Au=DH Enc=Camellia(256) Mac=SHA1
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA384
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1

I'm just interested in which ones they figured were weak.
I think Wordpress limits comment reply depth. It was basically all TLS_RSA_* based ciphers....they only accept TLS_ECDHE_* as strong enough now https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com&s=172.217.5.100&hideResults=on (and I was just reading that Chrome is about to name and shame HTTP only sites)...
Versus my results now that I've updated CipherSuite https://www.ssllabs.com/ssltest/analyze.html?d=www.isam.kiwi&hideResults=on - I'd get a better rating with a trusted root, but yeah nah.
They appear to keep their readme up to date: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites
good info from github Ben - thanks !
Top Contributors
Version history
Revision #:
3 of 3
Last update:
‎2020-01-31 22:05
Updated by:
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.