4

With 7k plus servers in an F5 load balanced environment, what are some suggested approaches to identify SSL use and use of TLS below 1.2?

  • "Suggested approaches" will depend on your resources... – schroeder Mar 30 '17 at 11:55
  • All of your input is very much appreciated. Need to huddle with the load balancer team. I will likely be coming back for additional help. Thanks for your detailed responses. – Securityquest Mar 30 '17 at 20:38
2

There are a LOT of ways to get this information.

It's important to actively probe the services running on your network and not just look at passive information as the ciphers negotiated and in active use don't represent all ciphers configured to be used on by the service which is what's really important to avoid downgrade attacks.

The tool nmap has a script called ssl-enum-ciphers which may help

nmap --script ssl-enum-ciphers -p 443 www.sitename.com

-p is to specify port 443 for https but this can be used on any port. You can also test huge lists of IP's in a single command but the following is a test against one port on one IP for reader simplicity.

The output from this command and option setting looks like the following:

trey@pentest01:~$ nmap --script ssl-enum-ciphers -p 443 www.verificationlabs.com

Starting Nmap 7.31 ( https://nmap.org ) at 2017-03-30 00:57 UTC
Nmap scan report for www.verificationlabs.com (198.61.176.181)
Host is up (0.0014s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 4.76 seconds

Note: SSL data will show up as well it just wasn't configured on this server. You can also automate this script to run at regular intervals and report on non-compliant findings.

  • Great example re: nmap is super useful for these kinds of enumerations. In situations where you can't use nmap you can also use openssl s_client to get a similar result. Here's an example around a similar vein: superuser.com/a/224263 – Ori Apr 29 '17 at 16:28
0

If you already have a vulnerability scanner in this environment, you can probably get a list very similar to what Trey suggests. In Qualys, you can scan for QID 38116 and it produces a list of supported SSL/TLS versions, as well as Cipher Suites for every port scanned.

I would presume something similar is available with other vulnerability scanners (ie. Nessus).

0

I assume that you are interested in quantifying the TLS protocols and ciphers being used by your clients, the better to understand and communicate the impact of changes required to retire "early TLS" as per PCI.

In that case, you are so in luck. You can easily log the negotiated parameters of each connection using an iRule like this on each F5 LTM virtual:

when CLIENTSSL_HANDSHAKE {
    log local0. "protocol=[SSL::cipher version] cipher_suite=[SSL::cipher name]\
      virtual=[virtual name] client_addr=[IP::client_addr]"
}

Which will result in log entries like this:

protocol=TLSv1.2 cipher_suite=ECDHE-RSA-AES256-CBC-SHA virtual=/Common/mywebsrv client_addr=172.16.31.13

Those log entries go to /var/log/ltm on the F5 and can be forwarded to your SIEM for aggregation and analysis via syslog.

Once you've been logging for a while, you can parse the logs and determine:

  • Which TLS protocols and ciphers are in use
  • Which clients are using older protocols that you need to retire
  • Whether the protocol mix varies by virtual (if you're hosting multiple sites...)

Now, some caveats. This will show you what got negotiated. It won't tell you when negotiation failed because you and the client couldn't agree on a protocol+suite, and it won't tell you what protocol+suite list your clients are willing to speak. Knowing the latter is very important when you're thinking about updating your server configuration and want to know who you'll be locking out.

The former can also be found in the F5 logs; look for the strings "error" and "ssl_hs_*" on the same line. Here's an example:

01260009:7: Connection error: ssl_hs_rxv2hello:6934: unsupported version (40)

To get details of what the clients are willing to speak, you need to go beyond the F5, and capture the actual CLIENT_HELLO packets off the wire as they come in. And then you need to parse it. This sounds painful, but that's because it is. You can write a BPF filter to extract CLIENT_HELLO packets, and you can parse those packets in a number of ways; I think the last time I had to do it I used scapy.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.