SSL Proxy

Can you possibly capture the SSL handshake on the BIG-IP using ssldump? Please refer to the following article:

K10209: Overview of packet tracing with the ssldump utility

What version of LibreSSL are you using on the back-end servers? The reason I'm asking is that some people have resolved this by simply upgrading LibreSSL.

benoittgt commented on 22 Jan

I update with brew, libressl, openssl and curl and reboot my machine. It's now working.

https://github.com/libressl-portable/portable/issues/369

As Philip states, it really would be helpful to see the ssldump transaction. That it seems to fail directly after the ClientHello usually suggests that the client and server's cipher lists are incompatible. If the server is the one severing the connection, then it could also be that the client is sending, or maybe not sending, an extension (like Server Name).

Waiting for ssh access... Meanwhile, maybe somebody sees any issues with this config?

vip_config:

client_ssl_profile:

server_ssl_profile:

Thanks

Sorry guys, I got stuck with ssldump utility:

ssldump -r /path/to/capture_file -k /path/to/private_key -M /path/to/pre-master-key_log_file

Where to I get private key? I'm in tmos utility.

Also, how would I capture traffic for a specific VIP after it's offloaded?

This doesn't work: tcpdump -vvv -s 0 -nni external host 192.168.56.200 and port 8140

Thanks

Okay, two things.

• Why do you have SSL Forward Proxy enabled? You definitely shouldn’t need this. SSLFWD is used when the F5 is a forward proxy (for outbound traffic) and you need to re-issue (forge) remote server certs. I think you’re just dealing with a reverse proxy here, so you just need the server cert and key in the client SSL profile, and probably just the generic serverssl profile.

• You don’t need to specify a key in the ssldump. That’d be if you were trying to decrypt the traffic, and would also only work with non-PFS (RSA key exchange) ciphers. You just need a very simple ssldump command like this:

  ssldump -AdNn -i [vlan name] port 443 [and any additional display filters]
  

So just to be clear from Philip's last post, you also MUST set the Trusted Certificate Authorities option. This is what the BIG-IP uses to validate the client certificate, and will fail without it. Minimally this is a single self-signed root CA, but in reality should be a text file containing the entire PKI CA chain in PEM format.

----- BEGIN CERTIFICATE -----
...stuff...
----- END CERTIFICATE -----
----- BEGIN CERTIFICATE -----
...stuff...
----- END CERTIFICATE -----    

So is it that [X509::subject [SSL::cert 0]] doesn't work because client cert auth is failing? If you insert a log statement, does the log return the correct value?

log local0. "cert = [X509::subject [SSL::cert 0]]"

It looks like you're getting all the way through a first TLS handshake, then failing on a second, and you're definitely passing a certificate, so an improvement. An ssldump will still be helpful.

And last, what are you trying to do once you've set the variable? And how does puppet expect to receive the client cert? Can it consume an HTTP header? Or does puppet strictly require the client cert in a TLS handshake?

One more question, Let's say a client doesn't have a cert signed with CA, in this model F5 would throw an error (unauth).

In fact CA is behind F5, is there a way to allow cert requests to flow through F5 without auth through the same VIP and port?

Thanks