Decrypting F5 Server side SSL Traffic

Question

Im a beginner in decrypting SSL traffic but im able to decrypt normal client to server SSL traffic. The problem im encountering is when I try to decrypt SSL traffic bridged from an F5 to the Server. I was expecting the F5 to just re-established the connection in the same method as a client to the F5.

All I see are:

TLSv1 Client Hello
TLSv1 Server Hello
TLSv1 Change Cipher Spec
TLSv1 Encrypted Handshake Message

What I normally see is:

TLSv1    Client Hello
TLSv1    Server Hello
TLSv1    Client Key Exchange, Change Cipher Spec
TLSv1    Change Cipher Spec, Finished
TLSv1    Certificate, Server Hello Done

The purpose of this is I want to diagnose encrypted health checks to see why they failing. Any Ideas? Thanks for your Help.

Answer 1

1

The difference in the SSL Handshake is caused by the fact that the F5 reuses the initial full SSL handshake to the server and therefor only uses a short handshake to the server to not overload it. That's why you don't see the ClientKeyExchange message. And because you don't have the ClientKeyExchange, you can't do decryption.

You can change the ServerSSL profile to not cache SSL sessions for troubleshooting purposes. But beware that this will increase the CPU load on the server as each SSL session from the F5 to the server will now need to do a full SSL handshake which is very CPU intensive.

answered 11 Jul '12, 04:17

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

Thanks I saw your answer just as I posted the other one, caching turned off and captures being taken as I type..

(11 Jul '12, 06:29) Fishlogic

You're welcome, I hope it will solve your issue!

I converted your answer to a comment. Please review the FAQ of this site and use "Add new Comment" instead of posting a new answer when you respond to an answer or comment. That's how this site works best...

(11 Jul '12, 06:46) SYN-bit ♦♦

Caching turned off but im still recieving the same traffic in the capture, Cache Size set to 0. Does the VIP need to be diabled / enabled after the cache is disabled?

(11 Jul '12, 08:31) Fishlogic

Does the ClientHello from the F5 to the backend server have a SessionID (so SessionIdLength > 0)? If so, the F5 is indeed reusing an older session. I would expect that change to be active inmediately. However I'm not sure. I would need to check on my LTM-VE.

(11 Jul '12, 14:03) SYN-bit ♦♦

I just read your question again, are you troubleshooting production traffic or the health checks? If you are trying to decrypt the health checks (monitors), then you can only make the F5 stop reusing the old SSL session by turning of caching on the server side.

(11 Jul '12, 14:43) SYN-bit ♦♦

Or you can capture long enough to get a full handshake. On my server I needed to wait 300 seconds for a new full handshake (from my apache config: SSLSessionCacheTimeout 300)

(11 Jul '12, 15:21) SYN-bit ♦♦

showing 5 of 6 show 1 more comments

Answer 2

0

I was expecting the F5 to just re-established the connection in the same method as a client to the F5.

That's not the case. It depends on the settings in th "client ssl profile" (frontend) and the "sever ssl profile" (backend).

The problem im encountering is when I try to decrypt SSL traffic bridged from an F5 to the Server

If you want to decrypt the SSL/TLS session between the loadbalancer and the nodes, you need to have the private key, installed on the nodes, unless it's the same as the one installed on the load balancer. Furthermore, you must ensure, that the loadbalancer is NOT using any SSL/TLS ciphers with DH (Diffie Hellman) authentication, as you cannot decrypt that. You need to change the CIPHERS in the "server ssl profile" (the one you configured for the virtual server). See the F5 SOL13171.

Regards
Kurt

answered 11 Jul '12, 03:42

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

The same cert/key is used on the nodes and the 'server ssl profile'.

Does the following mean it's using them all ?

Parameter Definition 
!SSLv2    Do not use SSL version 2 
ALL       Use all SSL ciphers in the default SSL stack 
!DH       Do not use DH ciphers 
!ADH      Do not use ADH ciphers 
!EDH      Do not use EDH ciphers 
!MD5      Do not use MD5 ciphers 
!EXPORT   Do not use EXPORT grade (weak) ciphers 
!DES      Do not use DES ciphers 
@SPEED    Order the cipher preference by speed

The node to F5 'TLSv1 Record Layer: Handshake Protocol: Server Hello' is using the following

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA

I also Found this on Dev Central which kind of explains what im seeing still doesnt tell me if i can decrypt it though

"The server can decrypt stuff from the F5 (Client) because the shared session key (That's actually used to encrypt the traffic) is negotiated as part of the key exchange where the server uses it's own private key. The client side key doesn't get involved). The session between the LTM and the server is a completely different TLS (Or SSL) session from the client - LTM connection."

(11 Jul '12, 05:07) Fishlogic

(I converted your answer to a comment, please see the FAQ for more details)

The ciphersuite is not the issue here, please see my answer below...

(11 Jul '12, 05:23) SYN-bit ♦♦

Does the following mean it's using them all ?

the ! means logical NOT. So it's NOT using any of them.

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA

As SYN-Bit said, in this case the cipher is not your problem.

because the shared session key (That's actually used to encrypt the traffic) is negotiated as part of the key exchange where the server uses it's own private key

that's the reason why you can't decrpyt it. See answer of SNY-Bit.

Anyway, IF the server uses a different private key than the one you imported into the loadbalancer, please use the key of the server to decrypt the communication between the lodabalancer and the node.

(11 Jul '12, 06:15) Kurt Knochner ♦

Sorry have quite got the hang of the Forum ... What about

ALL Use all SSL ciphers in the default SSL stack

(11 Jul '12, 08:53) Fishlogic