Howto get an A rating for Access Manager against SSL Labs

0 Likes
over 6 years ago
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.





  • 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.



  • 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


  • 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

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

  • 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"



  • 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.



  • 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.




  • 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.



  • Removed TLS_DHE_RSA_WITH_AES_128_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA but still got A-


  • 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:

How To-Best Practice
Comment List
Anonymous
Parents
  • 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!
  • 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 www.ssllabs.com/.../analyze.html (and I was just reading that Chrome is about to name and shame HTTP only sites)...
Comment Children
No Data
Related Discussions
Recommended