Forum Discussion

Per_Hagstrom's avatar
Per_Hagstrom
Icon for Nimbostratus rankNimbostratus
Apr 29, 2019

Recommended Exchange 2016 ciphers settings?

After setting up our Exchange 2016 environment behind the F5 using the iApp, the SSL scan through Qualys SSL Labs gave us a big red F. Started a case with F5, to get the recommended cipher settings for Exchange 2016, but Support is telling me they don't know, and can only recommend different general settings to try to get rid of insecure ciphers. So first thing I'm recommended to try is: DEFAULT:!RSA

 

I'm really surprised over this poor support, and hoping someone else out there has an Exchange 2016 server tightened down, without tighten it too much, to still be able to use Outlook Anywhere/OWA/ActiveSync etc. If you would be willing to share your ciphers settings, it would be much appreciated!

 

application delivery
BIG-IP
ciphers
exchange 2016
LTM
security
ssl ciphers

1 Reply

Sort By
  • Daniel_Wolf's avatar
    Daniel_Wolf
    Icon for MVP rankMVP
    May 02, 2019

    Hi Per,

    I think it is pretty reasonable from F5 not to provide "recommended" settings for a product which they are not the product owner. How should F5 keep a list of recommended settings for each and every software on the market. Even for the most popular ones (thinking Exchange/SharePoint in versions 2010, 2013, 2016, 2019, SAP ERP, etc.) it would be challenging.

    Microsoft provides some insights on the supported / recommended cipher settings, though they are also not giving a definite list. First off all Microsoft (from October 31st, 2018) stopped support for TLS 1.0 and TLS 1.1 for Office 365. It does not mean that you must disable TLS 1.0 and / or 1.1, but it means you won't get support when you are using one of these. See here: Preparing to use TLS 1.2 in Office 365

    And they are providing you with a list of checks that should be performed in advance. See Part 1 to 3 of this series: Exchange Server TLS guidance, part 1: Getting Ready for TLS 1.2

    Regarding your issue. Why don't you try with an iRule to figure out what kind of client traffic you receive. From that analysis you can probably rule out some SSL versions and cipher suites that you don't want to have. Then you could try to figure out if and which of your clients are using legacy SSL versions and cipher suites and decide how to cope with these.

    A logging iRule could like something like this:

    when CLIENTSSL_HANDSHAKE {
    switch [SSL::cipher version] {
        "TLSv1" {
            log local0. "TLS1.0 Session - Client: [IP::client_addr] successfully negotiated [SSL::cipher version] - [SSL::cipher name] - [SSL::cipher bits] - For the VIP - [virtual name]"
        }
        "TLSv1.1" {
            log local0. "TLS1.1 Session - Client: [IP::client_addr] successfully negotiated [SSL::cipher version] - [SSL::cipher name] - [SSL::cipher bits] - For the VIP - [virtual name]"
        }
        "TLSv1.2" {
            log local0. "TLS1.2 Session - Client: [IP::client_addr] successfully negotiated [SSL::cipher version] - [SSL::cipher name] - [SSL::cipher bits] - For the VIP - [virtual name]"
        }        
        default {
            log local0. "Legacy SSL Session - Client: [IP::client_addr] successfully negotiated [SSL::cipher version] - [SSL::cipher name] - [SSL::cipher bits] - For the VIP - [virtual name]"
        }
    }

    You can test your iRule with cURL:

    curl -v  --tlsv1  owa.mydomain.com      
curl -v --tlsv1.0   owa.mydomain.com   
curl -v  --tlsv1.1   owa.mydomain.com  
curl -v  --tlsv1.2  owa.mydomain.com 
curl -v  --sslv3   owa.mydomain.com