Recommended configurations

Three configurations are recommended. Pick the right configuration depending on your audience. If you do not need backward compatibility, and are building a service for modern clients only (post FF27), then use the Modern configuration. Otherwise, prefer the Intermediate configuration. Use the Old backward compatible configuration only if your service will be accessed by very old clients, such as Windows XP IE6, or ancient libraries & bots.

Modern compatibility

For services that don't need backward compatibility, the parameters below provide a higher level of security. This configuration is compatible with Firefox 27, Chrome 22, IE 11, Opera 14 and Safari 7.

• Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
• Versions: TLSv1.1, TLSv1.2
• RSA key size: 2048
• DH Parameter size: 2048
• Elliptic curves: secp256r1, secp384r1, secp521r1 (at a minimum)
• Certificate signature: SHA-256
• HSTS: max-age=15724800

Intermediate compatibility (default)

For services that don't need compatibility with legacy clients (mostly WinXP), but still need to support a wide range of clients, this configuration is recommended. It is is compatible with Firefox 1, Chrome 1, IE 7, Opera 5 and Safari 1.

• Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
• Versions: TLSv1, TLSv1.1, TLSv1.2
• RSA key size: 2048
• DH Parameter size: 2048 (1024 tolerable)
• Elliptic curves: secp256r1, secp384r1, secp521r1 (at a minimum)
• Certificate signature: SHA-256

Old backward compatibility

This is the old ciphersuite that works with all clients back to Windows XP/IE6. It should be used as a last resort only.

• Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
• Versions: SSLv3, TLSv1, TLSv1.1, TLSv1.2
• RSA key size: 2048
• DH Parameter size: 1024
• Elliptic curves: secp256r1, secp384r1, secp521r1
• Certificate signature: SHA-1 (windows XP pre-sp3 is incompatible with sha-256)

If your version of OpenSSL is old, unavailable ciphers will be discarded automatically. Always use the full ciphersuite above and let OpenSSL pick the ones it supports.

The ordering of a ciphersuite is very important because it decides which algorithms are going to be selected in priority. The recommendation above prioritizes algorithms that provide perfect forward secrecy.

The listing below shows the list of algorithms returned by this ciphersuite. If you have to pick them manually for your application, make sure you keep this ordering.

Older versions of OpenSSL may not return the full list of algorithms. AES-GCM and some ECDHE are fairly recent, and not present on most versions of OpenSSL shipped with Ubuntu or RHEL. This listing below was obtained from a freshly built OpenSSL.

The ciphers are described here: http://www.openssl.org/docs/apps/ciphers.html

Prioritization logic

1. ECDHE+AESGCM ciphers are selected first. These are TLS 1.2 ciphers and not widely supported at the moment. No known attack currently target these ciphers.
2. PFS ciphersuites are preferred, with ECDHE first, then DHE.
3. SHA256 signature is preferred to SHA-1 in ciphers and certificates. MD5 is disallowed entirely.
4. AES 128 is preferred to AES 256. There has been [discussions] on whether AES256 extra security was worth the cost, and the result is far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks.
5. In the backward compatible ciphersuite, AES is preferred to 3DES. BEAST attacks on AES are mitigated in TLS 1.1 and above, and difficult to achieve in TLS 1.0. In the non-backward compatible ciphersuite, 3DES is not present.
6. RC4 is removed entirely. 3DES is used for backward compatibility. See discussion in #RC4_weaknesses

Mandatory discards

• aNULL contains non-authenticated Diffie-Hellman key exchanges, that are subject to Man-In-The-Middle (MITM) attacks
• eNULL contains null-encryption ciphers (cleartext)
• EXPORT are legacy weak ciphers that were marked as exportable by US law
• RC4 contains ciphers that use the deprecated ARCFOUR algorithm
• DES contains ciphers that use the deprecated Data Encryption Standard
• SSLv2 contains all ciphers that were defined in the old version of the SSL standard, now deprecated
• MD5 contains all the ciphers that use the deprecated message digest 5 as the hashing algorithm

Forward Secrecy

