Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

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?

5
Rate this Question
Comments on this Question
Comment made 27-Apr-2014 by uni 1145
Very interesting. Would you be able to show the complete clientssl profile you use to get the A+?
2
Comment made 10-Apr-2015 by Stephan Manthey 3792
Thanks. +1
0
Comment made 30-Nov-2015 by Colin Stubbs 122
Bear in mind HTTP_RESPONSE will not fire for Web Acceleration or other cached responses (manual use of CACHE commands in iRules for instance). You may need to insert/replace the header on both HTTP_RESPONSE and CACHE_RESPONSE events to guarantee a clients will become aware of the desire for HSTS as quickly as possible.
0

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Thanks for the detailed information, I'm sure many will find it useful.

If you want the order to be exactly what you want just use -ALL:ECDHE+AES256:ECDHE+AES128... as you suggest (that's -ALL:...). This avoids the need remove things with !.

I'm rather wary of SSLlabs myself and tend to double-check everything around ciphers using the openssl s_client functionality. I had an Apache server that SSLlabs kept giving a C and claimed was supporting EXPORT, DES and others when I knew I'd configured it not to. OpenSSL proved I was right and SSLlabs were not.

2
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

In rereading Jason's blog, I see that he was expiring HSTS one day before the certificate expires. I don't think that's really needed, unless you might have second thoughts on HTTPS, and want to remove your 301 redirect, and not buy a new SSL certificate. In that case, only, you'd want your HSTS rule to expire before the certificate. If you do that, SSLLabs won't give you an A+ if your cert is going to expire in less than 181 days. So the static max-age is really "required" to get and keep an A+.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

As an update, as of the June 20 snapshot of the OpenSSL codebase, the reported strength of the 3DES Cipher Suites is now 112 bits instead of 168. This will make @STRENGTH give AES128 priority over 3DES(112). This should flow into the next release of OpenSSL (1.0.1i), it would be nice if F5 integrated this change into the NATIVE suites to reflect the same sorting priority.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

As an update, as of the June 20 snapshot of the OpenSSL codebase, the reported strength of the 3DES Cipher Suites is now 112 bits instead of 168.

Bug alias 467015 DES-CBC3-SHA(OpenSSL DES_192_CBC3_SHA) ciphers should use BITS 112 instead of 192.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

thx to bkhowson!

my settings for 11.5 to get A+:
ECDHE+AES:ECDHE+3DES:RSA+3DES:!SSLv2:!SSLv3:!MD5:!EXPORT:!RC4
disable Renegotiation
insert Strict-Transport-Security header from above in HTTP_RESPONSE
with this, only IE6 is missing.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I personally use those ciphers (11.5+) :

DEFAULT:!RC4:ECDHE:AES-GCM:!AES128-GCM-SHA256:!AES256-GCM-SHA384:!ADH-AES256-GCM-SHA384:!ADH-AES128-GCM-SHA256:!AES256-SHA256:!AES256-SHA:@STRENGTH

I disable Renegociation on Client SSL Profile

and add HSTS irule using an irule

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

i have 11.4.1 with the following setting DEFAULT:!SSLv3:!RC4:ECDHE:!AES256-SHA256:!AES256-SHA:@STRENGTH and i get F, because of POODLE (TLS) any suggestions

0
Comments on this Answer
Comment made 17-Feb-2015 by Benoit C. 234
Hello, did you try with this syntax ? tmm --clientciphers DEFAULT:ECDHE:-AES256-SHA256:-AES256-SHA:-SSLv3:-RC4:@STRENGTH ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 10 DES-CBC3-SHA 192 TLS1 Native DES SHA RSA 1: 10 DES-CBC3-SHA 192 TLS1.1 Native DES SHA RSA 2: 10 DES-CBC3-SHA 192 TLS1.2 Native DES SHA RSA 3: 10 DES-CBC3-SHA 192 DTLS1 Native DES SHA RSA 4: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 5: 47 AES128-SHA 128 TLS1.1 Native AES SHA RSA 6: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA 7: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 8: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA
0
Comment made 17-Feb-2015 by Benoit C. 234
Hello, did you try with this syntax ? tmm --clientciphers DEFAULT:ECDHE:-AES256-SHA256:-AES256-SHA:-SSLv3:-RC4:@STRENGTH ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 10 DES-CBC3-SHA 192 TLS1 Native DES SHA RSA 1: 10 DES-CBC3-SHA 192 TLS1.1 Native DES SHA RSA 2: 10 DES-CBC3-SHA 192 TLS1.2 Native DES SHA RSA 3: 10 DES-CBC3-SHA 192 DTLS1 Native DES SHA RSA 4: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 5: 47 AES128-SHA 128 TLS1.1 Native AES SHA RSA 6: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA 7: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 8: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

without preforming an upgrade

0
Comments on this Answer
Comment made 09-Dec-2014 by Torti 803
i dont think so
0
Comment made 09-Dec-2014 by Brad Parker 4465
Without patching, you need to only allow RC4 ciphers to not be vulnerable to POODLE(TLS).
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

John Wagnon has written an article about improving your test grade:

https://devcentral.f5.com/articles/security-sidebar-improving-your-ssl-labs-test-grade

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

You can get an A+ without having to re-order the cipher preference.

This works fine (v11.5.2): ALL:!DH:!ADH:!EDH:!MD5:!EXPORT:!DES:!RC4

However, in order to get A+ you need HSTS configured (180+ days) and inserting headers on the "/" URI (which is what SSL Labs uses to test with). In an example virtual I have locked down so only certain IPs can get to it and all others get an HTTP 400 response - with that setup inserting the Strict-Transport-Security header in the HTTP_RESPONSE event does not work since the "HTTP::respond 400" command in the HTTP_REQUEST does not fire the HTTP_RESPONSE event. What needs to happen is to have any iRule which responds directly to client for the "/" URI via HTTP::respond, HTTP::redirect, etc include the Strict-Transport-Security header as part of that response. This is rather arbitrary, your site can support HSTS in general, without supporting it on "/" - where you just 301/302 - but SSL Labs won't give you the A+ unless they see that header in the HTTP response for that hit.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

For version 11.4.1 we are using the following cipher string:

!COMPAT:ECDHE-RSA-AES256-CBC-SHA:ECDHE-RSA-AES128-CBC-SHA:ECDHE+3DES:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:3DES:!MD5:!EXPORT:!DES:!EDH:!SSLv3:!RC4:!TLSv1

This results in the following available ciphers and order:

       ID  SUITE                            BITS PROT    METHOD  CIPHER  MAC     KEYX
 0: 49172  ECDHE-RSA-AES256-CBC-SHA         256  TLS1.1  Native  AES     SHA     ECDHE_RSA 
 1: 49172  ECDHE-RSA-AES256-CBC-SHA         256  TLS1.2  Native  AES     SHA     ECDHE_RSA 
 2: 49171  ECDHE-RSA-AES128-CBC-SHA         128  TLS1.1  Native  AES     SHA     ECDHE_RSA 
 3: 49171  ECDHE-RSA-AES128-CBC-SHA         128  TLS1.2  Native  AES     SHA     ECDHE_RSA 
 4: 49170  ECDHE-RSA-DES-CBC3-SHA           192  TLS1.1  Native  DES     SHA     ECDHE_RSA 
 5: 49170  ECDHE-RSA-DES-CBC3-SHA           192  TLS1.2  Native  DES     SHA     ECDHE_RSA 
 6:    61  AES256-SHA256                    256  TLS1.2  Native  AES     SHA256  RSA       
 7:    60  AES128-SHA256                    128  TLS1.2  Native  AES     SHA256  RSA       
 8:    53  AES256-SHA                       256  TLS1.1  Native  AES     SHA     RSA       
 9:    53  AES256-SHA                       256  TLS1.2  Native  AES     SHA     RSA       
10:    53  AES256-SHA                       256  DTLS1   Native  AES     SHA     RSA       
11:    47  AES128-SHA                       128  TLS1.1  Native  AES     SHA     RSA       
12:    47  AES128-SHA                       128  TLS1.2  Native  AES     SHA     RSA       
13:    47  AES128-SHA                       128  DTLS1   Native  AES     SHA     RSA       
14:    10  DES-CBC3-SHA                     192  TLS1.1  Native  DES     SHA     RSA       
15:    10  DES-CBC3-SHA                     192  TLS1.2  Native  DES     SHA     RSA       
16:    10  DES-CBC3-SHA                     192  DTLS1   Native  DES     SHA     RSA       

We disabled TLS1.0 by default as long as we don't have a dedicated requirement for any old browsers/clients which needs to be supported. And we also disabled Renegotiation in the SSL profile.

Any concerns about that?

If you are interested I raised a dedicated discussion for version 11.5 here.

Ciao Stefan :)

0