sni
34 TopicsTCP::collect and large TLS v1.3 client hello packets
Is anyone using iRules successfully to parse SNI names from the new TLS 1.3 hybridized Kyber client hello packets? The problem is the these packets are larger than MTU(?) size, around ~1800 bytes. Normal hello packets are ~500 bytes. I'm using TCP profile for which iRule parses SNI name to pass the connection as is to correct destination pool. How to reproduce: when CLIENT_ACCEPTED { TCP::collect } when CLIENT_DATA { # [TCP::payload length] shows only 1352, rest of packet missing, CLIENT_DATA is never called again } It only ever gets the first ~1352 bytes from packet, CLIENT_DATA is only called once, seems there is no way to get rest of the packet. If I add argument to collect length >1500 with "TCP::collect 1600", then it will read the whole ~1800 byte packet in first CLIENT_DATA. But this will break all connections that send normal small ~500 byte hello packets, as it just keeps on waiting for data indefinitely. Is there any workaround? BIG-IP version 16.1.4.1.Solved132Views0likes4CommentsChrome V 124+ on MacOS - Virtual Server Access Issue
(editors note: this is not just MacOS - appears to be all Chrome browsers regardless of OS) It appears that the latest version of Google Chrome (version 124) on MacOS (ed. any OS) has broken the above code. With debugging turned on, we get this when a MacOS client accesses a virtual server with this rule: No SSL/TLS protocol detected ; connection is rejected (0x0000) Can anyone else confirm this? Any idea how to fix it?Stanislas_Piro2 ---- (Editors Note: This forum post was created via a comment on the OG Article written by Eric_Chen here: How to use SNI Routing with BIG-IP. That article contains 'the above code' and 'the rule' referenced here)Solved794Views2likes25CommentsAPM :: Portal Access Lists :: SNI & HTTP
I'm trying to create a Portal Access List with a few web resources, and one of the links does not work because it is an Apache server that is validating that the SNI and HTTP hostname match. The problem is, that when the user logs into APM and launches the web link, they are launching a request to the APM and not the backend server... therefore the SNI is for APM and does not match the HTTP hostname in the header (which is specified in the Portal Access link via Application URI). [ssl:error] [pid 11111] AH02032: Hostname xxx.yyy.com provided via SNI and hostname aaa.bbb.com provided via HTTP are different From what I've read, this cannot be disabled on the Apache server without removing SNI and recompiling... which is not an option for me. However this F5 use-case seems like it would be fairly common, so I'm not sure what I'm missing here. Anybody have any thoughts? Thanks-472Views0likes1CommentBIG-IP DNS SNI monitoring
We are trying to get a SNI monitor to work on a BIG-IP DNS to a generic host. Using the external ADFS monitors the checks fail. When running a CURL to the destination servers we receive Unknown SSL protocol error in connection while a openssl test returns the cert and the CN we are grepping for but the moniotr still fails. We have tried with the standard ADFS external monitor provided by F5 along with the amended version for TLS1.1 and above. Also tried another custom one from Devcentral. Can anyone provide any pointers in how we could get this to work? Monitor 1: !/bin/sh These arguments supplied automatically for all external monitors: $1 = IP (nnn.nnn.nnn.nnn notation) $2 = port (decimal, host byte order) This script expects the following Name/Value pairs: HOST = the host name of the SNI-enabled site URI = the URI to request RECV = the expected response Remove IPv6/IPv4 compatibility prefix (LTM passes addresses in IPv6 format) NODE= echo ${1} | sed 's/::ffff://' if [[ $NODE =~ ^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}$ ]]; then NODE=${NODE} else NODE=[${NODE}] fi PORT=${2} PIDFILE="/var/run/ basename ${0} .sni_monitor_${HOST}_${PORT}_${NODE}.pid" if [ -f $PIDFILE ] then echo "EAV exceeded runtime needed to kill ${HOST}:${PORT}:${NODE}" | logger -p local0.error kill -9 cat $PIDFILE > /dev/null 2>&1 fi echo "$$" > $PIDFILE (echo -e "GET $URI HTTP/1.1\r\nHost: $HOST\r\nConnection: Close\r\n\r\n"; sleep 2) | openssl s_client -cipher 'ECDHE-RSA-AES256-SHA' -servername '$HOST' STATUS=$? rm -f $PIDFILE if [ $STATUS -eq 0 ] then echo "UP" fi exit Monitor 2 !/bin/sh These arguments supplied automatically for all external monitors: $1 = IP (nnn.nnn.nnn.nnn notation) $2 = port (decimal, host byte order) This script expects the following Name/Value pairs: HOST = the host name of the SNI-enabled site URI = the URI to request RECV = the expected response Remove IPv6/IPv4 compatibility prefix (LTM passes addresses in IPv6 format) NODE= echo ${1} | sed 's/::ffff://' if [[ $NODE =~ ^[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}$ ]]; then NODE=${NODE} else NODE=[${NODE}] fi PORT=${2} PIDFILE="/var/run/ basename ${0} .sni_monitor_${HOST}_${PORT}_${NODE}.pid" if [ -f $PIDFILE ] then echo "EAV exceeded runtime needed to kill ${HOST}:${PORT}:${NODE}" | logger -p local0.error kill -9 cat $PIDFILE > /dev/null 2>&1 fi echo "$$" > $PIDFILE curl-apd -k -i --resolve $HOST:$PORT:$NODE https://$HOST$URI | grep -i "${RECV}" > /dev/null 2>&1 STATUS=$? rm -f $PIDFILE if [ $STATUS -eq 0 ] then echo "UP" fi exit Monitor 3 !/bin/bash pidfile="/var/run/$MONITOR_NAME.$1..$2.pid" if [ -f $pidfile ] then kill -9 - cat $pidfile > /dev/null 2>&1 fi echo "$$" > $pidfile node_ip= echo $1 |sed 's/::ffff://' node_port=$2 getscript () { echo 'GET / HTTP/1.1' echo 'Host: ..*.com' echo '' while sleep 0; do echo 'quit\n' done } docurl () { IFS=$'\n' arr=($(getscript | openssl s_client -connect ...:443 -servername ...com 2>/dev/nul |grep -E CN=...com)) unset IFS } docurl echo ${arr[0]} if [ -n "${arr[0]}" ] then Remove the pidfile before the script echoes anything to stdout and is killed by bigd rm -f $pidfile echo "up" fi Remove the pidfile before the script ends rm -f $pidfile386Views0likes0CommentsSelected client SSL does not match security policies for VS after cipher update
Hi, I'm trying to update ciphers on one of my profiles. The one I want to use is: !LOW:!SSLv2:!SSLv3:!MD5:!RC4+SHA:!EXPORT:!DHE:ECDHE+AES-GCM:ECDHE+AES:AES+SHA+RSA:@STRENGTH This works fine on another VS, but an attemtp of installing it on this one results in this error: 0107157c:3: Selected client SSL profiles do not match security policies for Virtual Server /EXTERNAL/vs_server_443. Now the OK and NOK vs are a bit different, but I can't figure out which portion of the config can be responsible for this error. Let me summarize the differences: vs_NOK_443 Protocol Profile (Client): prot_tcp_client_name_WAN (based on tcp_wan_optimized) Protocol Profile (Server): prot_tcp_client_name_LAN (based on tcp-lan-optimized) HTTP Profile: http_xff vs_OK_https Protocol Profile (Client): tcp Protocol Profile (Server): (use Client Profile) HTTP Profile: http_xff_redir-rewrite Now i do not see any difference between http-xff and http-xff_redir_rewrite is that the latter uses a Server Agent Name Both server have two client ssl profiles and the profile in question is marked as the default profile for SNI.421Views0likes1CommentClient SSL profiles using SNI not able to use the subject alternative name
We have a clientssl profile using a *.domain.com wildcard SSL certificate. This profile is set as the default for SNI. We also have specific clientssl profiles using the application specific SSL certificate. The application specific certs have their subject as www.application.com with the subject alternative name with application.com. There may also be several other SAN listed depending on the web app. In testing everything works great when accessing the site via https://www.application.com. However when using https://application.com we receive a cert error and the *.domain.com wildcard SSL certificate is used. This is the same for any domain listed as a SAN. My main question is can SNI use subject alternative names? My testing indicates no, but I wanted to put this out to the group. Here is my sanitized config: ltm profile client-ssl domain.com_wildcard { app-service none cert domain.com_wildcard.crt chain ComodoCA.crt defaults-from clientssl key domain.com_wildcard.key sni-default true } ltm profile client-ssl prod-www_application_com { app-service none cert prod-www_application_com.crt chain prod-www_application_com.intermediate.ca.crt key prod-www_application_com.key } ltm virtual vs-x.x.x.x_443 { destination x.x.x.x:https ip-protocol tcp mask 255.255.255.255 pool site-x.x.x.x_443 profiles { http-x-forward { } domain.com_wildcard { context clientside } prod-www_application_com { context clientside } serverssl-insecure-compatible { context serverside } tcp { } websecurity { } } source 0.0.0.0/0 source-address-translation { pool snat_pool type snat } vs-index 2539 }1.4KViews0likes7Commentsissue 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.385Views0likes1CommentUsing two certificates with SNI and IP as common name
Hi all, I have a VS which client access using both FQDN and IP and I need it to be HTTPS. I have a legitimate cert for the FQDN (wildcard) and I've created a certificate for the IP address using a CA we have inhouse. I've also included SAN values for DNS and IP in this cert. When I attach each certificate individualy to the VS and try to access it accordingly, everything works fine, so I know the certs are legit. When I put both certs in the VS and configure their SSL profile with Default SNI and ServerName, it also selects the FQDN cert, even if the client access using IP address. Any suggestions why this happens? Using version 14.1.4.5. Thanks!627Views0likes2CommentsLoad balance messaging protocols like AMQP, MQTT, STOMP over TLS for ActiveMQ Artemis
Messaging protocols like AMQP, MQT, STOMP, OpenWire, HornetQ can all be load balanced trough the F5. Making the setup I encountered some issues. There is some specific configuration that needs to be apllied, which i will try to clearify. The setup: devices sending AMQP messages trough the F5 to a backend server over TLS. The F5 is configured as full proxy. The Virtual Server was pretty basic config. Standard Virtuals server, TCP, HTTP, SSL client & server profiles. Also websocket auto SNAT automap enabled. I selected the virtual server which had the correct certificate in the Clientssl profile. The client initiating the request has our root /& issuing CA trusted in their truststore. Using a tcpdump and wireshark, I saw the corect TLS handshakes, Application data over TLS is being send, but not much data and due an error *** the client sends a TCP reset. The F5 will only apply a profile, when that specific data is being detected (trigger). So yeah, there are TCP profiles to handle TCP and i have an SSL Client & server profile to handle TLS. Strangly it doesn't work. In the capture i took on the F5, wireshark sees the TLS application data as http-over-tls. hmm.. what if the F5 did the same? Then it would apply the http profile on the AMQP data, and that might screw things up. Disable the HTTP processing for that hostname, bingo. The next problem: the hostname, part off [HTTP::host] is not our event scopes. It is only activated when http profile is triggered. So the solution is to get the hostname, in this case the SNI (server name indication) from the TLS Client hello in eventCLIENTSSL_HANDSHAKE. And check the SNI value to disable http processing. caveat: this will only work for TLS 1.2. When TLS 1.3 is used with encrypted SNI, another solution is needed. Solution in short: it should work using a seperate virtual server with only TCP, SSL client & server profiles and have a load balancing default pool. If your setup is more complex and are reusing an existing VS, do the following. I use a combination of an iRule and datagrouplists to extract the SNI, disable HTTP processing and send it to the right pool. For a current setup the SNI is also inserted server-side. I think this step is optional but i'll paste the code too. datagrouplist dgl_vs01_sni_targetpool: messaging.company.local and value "the targetpool" datagrouplist dgl_vs01_disable_http_procesin: messaging.company.local without a value when CLIENTSSL_HANDSHAKE { if { [SSL::extensions exists -type 0] } { set dgl "dgl_vs01_sni_targetpool" set dgl_nohttp "dgl_vs01_disable_http_processing" # read SNI value and place into variable sni_value binary scan [SSL::extensions -type 0] {@9A*} sni_value log local0. "sni value: [expr {[info exists sni_value] ? ${sni_value} : {not found} }]" #disable HTTP processing for AMQP, MQTT, STOMP, etc if { [class match $sni_value equals $dgl_nohttp] }{ HTTP::disable log local0. "HTTP Disabled for $sni_value" } if { [class match $sni_value equals $dgl] }{ set pool_target [class match -value [string tolower $sni_value] equals $dgl] pool $pool_target log local0. "pool chosen for $sni_value, pool $pool_target " } } } when SERVERSSL_CLIENTHELLO_SEND { #Inject SNI serverside if { [class match $sni_value equals $dgl] }{ 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] log local0. "SNI inserted $sni_value" } } For those less comfterable with iRule, you can do SNI-based load balancing like thishttps://community.f5.com/t5/technical-articles/sni-routing-with-big-ip/ta-p/282018 but I'm not sure how to disable HTTP processing with a policy in the ssl client hello. If someone knows please post below, thx. Now you are all set! Good luck with your F5 adventures. Documentation used: https://clouddocs.f5.com/training/community/irules/html/class1/module1/iRuleEventsFlowHTTPS.html https://community.f5.com/t5/crowdsrc/serverside-sni-injection-irule/ta-p/286745 https://community.f5.com/t5/crowdsrc/extracting-the-sni-server-name/ta-p/288029 https://activemq.apache.org/components/artemis/documentation/1.5.1/protocols-interoperability.html3.3KViews0likes0Comments