The concept of forward secrecy is simple: client and server negotiate a key that never hits the wire, and is destroyed at the end of the session. The RSA private from the server is used to sign a Diffie-Hellman key exchange between the client and the server. The pre-master key obtained from the Diffie-Hellman handshake is then used for encryption. Since the pre-master key is specific to a connection between a client and a server, and used only for a limited amount of time, it is called Ephemeral.

With Forward Secrecy, if an attacker gets a hold of the server's private key, it will not be able to decrypt past communications. The private key is only used to sign the DH handshake, which does not reveal the pre-master key. Diffie-Hellman ensures that the pre-master keys never leave the client and the server, and cannot be intercepted by a MITM.

DHE handshake and dhparam

When an ephemeral Diffie-Hellman cipher is used, the server and the client negotiate a pre-master key using the Diffie-Hellman algorithm. This algorithm requires that the server sends the client a prime number and a generator. Neither are confidential, and are sent in clear text. However, they must be signed, such that a MITM cannot hijack the handshake.

As an example, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 works as follow:

1. Server sends Client a [SERVER KEY EXCHANGE] message during the SSL Handshake. The message contains:
   1. Prime number p
   2. Generator g
   3. Server's Diffie-Hellman public value A = g^X mod p, where X is a private integer chosen by the server at random, and never shared with the client. (note: A is called pubkey in wireshark)
   4. signature S of the above (plus two random values) computed using the Server's private RSA key
2. Client verifies the signature S
3. Client sends server a [CLIENT KEY EXCHANGE] message. The message contains:
   1. Client's Diffie-Hellman public value B = g^Y mod p, where Y is a private integer chosen at random and never shared. (note: B is called pubkey in wireshark)
4. The Server and the Client can now calculate the pre-master secret using each other's public values:
   1. server calculates PMS = B^X mod p
   2. client calculates PMS = A^Y mod p
5. Client sends a [CHANGE CIPHER SPEC] message to the server, and both parties continue the handshake using ENCRYPTED HANDSHAKE MESSAGES

The size of the prime number p constrains the size of the pre-master key PMS, because of the modulo operation. A smaller prime almost means weaker values of A and B, which could leak the secret values X and Y. Thus, the prime p should not be smaller than the size of the RSA private key.

OCSP Stapling

When connecting to a server, clients should verify the validity of the server certificate using either a Certificate Revocation List (CRL), or an Online Certificate Status Protocol (OCSP) record. The problem with CRL is that the lists have grown huge and takes forever to download.

OCSP is much more lightweight, as only one record is retrieved at a time. But the side effect is that OCSP requests must be made to a 3rd party OCSP responder when connecting to a server, which adds latency and potential failures. In fact, the OCSP responders operated by CAs are often so unreliable that browser will fail silently if no response is received in a timely manner. This reduces security, by allowing an attacker to DoS an OCSP responder to disable the validation.

The solution is to allow the server to send its cached OCSP record during the TLS handshake, therefore bypassing the OCSP responder. This mechanism saves a roundtrip between the client and the OCSP responder, and is called OCSP Stapling.

The server will send a cached OCSP response only if the client requests it, by announcing support for the status_request TLS extension in its CLIENT HELLO.

Most servers will cache OCSP response for up to 48 hours. At regular intervals, the server will connect to the OCSP responder of the CA to retrieve a fresh OCSP record. The location of the OCSP responder is taken from the Authority Information Access field of the signed certificate. For example, with StartSSL:

Authority Information Access: 
      OCSP - URI:http://ocsp.startssl.com/sub/class1/server/ca

Support for OCSP Stapling can be tested using the -status option of the OpenSSL client.

$ openssl s_client -connect monitor.mozillalabs.com:443 -status
...
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
...

Session Resumption

Session Resumption is the ability to reuse the session secrets previously negotiated between a client and a server for a new TLS connection. This feature greatly increases the speed establishment of TLS connections after the first handshake, and is very useful for connections that use Perfect Forward Secrecy with a slow handshake like DHE.

Session Resumption can be performed using one of two methods:

