# disable weak ciphers
# 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 must have a certificate using SHA 256 to obtain an A on the SSL labs tester.
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
# Only allow TLS protocol version 1.0, 1.1 and 1.2
SSLProtocol -SSLV3 -SSLV2 TLSv1.2 TLSv1.1 TLSv1
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.
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:
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
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.
LoadModule headers_module libexec/mod_headers.so
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.
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.
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.
To address the main concerns reported against the Identity Server, perform the following tasks:
verify following parameters exist in the /opt/novell/nam/idp/conf/server.xml IDP connector with the right values.
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.
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.
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
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="188.8.131.52" 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.
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="184.108.40.206" 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" />