Decrypting SSL traffic - PMS and egress
Hi - two questions combined. Background - trying to catch and decipher tcpdump both for Client -> VIP and F5-> Pool Members traffic I'm following this tutorial:Decrypt with tcpdump --f5 ssl I managed to catch the frontend traffic, but I'm struggling with creating the PMS key. I want to automate it using the provided wireshark cmd command, but I get the error: C:\Program Files\Wireshark: invalid option -- 'T' C:\Program Files\Wireshark: invalid option -- 'e' I'm using Wireshark 3.4.8 - what would be the equivalent options for my version? Unfortunately using a Linux in this environment is out of the question. I can only work on Windows stepping stone and can't send the captures to my PC Second issue: Catching the backend traffic does not produce the F5 TLS in the pcap capture... The server ssl profile is present, but I have no idea how to force the --f5 ssl option in tcpdump to catch the keys. Will appreciate any advice - It is my second day struggling with the issue
SSL::enable/SSL::disable unexpected behaviour
I have a question about the specific bahaviour of LTM with regard to SSL::enable/SSL::disable. I have a virtual server with two pools: One pool has a member that needs TLS communication; The other pool has a member that doesn't use TLS (i.e., it uses plain text HTTP). The pool selection is based on the request URI (e.g., the first URI-path selects the pool). I have a serverside SSL profile configured to my virtual server. When I use the iRule below, the behaviour is not quite what I expected: when HTTP_REQUEST { if { } { select the tls-pool: enable server side SSL SSL::enable serverside pool } else { select the http-pool: disable server side SSL SSL::disable serverside pool } } ` The observed behaviour is as follows: Client connects to virtual server (new TCP connection). Client issues a request that selects the http-pool. The http-pool member responds (confirmed: the 'SSL::disable' works). Over the same client TCP connection, the client issues a request that selects the tls-pool. The tls-pool member responds (confirmed: server side TLS is working). Over the same client TCP connection, the client issues a request that selects the http-pool again. This fails! A tcpdump reveals that LTM is sending a TLS Client Hello to the http pool member. The pool member responds with a '400 Bad Request', I get errors in /var/log/ltm: `warning tmm2[1688]: 01260009:4: Connection error: ssl_null_parse:3177: record length too large (22) warning tmm2[1688]: 01260013:4: SSL Handshake failed for TCP 192.168.10.10:80 -> 192.168.10.1:50214 ` and the client side TCP connection is aborted (TCP RST). When I rewrite my iRule to perform the 'SSL::enable' and 'SSL::disable' in a SERVER_CONNECTED event, all seems to work fine: `when HTTP_REQUEST { if { } { set tls 1 pool } else { set tls 0 pool } } when SERVER_CONNECTED { if { $tls == 1 } { SSL::enable serverside } else { SSL::disable serverside } } What is the difference? My guess is it has to do with attach/detach. But I seem to miss the subtle difference...
SSL Bridging with URL Rewrite
I need to terminate SSL, rewrite the URL and URI, then send to the new destination server with SSL. I have this working, but the SSL session resumption is failing so I have to re-handshake for every call. For a 20 millisecond server call, 80 milliseconds of handshaking is a non-starter. What am I doing wrong? when HTTP_REQUEST { #log local0. "host: [HTTP::host], uri: [HTTP::uri]" switch -glob [string tolower [HTTP::host]] { "apps.svr1.oscplatform.site" - "apps.svr2.oscplatform.site" - "apps.svr3.oscplatform.site" { # Example rewrite URL: # apps.svr1.oscplatform.site/rerwite/example-service/blah # Result after rule: # example-service.apps.svr1.oscplatform.site/blah # Removed the /rewrite/ set svc_uri [substr [HTTP::uri] 9] #log local0. "svc_uri: $svc_uri" # Splits the remaining URI into service name and original URI. # 'example-service/blah' becomes 'example-service' and '/blah' set part_count [scan $svc_uri {%[^?/#]%s} svc uri] # If there was no original URI update it to blank. if { $part_count == 1 } { set uri "" } #log local0. "host: $svc.[HTTP::host] uri: '$uri'" # Set the new host value. HTTP::host "$svc.[HTTP::host]" # Update URI to the correct value. HTTP::uri "$uri" } } # Set the value used in the SNI extension record. # This is used in the SSL handshake to the destination server. # This is how we implement SSL Bridging with a possible URL rewrite in the middle. set sni_value [HTTP::host] } when SERVERSSL_CLIENTHELLO_SEND { #log local0. "sni_value: $sni_value" # SNI extension record as defined in RFC 3546/3.1 # # - TLS Extension Type = int16( 0 = SNI ) # - TLS Extension Length = int16( $sni_length + 5 byte ) # - SNI Record Length = int16( $sni_length + 3 byte) # - SNI Record Type = int8( 0 = HOST ) # - SNI Record Value Length = int16( $sni_length ) # - SNI Record Value = str( $sni_value ) # # Calculate the length of the SNI value, Compute the SNI Record / TLS extension fields and add the result to the SERVERSSL_CLIENTHELLO SSL::extensions insert [binary format SSScSa* 0 [expr { [set sni_length [string length $sni_value]] + 5 }] [expr { $sni_length + 3 }] 0 $sni_length $sni_value] }
[F5 LTM 11.4.1 HF9][2-Way-auth] CLIENTSSL_CLIENTCERT is not triggered in the Irule
Hello all, I am trying to implement an Irule to filter CN names. below the irule : when RULE_INIT { set static::org "O=OPS" log local0.alert "RULE_INIT" } when CLIENTSSL_CLIENTCERT { Check if client provided a cert if {[SSL::cert 0] eq ""}{ Reset the connection reject } else { Example Subject DN: /C=AU/ST=NSW/L=Syd/O=Your Organisation/OU=Your OU/CN=John Smith set subject_dn [X509::subject [SSL::cert 0]] log local0.alert "Client Certificate Received: $subject_dn" Check if the client certificate contains the correct O and a CN from the list if { ([matchclass $subject_dn contains cn_allowed]) and ($subject_dn contains $static::org) } { Accept the client cert log local0.alert "Client Certificate Accepted: $subject_dn" } else { log local0.alert "No Matching Client Certificate Was Found Using: $subject_dn" reject } } } The "cn_allowed" contains the list of allowed CNs. When I make a new connection with the browser (after sending the client certificate), I am not getting any log in /var/log/ltm related to the CLIENTSSL_CLIENTCERT section (only the rule init is shown). Kindly help me to resolve this problem. Thanks in advance.
Change in behavior ID411879
There are quite a few threads open here in the forum, all indicating SSL handshake issues when upgrading from a version < 11.4.0 to a version >= 11.4.0. The reason for all these issues seems to be the change in behavior ID411879 (from version 11.4.0), which is described as follows: For serverssl profiles, the system uses TLS in the following way: TLS1.2, then TLS1.1 and TLS1.0. Previously, it was TLS1, TLS1.2 and TLS1.1. This might result in unexpected status settings for existing virtual servers configured in previous releases. But is there anybody, who can explain the internal logic/algorithm behind that? I mentioned it already in another thread **_what kind of sense makes an order if the second or third option will never be used, when the first one fails?_** I don't think this is a bug, but is more related to the standard SSL handshake process. But I haven't the required knowledge in detail to explain and/or understand this behavior. I hope we can finally solve this topic. Thank you! Ciao Stefan 🙂
How to set top priority for TLS 1.2 protocol over TLS 1.0 for client ciphers in BIG-IP v11.6.x
Problem: The F5 (version 11.6.x) establishes a TLS 1.0 connection for a client browser even if protocols TLS 1.2 and TLS 1.1 are part of the supported ciphers on both sides (client browser and F5 client-side). How can I force the F5 to use the highest protocol available? How can I reorder the ciphers/protocols to put TLS 1.2 at the top of the protocol negotiation mechanism? How does the F5 perform the TLS protocol negotiation? The cipher string: DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:!SSLv3:!DTLSv1 tmm --clientciphers 'DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:!SSLv3:!DTLSv1' ID SUITE BITS PROT METHOD CIPHER MAC KEYX 0: 51 DHE-RSA-AES128-SHA 128 TLS1 Native AES SHA EDH/RSA 1: 51 DHE-RSA-AES128-SHA 128 TLS1.1 Native AES SHA EDH/RSA 2: 51 DHE-RSA-AES128-SHA 128 TLS1.2 Native AES SHA EDH/RSA 3: 57 DHE-RSA-AES256-SHA 256 TLS1 Native AES SHA EDH/RSA 4: 57 DHE-RSA-AES256-SHA 256 TLS1.1 Native AES SHA EDH/RSA 5: 57 DHE-RSA-AES256-SHA 256 TLS1.2 Native AES SHA EDH/RSA The client browser is Safari 11.1 (the latest version at time of writing).issue with ssl client profile when adding irule sni injection to a vs
Hello, We want to add SNI field to our MQTT/TLS trafic between clients and a broker servers (acting as servers). unfortunatelly, the client do not support SNI extension field. The F5 is acting in TLS passthrough. the broker servers are the TLS server end point. For that I use an irule with SSL::extensions insert (check below). I am creating my self the SNI extension. unfortunatelly, When adding my irule to my virtual server, I cannot validated my virtual server, i get an error that a client ssl profile is not present. here is my irule: when CLIENTSSL_CLIENTHELLO { SNI extension record as defined in RFC 3546/3.1 - TLS Extension Type = int16( 0 = SNI ) - TLS Extension Length = int16( $sni_length + 5 byte ) - SNI Record Length = int16( $sni_length + 3 byte) - SNI Record Type = int8( 0 = HOST ) - SNI Record Value Length = int16( $sni_length ) - SNI Record Value = str( $sni_value ) Calculate the length of the SNI value, Compute the SNI Record / TLS extension fields and add the result to the SERVERSSL_CLIENTHELLO SSL::extensions insert [binary format SSScSa* 0 [expr { [set sni_length [string length "testname"]] + 5 }] [expr { $sni_length + 3 }] 0 $sni_length "testname"] } I don't understand why i need to add a ssl profile to my virtual server, as F5 is TLS passthrough. thanks for your answer.
TLS/1.0, PCI, and a custom message for HTTP response status codes
By June 30, 2018 we would like to turn off TLS/1.0 on all our HTTPS websites, in order to be compliant with PCI requirements. Instead of just turning TLS/1.0 off, we would like to use that time between now and June 30, 2018 to seamlessly phase the TLS/1.0 out. To do so, our F5 still supports all TLS protocols (TLS/1.0, TLS/1.1, and TLS/1.2), but only the clients supporting TLS/1.1 and above get the actual website content. Everyone else (clients supporting TLS/1.0 only) gets a custom error page informing them about the browser upgrade requirement. To achieve that, I'm using the HTTP status code "426 Upgrade Required". Please see: 4.2 Mandatory Advertisement in RFC2817 Server-initiated upgrade to TLS The expected result is: HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.1, HTTP/1.1 Connection: Upgrade ... Human-readable HTML page describing why the upgrade is required and what to do if this text is seen ... Unfortunately, F5 gives me the following result: HTTP/1.1 426 Unknown Code Upgrade: TLS/1.1, HTTP/1.1 Connection: close ... Human-readable HTML page describing why the upgrade is required and what to do if this text is seen ... My iRule looks like this: Detect TLSv1.0 protocol and send HTTP 426 when HTTP_REQUEST priority 150 { if { [SSL::cipher version] equals "TLSv1" } { log local0. "TLS/1.0 connection detected from [IP::client_addr] for [HTTP::host]" HTTP::respond 426 -version auto content $static::obsolete_browser_page noserver "Upgrade" "TLS/1.1, HTTP/1.1" "Content-Type" "text/html" "Cache-Control" "no-cache" "Retry-After" "60" "Connection" "Close" event disable return } } If I use "Connection" "Upgrade" in the HTTP::respond code, as defined in the aforementioned RFC2817, F5 replaces it with Connection: Keep-Alive in the actual response which is being sent back to the client. My questions are: Question 1: is there a way in F5 to replace the message in HTTP response, so that it says: HTTP/1.1 426 Upgrade Required instead of HTTP/1.1 426 Unknown Code Question 2: is there a way to force F5 to send HTTP header that says: Connection: Upgrade instead of Connection: close or Connection: Keep-Alive
Chrome v30 Triggers v10.2.x TLS and ClientHello Bugs -- Sites Down
The recent upgrade to Chrome v30 exploits a bug in 10.2.x where the BIG-IP refuses to respond to ClientHello with ServerHello. I am trying to determine in what version(s) this is actually fixed. It seems this bug is two-fold: "From testing it appears that these servers hang the connection if: 1. The ClientHello record is larger than 255 bytes _and_ 2. The record version is greater than 0x0301 (0x0301 = TLSv1.0). This is different from the traditional F5 bug, which hangs the connection based only on the size of the ClientHello record." (Above quoted from comment 17 on https://code.google.com/p/chromium/issues/detail?id=303398) Issue "1" from above seems to have been fixed in 10.2.2 HF2: Bug ID 364699: "ClientHello SSL messages greater than 256 bytes in length no longer cause connections to clientssl virtual servers to stall, or re-negotiations to fail." (SOL13109) The problem is that I have contacts experiencing the overall issue on 10.2.3 HF1 and 10.2.4 HF4. There are reports that things work properly by 10.2.4 HF6 (From comment 18 on https://code.google.com/p/chromium/issues/detail?id=303398) -- I have not tested or heard about 10.2.4 HF5. Issue "1" could also relate to 10.2.4-732.0 (HF5) which included F5 Bug ID 225445 (SOL8653 ††😞 "SSL handshakes with large, but RFC-compliant, messages (for example, large certificate chains) are now correctly handled by the BIG-IP." (†† SOL8653 does not mention v10.2.4, but the release notes include this F5 Bug ID.) Issue "2" may have been dealt with in 10.2.2 HF1 and 10.2.3: Bug ID 363396 (SOL13037) Bug ID 407706 (included in 10.2.4 HF6) may also be related: "BIG-IP is no longer susceptible to the attacks described in CVE-2013-0169." * While this CVE does not seem to be specifically relevant to this bug, the fixes touch TLSv1.1 and TLSv1.2, both of which are related to the issue you're seeing. It is quite possible that the fixes implemented by F5 for this bug also took care of your issue.