1. session identifier: When establishing a first session, the server generates an arbitrary session ID sent to the client. On subsequent connections, the client sends the session ID in the CLIENT HELLO message, indicating to the server it wants to reuse an existing state. If the server can find a corresponding state in its local cache, it reuse the session secrets and skips directly to exchanging encrypted data with the client. If the cache stored on the server is compromised, session keys from the cache can be used to decrypt past and future sessions.
2. session tickets: Storing a cache on the server might be problematic for systems that handle very large numbers of clients. Session tickets provide an alternative where the server sends the encrypted state (ticket) to the client instead of storing it in its local cache. The client can send back the encrypted state to the server in subsequent connections, thus allowing session resumption. This method requires symmetric keys on the server to encrypt and decrypt session tickets. If the keys are compromised, an attacker obtains access to session keys and can decrypt past and future sessions.

Session resumption is a very useful performance feature of TLS, but also carries a significant amount of risk. Most servers do not purge sessions or ticket keys, thus increasing the risk that a server compromise would leak data from previous (and future) connections.

The current recommendation for web servers is to enable session resumption and benefit from the performance improvement, but to restart servers daily when possible. This ensure that sessions get purged and ticket keys get renewed on a regular basis.

HSTS: HTTP Strict Transport Security

[HSTS] is a HTTP header sent by a server to a client, indicating that the current site must only be accessed over HTTPS until expiration of the HSTS value is reached.

The header format is very simple, composed only of a max-age parameter that indicates when the directive should expire. max-age is expressed in seconds. A typical value is 15724800 seconds, or 6 months.

Strict-Transport-Security: max-age=15724800

HSTS is becoming more and more of a standard, but should only be used when the site's operators are confident that HTTPS will be available continuously for the duration of max-age. Once the HSTS header is sent to client, HTTPS cannot be disabled on the site until the last client has expired its HSTS record.

HPKP: Public Key Pinning Extension for HTTP

HPKP is an experimental HTTP header sent by a server to a client, to indicate that some certificates related to the site should be pinned in the client. The client would thus refuse to establish a connection to the server if the pining does not comply.

Due to its experimental nature, HPKP is currently not recommended on production sites. More informations can be found on the [MDN description page].

Recommended Server Configurations

Try out our configuration generator to create a sample configuration file for various servers. Click the image below:

Nginx

Nginx provides the best TLS support at the moment. It is the only daemon that provides OCSP Stapling, custom DH parameters, and the full flavor of TLS versions (from OpenSSL).

The detail of each configuration parameter, and how to build a recent Nginx with OpenSSL, is at the end of this document.

server {
    listen 443 ssl;

    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 5m;
    ssl_session_cache shared:SSL:5m;

    # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
    ssl_dhparam /path/to/dhparam.pem;

    # Intermediate configuration. tweak to your needs.
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers '<paste intermediate ciphersuite here>';
    ssl_prefer_server_ciphers on;
 
    # Enable this if your want HSTS (recommended)
    # add_header Strict-Transport-Security max-age=15768000;
 
    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;
    ## verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
    resolver <IP DNS resolver>;
 
    ....
}

Apache

Apache supports OCSP Stapling, but only in httpd 2.3.3 and later.

In Apache 2.4.6, the DH parameter is always set to 1024 bits and is not user configurable. Future versions of Apache will automatically select a better value for the DH parameter. The configuration below is recommended.

<VirtualHost *:443>
    ...
    SSLEngine on
    SSLCertificateFile      /path/to/signed_certificate
    SSLCertificateChainFile /path/to/intermediate_certificate
    SSLCertificateKeyFile   /path/to/private/key
    SSLCACertificateFile    /path/to/all_ca_certs

    # Intermediate configuration, tweak to your needs
    SSLProtocol             all -SSLv2 -SSLv3
    SSLCipherSuite          <paste intermediate ciphersuite here>
    SSLHonorCipherOrder     on
    SSLCompression          off

    # OCSP Stapling, only in httpd 2.3.3 and later
    SSLUseStapling          on
    SSLStaplingResponderTimeout 5
    SSLStaplingReturnResponderErrors off
    # On Apache 2.4+, SSLStaplingCache must be set *outside* of the VirtualHost
    SSLStaplingCache        shmcb:/var/run/ocsp(128000)
 
    # Enable this if your want HSTS (recommended)
    # Header add Strict-Transport-Security "max-age=15768000"
 
    ...
