Translating Cipher Suites from Wireshark to BIG-IP

Many of us use Wireshark to capture and analyze network traffic. When it comes to SSL/TLS traffic, Wireshark does a great job of showing the cipher suites presented by the client and then the cipher suite chosen by the server in a given SSL/TLS session. There’s no “standard” naming convention for the cipher suites, so different systems will present the cipher suites in a slightly different way. For example, the BIG-IP lists a cipher suite in this manner:

 
DHE-RSA-AES256-GCM-SHA384 256 TLS1.2 Native AES-GCM SHA384 EDH/RSA

Specific browsers have their own style of showing the cipher suite used for a given webpage. And those styles are not consistent across all browsers. Here’s an example of what Google will show you:

And here’s an example of what Firefox will show you:

As you can see, it’s sometimes difficult to track the exact cipher suite used for a given webpage in a given session. This is where Wireshark can come in really handy. Wireshark can be used to capture the actual SSL/TLS transactions between client and server, and it lists the cipher suites offered by the client as well as the cipher suite chosen by the server. For each cipher suite, it has an associated hexadecimal value listed next to each one. When tracking cipher suites, it’s best to use the hexadecimal value associated with each suite.

I have a BIG-IP v12.0, and I captured a Client Hello and Server Hello using Wireshark when I accessed a test web application. I have the DEFAULT cipher suite enabled for my client SSL profile on the BIG-IP. Here's the Wireshark capture for the Client Hello:

You can’t see them all in the screenshot above, but the browser sent 15 different cipher suites to the server for consideration. Notice the hexadecimal value listed to the right of each cipher suite. Keep an eye on cipher suite hex value 0x0039. This will be the one that is ultimately selected by the BIG-IP for this specific session. Here's the Server Hello Wireshark capture (happened shortly after the Client Hello):

You can see what the BIG-IP (Server) chose as the cipher suite for this session. This cipher suite also has a hexadecimal value listed…0x0039. As I said before, the Wireshark capture does a good job of letting you know what's in the cipher suite (TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)), but that doesn't always correspond exactly to the naming convention of the BIG-IP list of cipher suites. Here's a list of the DEFAULT cipher suites on the BIG-IP (v12.0) using the following command:

 
tmm --clientciphers DEFAULT

Unfortunately, the BIG-IP doesn't list the hexadecimal value of the cipher suites by default (using the command listed above). However, you can use the following command to list the cipher suites with hex values (make sure the "V" in the command is uppercase):

 
openssl ciphers –V DEFAULT

Here’s a screenshot of the same list of ciphers using the openssl command:

You can see that the hexadecimal values are listed, but some people might still find it hard to follow this specific output. If you are good with what the openssl command shows you, then great! You can certainly use this to cross-reference the Wireshark hexadecimal cipher suite value to see which one was chosen. If you want a slightly easier-to-read version of these ciphers with hexadecimal values listed, you can use this link: https://support.f5.com/csp/article/K13156 to find a good listing of BIG-IP cipher suites with hexadecimal values listed.

Here's a screenshot of the BIG-IP (v12.0.0 - 12.1.2) cipher suites from that page. I circled the 0x0039 so you could track the same cipher suite that was used throughout this session.

Updated Jun 06, 2023
Version 2.0
  • Hi John,

     

    Nice extension to already great explanation from other article! I tried your trick with openssl ciphers –V DEFAULT but on 12.1.1.1.0.196 I am getting output like that:

     

    ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:....

     

    What I am missing?

     

    Piotr

     

  • @Piotr, thanks for the info. I'm not sure why it's showing like that. Could you do a screen shot and post that here as well? Maybe it will show a little more info and we can figure out what is happening. Thanks!

     

  • Hi,

     

    Here is from vGuest running 12.1.1HF1

     

     

    vHost on i5800 running 13.0.0HF2

     

     

    Piotr

     

  • Hi Piotr. I ran this same command on a few of my lab boxes, and the results are showing up as expected. One option you could try is to send the output of the command to a file. Here's what I did on my box:

     

    openssl ciphers -V DEFAULT > /tmp/ciphers.txt

     

    Then, I used "nano" to open and look at the ciphers.txt file. You could use any editor you like, though.It had all the ciphers listed with the hexadecimal values. Hopefully this helps!

     

  • Hi,

     

    I tried to direct output to file but effect is the same :-(. I am running out of ideas why. My output is completely different than your listing.

     

    Could it be version of openssl? I tried on vGuest with:

     

    OpenSSL 1.0.1l-fips 15 Jan 2015

     

    Seems not as on VE I have the same one and output is as yours. So vCMP enabled host and guest has issue?

     

    Piotr

     

  • What if we updated the wireshark source to preload the friendly (and useable) cipher name after the long name and hex in that image capture? So instead of this:

    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

    We could have this:

    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) (DHE-RSA-AES256-SHA)