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

Filter by:
  • Solution
  • Technology
Answers

How do i restrict TLS negotiation to minimum TLS v1.2

There is a situation where it is allowed to negotiate a TLS v1 session.

How can I restrict TLS negotiation to minimum TLS v1.2. How to encounter any client issues if we do that ?

Thanks,

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

change the ciphers allowed in the ssl profile....

test afterwards using all potential client browsers...

depends of course on the version being used;

http://support.f5.com/kb/en-us/solutions/public/13000/100/sol13163.html

/j

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Try this on for size sfrjames

This will test if it is not TLS1.2, it will then serve a page from an iFile and set a cookie on the client, after a configurable amount of time (static::TLS1_2_Test_refresh) the page will refresh and deliver you to the originally requested content.

If you want to serve just simple text then replace the iFile content portion with whatever text you want, but this gives you the ability to load an entire page with formatting etc (if you're smart you can embed images directly into it as base64 encoded pngs)

The warning will only show up every 30 days by default (change static::TLS1_2_Test_Cookie_Validity to value in days) based on the cookie. If you don't put a mechanism like this into place, then every single request will get the warning page (though you can configure this by setting static::TLS1_2_Test_Block_Mode_On to 1).

(*N.B. This wasn't originally for TLS1.2 detection, it checked to see if they were using SSLv3 and sent them to a page telling them to upgrade their browser, but its the same principal, but I haven't checked it out to see if it 100% works for TLS1.2, but simply re-jigged it to check for not TLS1_2 instead of for SSLv3)

#   Name:       TLS1_2_Test
#   Author:     Matt Elkington
#   Contact:    melkington@integrity360.com
#   Date:       
#   Description:Test for TLS1_2 connections and then serve a page
#               Page will auto-refresh and then serve originally requested content
#               Can switch into block mode where it will always serve warning page
#               
#               
#
#   Change Log
#   Version     Change                              Date
#   1.0         Initial iRule                       07/12/15    
#   1.1         Multiple Changes                    16/02/16

when RULE_INIT {
    #set static variables
    #
    #set debug mode (0=off, 1=minimal, 2=verbose, 3=overwhelming)   
    #(change "iRule_Name" to name of actual iRule)
    set static::TLS1_2_Test_Debug 3
    #cookie name
    set static::TLS1_2_Test_Cookie_Name TLS1_2_Test_Cookie
    #cookie expiration period in days
    set static::TLS1_2_Test_Cookie_Validity 30
    #Default HTTP content for when no other page is specified
    set static::TLS1_2_Test_Ifile_default outdated_en
    #Page Refresh time in seconds
    set static::TLS1_2_Test_refresh 30
    #Set this variable to 1 to simply serve the page every single time
    set static::TLS1_2_Test_Block_Mode_On 0
    #
    #Cookie Value (not user configurable)
    set static::TLS1_2_Test_cookie_format [format "%s=%s; Max-Age=%s; path=/" $static::TLS1_2_Test_Cookie_Name $static::TLS1_2_Test_Cookie_Name [expr $static::TLS1_2_Test_Cookie_Validity * 86400] ]
    }                           

when HTTP_REQUEST {
    #Check for TLS1_2
    if { ([SSL::cipher version] ne "TLS1_2") } {
        set LogString "Client [IP::client_addr]:[TCP::client_port] -> [HTTP::host][HTTP::uri] -"
        #Check to see if Block Mode is not enabled
        if { $static::TLS1_2_Test_Block_Mode_On eq 0 } {
            #Check for existence of cookie and do not serve page if it exists
            if { [HTTP::cookie exists $static::TLS1_2_Test_Cookie_Name] } {
                if { $static::TLS1_2_Test_Debug > 2 } {
                log local0. "$LogString not using TLS1_2 but cookie is already set"
                }
                return
            }
        }
        #Serve outdated warning page
        HTTP::respond 200 content [ifile get $static::TLS1_2_Test_Ifile_default] "Set-Cookie" $static::TLS1_2_Test_cookie_format "Refresh" $static::TLS1_2_Test_refresh
        if { $static::TLS1_2_Test_Debug > 0 } {
            log local0. "$LogString using TLS1_2"
            if { $static::TLS1_2_Test_Debug > 1 } {
                log local0. "$LogString is [HTTP::header User-Agent]"
            }
        }
    }
}
1
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I'd first direction your attention to Jason Rahm's excellent article on cipher suites:

SSL Profiles Part 4: Cipher Suites

You could, for example, just enter 'TLSv1_2' in the Ciphers field of the client SSL profile to limit all client side communications to protocols that use TLSv1.2. On an 11.3 box it'd be something like this:

[root@bigip1:Active:Standalone] dev # tmm --clientciphers 'TLSv1_2'
     ID SUITE                          BITS  PROT  METHOD CIPHER MAC    KEYX
 0:   4 RC4-MD5                         128  TLS1.2  Native RC4    MD5    RSA
 1:   5 RC4-SHA                         128  TLS1.2  Native RC4    SHA    RSA
 2:  47 AES128-SHA                      128  TLS1.2  Native AES    SHA    RSA
 3:  53 AES256-SHA                      256  TLS1.2  Native AES    SHA    RSA
 4:  10 DES-CBC3-SHA                    192  TLS1.2  Native DES    SHA    RSA
 5:   9 DES-CBC-SHA                      64  TLS1.2  Native DES    SHA    RSA
 6:  51 DHE-RSA-AES128-SHA              128  TLS1.2  Native AES    SHA    EDH/RSA
 7:  57 DHE-RSA-AES256-SHA              256  TLS1.2  Native AES    SHA    EDH/RSA
 8:  21 DHE-RSA-DES-CBC-SHA              64  TLS1.2  Native DES    SHA    EDH/RSA
 9:  22 DHE-RSA-DES-CBC3-SHA            192  TLS1.2  Native DES    SHA    EDH/RSA
10: 100 EXP1024-RC4-SHA                  56  TLS1.2  Native RC4    SHA    RSA
11:  98 EXP1024-DES-CBC-SHA              56  TLS1.2  Native DES    SHA    RSA
12:   3 EXP-RC4-MD5                      40  TLS1.2  Native RC4    MD5    RSA
13:   8 EXP-DES-CBC-SHA                  40  TLS1.2  Native DES    SHA    RSA
14:  60 AES128-SHA256                   128  TLS1.2  Native AES    SHA256 RSA
15:  61 AES256-SHA256                   256  TLS1.2  Native AES    SHA256 RSA

But then you'd also (at present day) be significantly limiting WHO could access your application, as many clients still don't support TLSv1.2 in their browsers/OS. You could also implement this in an iRule:

when HTTP_REQUEST {
    if { [SSL::cipher version] ne "TLSv1.2" } {
        HTTP::respond 200 content "Your browser must support TLSv1.2"
    }
}

In this case the user would get a somewhat-friendly error message telling them why they couldn't access the site. In either case, I'd highly recommend, unless under the most controlled environments, that you NOT limit access based on TLSv1.2, but rather re-examine what you're trying to protect and if specific coding practices or even a web app firewall are better options.

0
Comments on this Answer
Comment made 28-Aug-2013 by Beinhard 10
I think above is a really good example, however, pretty much all new versions of a UA is supporting tls 1.2, however a lot of them has it disabled by default.
0
Comment made 20-Apr-2016 by sfrjames 0
Adding to this approach, I too have been asked to create our new Default Cipher suite. I have an iRule in play which redirects and also prompts with information-instruction on how to enable TLS1.2 within thier browser. What I now face is, the folks that are given a 200 response with text-html, is there a way after we give the 200 to allow them to fall through to the site after the message, instead of the hard stop? (This would be after a 20 second pause for example)
0
Comment made 04-Jun-2016 by Mauz 158
I was able to disable tls1.0 on 11.1.0 with this cipher profile DEFAULT:!TLSv1_1:!TLSv1:!SSLv3
0
Comment made 05-Jun-2016 by Yann Desmarest 4479
Hi you can test support for your configuration by browser by launching an ssl labs test. The result will show you the different user-agent and how they will negociate with your system
0