SSL offloading

is it possible to compare ssldump when using ie and ff/chrome?

 

 

sol10209: Overview of packet tracing with the ssldump utility

 

http://support.f5.com/kb/en-us/solutions/public/10000/200/sol10209.html

Here's what you're SSLDUMP string might look like:

 

 

ssldump -k -i 0.0 -AdNn port 443

 

 

-k - you need the physical location of the private (*.key) file that is specified in the client SSL profile

 

-i 0.0 - this means use all interfaces, but you can narrow it down to a single VLAN/interface

 

-AdNn - this esentially means decrypt the traffic if possible and clean up the capture

 

port 443 - this is your filter. SSLDUMP absolutely requires a filter string. YOu can narrow this down to an IP address or anything else as long as the filter is there.

 

 

What you're looking for are the initial client and server SSL handshakes, and more specifically, where it fails. You'll either see one of the parties mysteriously reset, or potentially a "fatal handshake" error. Please post what you find.

 

 

Also:

 

1. Do your client certificates contain a CRLDP or AIA field, and if so are those accessible?

 

2. In Chrome, under Advanced Settings and HTTP/SSL, do you have "Check for server certificate revocation" checked?

 

3. In Firefox, in Options, Advanced, Encryption, then the Validation button, what do you have checked there?

 

Thank you. Here it is (I omitted html content for successful attempts):

 

 

Internet Explorer: http://pastebin.com/PgEMErsD (works OK)

 

Firefox: http://pastebin.com/uLeTF4y3 (I left it connecting during the tcpdump session and eventually, after some time, the webpage was loaded but corrupted (for example, without images, CSS and forms))

 

Chrome: http://pastebin.com/V2ih7bUy (never worked, timed out pretty quick)

 

 

1. Do your client certificates contain a CRLDP or AIA field, and if so are those accessible?

 

How can check this? I'm using self-signed certificate which was included with F5 LTM VE.

 

 

2. In Chrome, under Advanced Settings and HTTP/SSL, do you have "Check for server certificate revocation" checked?

 

It's unchecked.

 

 

3. In Firefox, in Options, Advanced, Encryption, then the Validation button, what do you have checked there?

 

Both options are unchecked.

 

 

Many thanks for your time.

"How can check this? I'm using self-signed certificate which was included with F5 LTM VE."

 

- Nevermind. You're not using client certs and you're using the default server certs on the BIG-IP. Didn't catch that at first.

 

 

Okay, so it doesn't appear to be a validation/revocation issue. Do you not get certificate warnings with all of the browsers? Do you have any special cipher settings (or anything special) in your client SSL profile, or in your browsers?

 

 

Also, not sure this is related, as it talks about client cert, but take a look at this:

 

 

sol12313: The BIG-IP system responds with a full SSL handshake regardless of whether the client sends a session ID during SSL session renegotiation

 

http://support.f5.com/kb/en-us/solutions/public/12000/300/sol12313.html?sr=27615885

 

 

And ID 226971 from the 10.2.1 release notes

 

http://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote_10_2_1_ltm.html?sr=27616725

 

i do see ie session using TLS_RSA_WITH_AES_128_CBC_SHA cipher but ff/chrome using TLS_RSA_WITH_AES_256_CBC_SHA. additionally, it seems tls v1.1 is enabled in chrome (as we see it tried tls v1.1 (Version 3.2) first in client hello message.

anyway, i am not sure if this is relevant but if you want to try, we may force TLS_RSA_WITH_AES_128_CBC_SHA cipher and disable tls v1.1 in chrome and see whether it makes any change.

e.g.

[root@ve10:Active] config  b profile myclientssl list
profile clientssl myclientssl {
   defaults from clientssl
   ciphers "AES128-SHA"
}

Kevin, nitass, thank you very much guys!

 

 

I replicated my setup in production (we have a pair of BIG-IPs running 10.2.2 (build 763.3)) and all browsers are OK now, so I guess the software version of F5 LTM VE was/is to blame.