TLS protocol switching on F5
Hello Experts, I am looking for documents to understand the behavior of TLS version selection made by F5 in SSL handshake either sides. I would appreciate if someone can clarify on this : The scenario is if client connect to F5 using TLSv1.0, will F5 by default try to connect to server using TLSv1.0 as normal behavior ? What if server has TLSv1.0 disabled, only TLSv1.2 enabled. Will F5 retry connection to server by using TLSv1.2? Provided clientssl and serverssl are supporting all versions of TLS. Moreover, lets say if below are the settings in CLientssl and serverssl profile : !DEFAULT:!SSLv3:TLSv1:TLSv1_1:TLSv1_2 when i check the list of ciphers supported, i get below list : `@f5test:LICENSE EXPIRED] config tmm --serverciphers '!DEFAULT:!SSLv3:TLSv1:TLSv1_1:TLSv1_2' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 5 RC4-SHA 128 TLS1 Native RC4 SHA RSA 1: 5 RC4-SHA 128 TLS1.2 Native RC4 SHA RSA 2: 47 AES128-SHA 128 TLS1 Native AES SHA RSA 3: 47 AES128-SHA 128 TLS1.2 Native AES SHA RSA 4: 47 AES128-SHA 128 DTLS1 Native AES SHA RSA 5: 53 AES256-SHA 256 TLS1 Native AES SHA RSA 6: 53 AES256-SHA 256 TLS1.2 Native AES SHA RSA 7: 53 AES256-SHA 256 DTLS1 Native AES SHA RSA 8: 10 DES-CBC3-SHA 192 TLS1 Native DES SHA RSA 9: 10 DES-CBC3-SHA 192 TLS1.2 Native DES SHA RSA 10: 10 DES-CBC3-SHA 192 DTLS1 Native DES SHA RSA 11: 60 AES128-SHA256 128 TLS1.2 Native AES SHA256 RSA 12: 61 AES256-SHA256 256 TLS1.2 Native AES SHA256 RSA 13: 9 DES-CBC-SHA 64 TLS1 Native DES SHA RSA 14: 9 DES-CBC-SHA 64 TLS1.2 Native DES SHA RSA ` So along these, what will be selection sequence followed by F5 ?
Irule Check SSL Version and Redirect
Just to share my irule to check SSL Cypher or Bits on SSL Handshake, and redirect to another url. This working on Firefox,Chrome and IE. when CLIENTSSL_HANDSHAKE { if { ( [SSL::cipher version] <= "TLSv1" ) } { log local0. "Denegacion SSL Handshake para el Cliente [IP::client_addr]:[TCP::client_port] usando [SSL::cipher version], [SSL::cipher name] y [SSL::cipher bits]" set invalid_ssl 1 } else { set invalid_ssl 0 } } when HTTP_REQUEST { if { $invalid_ssl } then { HTTP::redirect "http://www.example.com/example" TCP::close event disable all return } } Regards.
TLS handshake in passthrough scenario
Hi All, This might be a basic question but i would like to know how the SSL/TLS handshake takes place in a SSL passthrough scenario. If we are not doing the offloading, there is no certificate on the F5 installed than how will the handshake happen? Will the tls hello packets be forwarded directly to the backend server? I couldn't find any documentation on this scenario. Any help would be great. I assume this would be the case for any loadbalancer and not just F5. Thanks!Resumed SSL session and decryption
Hi, I tried to figure out if there is a way to decrypt resumed SSL session in Wireshark if first session with full SSL handshake (including pre-master key exchange) is not captured. Seems that it's not possible even when pre-master secret was captured via ssldump. But maybe I am doing something wrong? Scenario: tcpdump used to capture first session with full SSL Handshake ssldump used to extract pre-maset secret to the file Wireshark is capturing traffic including first session - everything is encrypted pre-master secret file configured in Wireshark - traffic decrypted, including following resumed sessions (same is true when private key is configured in Wireshark) New capture in Wireshark performed Client and server are still resuming SSL session (same SessionID reported in ClientHello) - no traffic decrypted. Is above correct? I assumed that when original pre-master secret is know to Wireshark it can generate master key and use it for resumed sessions even without seeing original full SSL Handshake. Am I missing something here? Is that just limitation of Wireshark or it is not technically possible at all to decrypt resumed session knowing original pre-master key. Sure I am talking about RSA non ephemeral cipher suites, in this case Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) PiotrResumed SSL session and decryption
Hi, I tried to figure out if there is a way to decrypt resumed SSL session in Wireshark if first session with full SSL handshake (including pre-master key exchange) is not captured. Seems that it's not possible even when pre-master secret was captured via ssldump. But maybe I am doing something wrong? Scenario: tcpdump used to capture first session with full SSL Handshake ssldump used to extract pre-maset secret to the file Wireshark is capturing traffic including first session - everything is encrypted pre-master secret file configured in Wireshark - traffic decrypted, including following resumed sessions (same is true when private key is configured in Wireshark) New capture in Wireshark performed Client and server are still resuming SSL session (same SessionID reported in ClientHello) - no traffic decrypted. Is above correct? I assumed that when original pre-master secret is know to Wireshark it can generate master key and use it for resumed sessions even without seeing original full SSL Handshake. Am I missing something here? Is that just limitation of Wireshark or it is not technically possible at all to decrypt resumed session knowing original pre-master key. Sure I am talking about RSA non ephemeral cipher suites, in this case Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) PiotrLeveraging SSL connections between BIG IP LTM and backend servers
Hi Team, I have a scenario, wherein the SSL worker threads on the backend servers are being exhausted while processing all the SSL requests between BIG-LTM and the backend servers. I'm looking at some options/settings on BIGIP which can leverage already open SSL connections with backend servers so as to not bombard the backend servers with too many SSL handshake requests. I see OneConnect profile can leverage the already existing idle connections between LTM and backend server but not sure if it can used for leveraging open SSL connections as well. The idea is to reduce the number of encryption/decryption mechanism on the backend server. Can anyone provide their expertise to achieve this. BR, MSK