</VirtualHost>
# TLS Session cache, outside of virtual host, apache 2.4+
# the path doesn't need to exist
SSLSessionCache         shmcb:/path/to/ssl_gcache_data(5120000)

Haproxy

SSL support in Haproxy is stable in 1.5. Haproxy supports OCSP Stapling and custom DH parameters size. It can be used as a TLS termination in AWS using ELBs and the PROXY protocol. See Guidelines for HAProxy termination in AWS

global
    # set default parameters to the Intermediate configuration
    tune.ssl.default-dh-param 2048
    ssl-default-bind-ciphers <paste intermediate ciphersuite here>

frontend ft_test
    mode    http
    bind    0.0.0.0:443 ssl no-sslv3 crt /path/to/<cert+privkey+intermediate+dhparam>
    # Enable this if your want HSTS (recommended)
    # rspadd  Strict-Transport-Security:\ max-age=15768000

OCSP Stapling support

While HAProxy can serve OCSP stapled responses, it cannot fetch and update OCSP records from the CA automatically. The OCSP response must be downloaded by another process and placed next to the certificate, with a '.ocsp' extension.

/etc/haproxy/certs/
├── ca.pem
├── server_cert.pem
├── server_bundle.pem
└── server_bundle.pem.ocsp

The file 'server_bundle.pem.ocsp' must be retrieved and updated at regular intervals. A cronjob can be used for this:

$ openssl ocsp -noverify -issuer /etc/haproxy/certs/ca.pem \
-cert /etc/haproxy/certs/server_cert.pem \
-url http://ocsp.startssl.com/sub/class1/server/ca \
-no_nonce -header Host ocsp.startssl.com \
-respout /etc/haproxy/certs/server_bundle.pem.ocsp

The URL above is taken from the server certificate:

$ openssl x509 -in server_cert.pem -text | grep OCSP
OCSP - URI:http://ocsp.startssl.com/sub/class1/server/ca

Stud

Stud is a lightweight SSL termination proxy. It's basically a wrapper for OpenSSL. Stud is not being heavily developed, and features such as OCSP stapling are missing. But it is very lightweight and efficient, and with a recent openssl, supports all the TLS 1.2 ciphers.

# SSL x509 certificate file. REQUIRED.
# List multiple certs to use SNI. Certs are used in the order they
# are listed; the last cert listed will be used if none of the others match
#
# type: string
pem-file = "<concatenate cert + privkey + dhparam>"
 
# SSL protocol.
#
tls = on
ssl = on
 
# List of allowed SSL ciphers.
#
# Run openssl ciphers for list of available ciphers.
# type: string
ciphers = "<paste intermediate ciphersuite here>"
 
# Enforce server cipher list order
#
# type: boolean
prefer-server-ciphers = on

Amazon Web Services Elastic Load Balancer (AWS ELB)

The ELB service supports TLS 1.2 and ciphers ordering, but lacks support for custom DH parameters and OCSP Stapling.

The default configuration of ELBs has old settings, that can be customized in the Web Console or via the API. We recommend that you use the Security/Server_Side_TLS#elb_ciphers.py to enforce the right TLS configuration on an elastic load balancer.

Below is a side-by-side comparison of the 'intermediate' recommended configuration versus the default ELB configuration. The top ciphers are the same, but SSLv3 and various deprecated ciphers are removed from the intermediate configuration.

If you want better control over TLS than ELB provide, another option in AWS is to terminate SSL on HAproxy, using the PROXY protocol between ELB and HAproxy. https://jve.linuxwall.info/ressources/taf/haproxy-aws/

Zeus Load Balancer(Riverbed Stingray)

ZLB supports TLS1.2 and OCSP Stapling. It lacks support for Elliptic Curves and AES-GCM. As of Riverbed Steelhead 9.6, TLS parameters are configurable per site.

The recommended prioritization is:

1. SSL_DHE_RSA_WITH_AES_128_CBC_SHA
2. SSL_DHE_RSA_WITH_AES_256_CBC_SHA
3. SSL_RSA_WITH_AES_128_CBC_SHA
4. SSL_RSA_WITH_AES_256_CBC_SHA
5. SSL_RSA_WITH_3DES_EDE_CBC_SHA

