Forum Discussion

bkhowson's avatar
bkhowson
Icon for Nimbostratus rankNimbostratus
Apr 26, 2014

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?

application delivery
design
devops
iRules
LTM
performance
security

24 Replies

Sort By
Show More
    • Brad_Parker's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      Dec 09, 2014
      Without patching, you need to only allow RC4 ciphers to not be vulnerable to POODLE(TLS).
  • Mike_Gorski_625's avatar
    Mike_Gorski_625
    Icon for Nimbostratus rankNimbostratus
    May 20, 2015

    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.

     

  • Stefan_Klotz's avatar
    Stefan_Klotz
    Icon for Cumulonimbus rankCumulonimbus
    Jun 16, 2015

    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 🙂

  • Colin_Stubbs's avatar
    Colin_Stubbs
    Icon for Nimbostratus rankNimbostratus
    Dec 01, 2015
    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.