The default out of the box configuration is designed firstly for maximum interoperability allowing any client to connect. They dont want to discriminate and provide you with SSL that you cant use. The second goal is to provide high levels of security by enabling the strongest and fastest ciphers, thus today you will find that the client often connects with AES128GCM using Elliptic Curve Key generation. The third is to reluctantly cut off the oldest ciphers that are deemed weak. For instance long ago we made a decision to not use 3DES as it was the weakest, then when RC4 was deamed insecure, 3DES made a come back. The reason that the oldest clients like IE6 on windows XP support at best SSLv3 with 3DES or RC4, so the options are pretty limited. The problem is that neither of these two should be used if you want performance or security, just SSL for the sake of SSL. SSL Labs maintains an excellent list of clients here. I hope to add to this shortly.

SSL almost needs to be considered a personal statement as per your goals and the content of your website. If you are running a public site which like this provides only information which may as well be HTTP, then the ideal selection is interoperability & performance. If SSL has some issues, well who cares, the risk is limited to a stream mitm only, no user data is going to be compromised. You need to think about why you are using SSL and even if SSL is even required. For instance, if you had a HTTP website which provides public information and you wish to use Secure SSL for the sake of beng secure, then a bunch of your users may not be able to connect. This is why if you browse google, although they use mandatory SSL, they provide the oldest and weakest ciphers as options so that anyone can connect. This is SSL for the sake of SSL. Its a hard call to either alienate potential customers from not being able to open your website, vs getting an A+ in SSL labs sever test to stimiluate your ego. For instance you cant get A+ without HSTS, but in enabling HSTS and forcing HTTPS you turn off the ability to use HTTP, so you cant use HTTP for old clients and have strong SSL for good clients. Its an arguement if SSL is a privelidge or a right. Personally i think its a right and i would rather leave an HTTP version for old clients and then only provide good strong SSL as a statement. As an engineer I want people to upgrade and patch so I will offer strong SSL ONLY and make people upgrade for the right to use SSL.

I like the approach of using a specific list of ciphers that meet the needs of the website. for example:

Configuration Options

Configure for Performance

You can custom test the performance of SSL on your server using "openssl speed". This will test every cipher it has and take a while so specifiying the group or exact will speed things up eg "openssl speed aes" or "openssl speed aes-128-cbc" (CBC is the default AES type in SSL)

Give Preference to:

  • TLS1.0 and TLS1.2
  • AES as CPUs have hardware accelleration via AES-NI
  • 128bit ciphers
  • 2048bit RSA/DH keys
  • SHA1 or SHA256
  • Stream Ciphers before Block Ciphers
  • RC4 / Stream ciphers for performance - use internally only

Configure for Interoperability

To get the widest support while still valuing some security, the default of AES 128 in TLS1.0 would suffice.

Give Preference to:

  • TLS1.0 and TLS1.2
  • AES is supported almost universally
  • 128bit ciphers as old browsers support weaker versions
  • 2048bit RSA/DH keys
  • SHA1 or SHA256
  • Enable 3DES for legacy support (old browsers only options are RC4 or 3DES)

Dont use HSTS if you want 100% browser compatibility. Offer HTTP alternative because it is the only way to offer total interoperability.

Configure for Security

To achive good security, you must be prepared to cut off old clients and use fast CPUs to offset the requierments of good encryption.

Give Preference to:

  • TLS 1.2 only
  • 256bit ciphers
  • 3072bit+ RSA/DH keys
  • SHA256+
  • Authenticated encryption schemes GCM / CCM
  • AES, Camellia or Chacha20
  • PFS & HSTS mandatory.

Configure for SuiteB

To achive very high end security, you have to cut the ties with old systems, and cut off chrome & firefox.

Restrict to:

  • TLS 1.2
  • 128bit Cipher
  • RSA/DH 2048+
  • SHA256+
  • ECDH 256+

camellia (japan) & gost (russia) not supported for obvious reasons

NSA Suite B SSL (rfc link)

The NSA Suite B is approached with a bit of sceptacism. On one hand how do we trust the recommendations of an agency that goes out of its way to subvert encryption to meet its own need to gather intelligence (or it just screwed up its own encryption), and on the other hand why shouldnt we trust the recommendations of an agency who has gone out of its way to provide guidance on protecting businesses and its partners. For instance the NSA guide to configuring Cisco Routers was an excellent applied security configuration resource. For now lets put fears aside and believe that they have the interests of their partners at hand, and look at the integration with SSL and how we can provide these rigid levels of encryption and push SSL to its limits. On a note I started deriving this from the NSA brief guidance source here, then swapped to the RFC for additional guidance on things implied like PFS(E). On a note, the guidance is by NIST

For NSA Secret (128bit):

Server Settings:
  • TLS 1.2
  • 128 Bit Cipher
  • 2048bit RSA/DH keys
  • SHA256
  • ECDH secp284r1
  • PFS & Authenticated Encryption

Compliant Browsers:

  • Safari
  • Internet Explorer
  • Firefox
  • Chrome

Compliant Ciphers:


For NSA Top Secret (192bit)):

Server Settings:
  • TLS 1.2
  • 256bit cipher
  • >3072bit RSA/DH keys
  • SHA384
  • ECDH secp384r1
  • PFS & Authenticated Encryption (AEAD Mode)

Compliant Browsers:

  • Safari (best ssl support)
  • Internet Explorer (second best support)

Non Compliant Browsers:

  • Firefox (doesnt offer 256bit AES in TLS1.2)
  • Chrome (only supports chacha in 256bit/TLS1.2)

Compliant Ciphers:


NZISM SSL (external link)

The ISM indicates that RSA is no longer acceptable and all keys must be Eliptic Curve based. The ISM also implies that the limit must be used as the minimum which I appreciate the view of. Therefore in my understanding, GCM must be used which implies tls1.2 only, and the highest strength configuation is currently AES256-GCM-SH384. Therefore TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 would be the only compliant cipher with secp521r.

Security is a Priviledge

Security is a priviledge, not a right. To maintain priviledge, you must upgrade and patch your technology, not expect technology to downgrade to you. In other words if youre not patched, you dont deserve SSL. This section was about experimenting with the upper limits of SSL, but is now a blunt minimum.

This Server

  • TLS 1.2 only
  • 256bit ciphers only
  • 4096bit RSA, 4096 DH keys... sets a standard
  • SHA384 for security in TLS1.2
  • Authenticated encryption GCM for security
  • AES & Chacha20
  • PFS & HSTS mandatory.
  • ECDH secp521r1 (in 2016 only Safari worked
  • Session Resumption On
  • Pinning enabled

Legacy Mode (no GCM or Eliptic Curve)

  • TLS 1.2 in legacy mode
  • 256bit
  • 4096bit DHE
  • SHA384/RSA
  • PFS & HSTS
  • No ECDH
  • Non PFS Ciphers: TLS_RSA_WITH_AES_256_CBC_SHA256 and TLS_RSA_WITH_AES_128_CBC_SHA256