The following strings can be used directly in the ZLB configuration, under global settings > ssl3_ciphers. with 3DES

without 3DES

While the recommended DH prime size is 2048, problems with client libraries, such as Java 6, make this impossible to deploy for now. Therefore, a DH prime of 1024 bits should be used until all clients are compatible with larger primes.

Citrix Netscaler

There is an issue with Netscaler's TLS1.2 and DHE ciphers. When DHE is used, the TLS handshake fails with a fatal 'Decode error'. TLS1.2 works fine with AES and RC4 ciphers.

Netscaler documentation is at http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-map/ns-ssl-supported-ciphers-list-ref.html

The configuration sample below shows how a default ciphersuite object can be created and attached to a vserver.

First, create a default ciphersuite that can be used in all vservers.

> add ssl cipher MozillaDefault
> bind ssl cipher MozillaSecure -cipherName TLS1-DHE-DSS-AES-128-CBC-SHA
> bind ssl cipher MozillaSecure -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA
> bind ssl cipher MozillaSecure -cipherName TLS1-DHE-DSS-AES-256-CBC-SHA
> bind ssl cipher MozillaSecure -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA
> bind ssl cipher MozillaSecure -cipherName TLS1-AES-128-CBC-SHA
> bind ssl cipher MozillaSecure -cipherName TLS1-AES-256-CBC-SHA
> bind ssl cipher MozillaSecure -cipherName SSL3-DES-CBC3-SHA

Second, create a DH parameter. If backward compatibility with Java 6 isn't needed, use 2048 instead of 1024.

> create ssl dhparam /nsconfig/ssl/dh1024.pem 1024 -gen 5

Third, configure the vserver to use the default ciphersuite and DH parameter.

> add ssl certKey <domain> -cert <cert> -key <key>
> add ssl certKey <intermediateCertName> -cert <intermediateCertName>
> link ssl certKey <domain> <intermediateCertName>
> set ssl vserver <domain>:https -eRSA ENABLED
> bind ssl vserver <domain>:https -cipherName MozillaDefault
> set ssl vserver <domain>:https -dh ENABLED -dhFile /nsconfig/ssl/dh1024.pem -dhCount 1000

The resulting configuration can be viewed with 'show ssl'

> show ssl vserver marketplace.firefox.com:https

    Advanced SSL configuration for VServer marketplace.firefox.com:https:
    DH: ENABLED    DHParam File: /nsconfig/ssl/dh1024.pem    Refresh Count: 1000
    Ephemeral RSA: ENABLED        Refresh Count: 0
    Session Reuse: ENABLED        Timeout: 120 seconds
    Cipher Redirect: DISABLED
    SSLv2 Redirect: DISABLED
    ClearText Port: 0
    Client Auth: DISABLED
    SSL Redirect: DISABLED
    Non FIPS Ciphers: DISABLED
    SNI: DISABLED
    SSLv2: DISABLED    SSLv3: ENABLED    TLSv1: ENABLED
    Push Encryption Trigger: Always
    Send Close-Notify: YES

1)    CertKey Name: marketplace.mozilla.org.san    Server Certificate
1)    Cipher Name: MozillaSecure    Description: User Created Cipher Group

Go

The Go standard library supports TLS1.2 and a limited subset of ECDHE and GCM ciphers. To configure a Go program accepting TLS connections, use the following code:

CipherScan

See https://github.com/jvehent/cipherscan

Cipherscan is a small Bash script that connects to a target and list the preferred Ciphers. It's an easy way to test a web server for available ciphers, PFS key size, elliptic curves, support for OCSP Stapling, TLS ticket lifetime and certificate trust.

SSL Labs (Qualys)

Available here: https://www.ssllabs.com/ssltest/

Qualys SSL Labs provides a comprehensive SSL testing suite.

GlobalSign has a modified interface of SSL Labs that is interesting as well: https://sslcheck.globalsign.com/

elb_ciphers.py

This python script uses boto to create a TLS policy and apply it to a given load balancer. Make sure you have an AWS access key configured in ~/.boto to use this script, then invoke it as follow:

If no mode is specified, the intermediate mode will be used. The modes are 'old', 'intermediate' and 'modern', and map to the recommended configurations.