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?