Any approach to encrypting HSL traffic such that no plain text is ever sniffable?
Hi - we have been asked to integrate a vendor logging solution on our F5s that uses HSL to send information about requests to and responses from our HTTP/HTTPS VIPs on our LTMs. (I describe this configuration in more detail in a post yesterday, with the title "Pool used with HSL::open - what are the requirements? Any way to make it send using TLS?" ... but in summary, they use an iRule with HSL:open against a manually created pool, that uses as members an HTTP VIP created on the same F5; that in turn requires us to use a static route to send the traffic over the management interface, so it can reach the VIP on the same F5). Though we have a solution for the flow (see other post), it results in the logged content being plain-text on our network, whilst going from the management port to the VIP used as a destination of the HSL pool. Is there any general solution or design that would permit us to send out HSL logging such that it is TLS encrypted right from the moment it is sent by the F5, never appearing in plain text on our network? Thank you!
Question on configuring SNI clientSSL Profile
Hi Experts , I have a question on configuring the SNI SSL profile .Suppose say I have 3 different certificate and 3 SSL profile to be attached to the VIP to configure SNI . https://www.securesite1.com ClientSSL1 > Default SSL Profile for SNI https://www.securesite2.com ClientSSL2 https://www.securesite3.com ClientSSL3 To enable SNI, we configure the Server Name and Default SSL Profile for SNI will be checked on an SSL profile of ClientSSL1, and then assign the profile to a virtual server. How about on other 2 SSL profiles ClientSSL2 & ClientSSL3 ? For other SSL profiles do I need to type the name for the HTTPS site in the Server Name box ? or it can be left blank ?INFORM: Entrust CA will be untrusted in Chrome after Oct 31, 2024
If you manage certs from Entrust in your environment, this will impact your Google Chrome users, so intermediate certs will likely need to be bundled to handle this in your clientssl profiles OR if you control all the clients you can assure that explicit trust in the clients is enabled for Entrust CAs. Google details on the situation
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).
