SSLLabs A+, F5 LTM 11.4

We are testing a configuration to achieve an A+ grade on the SSLLabs.com server test.

The "DEFAULT" ciphers is documented in sol13156 and sol13171.

  DEFAULT = NATIVE:!MD5:!EXPORT:!DES:!DHE:!EDH:@SPEED
    Cipher  Bits    Protocols
    RC4-SHA 128 SSL3, TLS1.0, TLS1.1, TLS1.2
    AES128-SHA  128 SSL3, TLS1.0, TLS1.1, TLS1.2, DTLS1
    AES256-SHA  256 SSL3, TLS1.0, TLS1.1, TLS1.2, DTLS1
    DES-CBC3-SHA    192 SSL3, TLS1.0, TLS1.1, TLS1.2, DTLS1
    AES128-SHA256   128 TLS1.2
    AES256-SHA256   256 TLS1.2
    ECDHE-RSA-AES128-CBC-SHA    128 TLS1.0, TLS1.1, TLS1.2
    ECDHE-RSA-AES256-CBC-SHA     256    TLS1.0, TLS1.1, TLS1.2
    ECDHE-RSA-DES-CBC3-SHA     192  TLS1.0, TLS1.1, TLS1.2

The first try to correct this was to just exclude RC4 and change this to strength.

  NATIVE:!MD5:!EXPORT:!DES:!DHE:!EDH:!RC4:@STRENGTH 
    Cipher  Bits    Protocols
    AES256-SHA  256 SSL3, TLS1.0, TLS1.1, TLS1.2, DTLS1
    AES256-SHA256   256 TLS1.2
    ECDHE-RSA-AES256-CBC-SHA     256    TLS1.0, TLS1.1, TLS1.2
    DES-CBC3-SHA    192 SSL3, TLS1.0, TLS1.1, TLS1.2, DTLS1
    ECDHE-RSA-DES-CBC3-SHA     192  TLS1.0, TLS1.1, TLS1.2                        
    AES128-SHA  128 SSL3, TLS1.0, TLS1.1, TLS1.2, DTLS1
    AES128-SHA256   128 TLS1.2
    ECDHE-RSA-AES128-CBC-SHA    128 TLS1.0, TLS1.1, TLS1.2

This might look better, but it really wasn't what I was looking for. It's just bubble sorting the cipher suites based on nominal bit strength. This wasn't desirable because it sorts 3DES based on it's nominal bit strength of 192, putting it above AES128. DES is 56bit, so 3DES should really be 168bits. The current cryptologic analysis of 3DES rates it at only 112bits, due to protocol weakness. We want AES128 to appear before 3DES. The second problem is that forward secrecy suites (ECDHE) aren't being given preference. Forward Secrecy is even more important than keysize, but @STRENGTH doesn't appear to help with this. So we decided to build the cipher list by adding suites in order, making sure to avoid the COMPAT suites to maintain hardware acceleration and avoid openssl.

 !COMPAT:ECDHE+AES:ECDHE+3DES:AES:3DES:!MD5:!EXPORT:!DES:!EDH:!RC4
    Cipher  Bits    Protocols
    ECDHE-RSA-AES128-CBC-SHA    128 TLS1.0, TLS1.1, TLS1.2
    ECDHE-RSA-AES256-CBC-SHA     256    TLS1.0, TLS1.1, TLS1.2
    ECDHE-RSA-DES-CBC3-SHA     192  TLS1.0, TLS1.1, TLS1.2                        
    AES128-SHA  128 SSL3, TLS1.0, TLS1.1, TLS1.2, DTLS1                
    AES256-SHA  256 SSL3, TLS1.0, TLS1.1, TLS1.2, DTLS1
    AES128-SHA256   128 TLS1.2
    AES256-SHA256   256 TLS1.2
    DES-CBC3-SHA    192 SSL3, TLS1.0, TLS1.1, TLS1.2, DTLS1

This is pretty good, and gets an A. The 128 bit suites are before 256, which might help with performance and still be acceptable. I'd like to know how to specify 256... maybe "ECDHE+AES256:ECDHE+AES128" etc. More testing to do, and of course this is version specific and will have to be reviewed for 11.5.

The other issue is HTTP Strict Transport Security, which is required to get an A+. Currently, most major browsers support HSTS, the exception being Microsoft Internet Explorer. MS has reportedly committed to supporting HSTS in IE12, estimated aug 2014. (Hopefully they'll add GCM suites as well, but then we'll need 11.5+ for that).

We previously configured an HTTP to HTTPS 301 redirect iRule, to our HTTP/80 Virtuals:

 iRule for HTTP Virtuals redirect to HTTPS 
when HTTP_REQUEST {
   HTTP::respond 301 location "https://[HTTP::host][HTTP::uri]"
}

On HTTPS/443 Virtuals, add an "hsts_insert" iRule. We had gone over the 2010 blog, and realized that the sample iRule could be simplified. Paul seems to be trying to set an HSTS expiration date that matches the page expiration date. This is silly, you don't want people to be bouncing through HTTP redirect every time the page refreshes. The RFC and all of the samples in the HSTS wiki just show a one year or half year expiration. SSLLabs gives an A+ if your max-age is over 180 days. Simplifying this also eliminates date math in the iRule. So we just have:

Jason's Blog https://devcentral.f5.com/articles/implementing-http-strict-transport-security-in-irules

RFC 6797 http://tools.ietf.org/html/rfc6797

Wikipedia: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Simplified HSTS redirect alligned with wiki samples:

 iRule "hsts_insert" for HSTS HTTPS virtuals
when HTTP_RESPONSE {
   HTTP::header insert Strict-Transport-Security "max-age=31536000 ; includeSubDomains"
}

So with this, and making sure the Secure Negotiation options are correct, we were able to get a test site to report as A+. All the Forward Secrecy capable browsers in the SSLLabs "handshake simulation" report "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)", TLS 1.2 or TLS 1.0. We plan on putting this through our test cycle to go into production, but I wanted to see if the F5 community has thoughts first. Any thoughts?