tls
38 TopicsINFORM: 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 situation115Views0likes1CommentDecrypting 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 issue2.5KViews0likes14CommentsSSL::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...625Views1like2CommentsSSL 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] }686Views0likes2Comments[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.487Views0likes7CommentsChange 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 🙂166Views0likes0CommentsHow 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).803Views0likes2Commentsissue 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.387Views0likes1CommentIncrease DH key exchange to 2048
I'm trying to move from cipher lists in the ssl profile to cipher rules and groups in order to support TLS1.3 I would like to only enable strong cipher suites. So far I've found this list TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 So far I've come up with this string to reproduce the list: ECDHE+AES-GCM:DHE+AES-GCM:CHACHA20-POLY1305 Each time I test it the DHE+AES-GCM gets flagged because it is only 1024 bits. Removing it means removing a lot of clients from the compatibility list. After days of reseach I can't find the place to increase my DH group strength. Only a 5 year old article which says that I can't increase it. Does anyone know if it is possible to increase DH group strength in either 13.1.1 or 14.1.2, and where to do it?Solved12KViews0likes16CommentsTLS/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-Alive777Views0likes5Comments