iRule TLSv1.2 Redirect Page
I've created an iRule that builds out the redirect page we want to send people to if there browser isn't using TLSv1.2 and it works if I hit the url directly i.e. https://www.oursite.com or by typing something like https://www.oursite.com/locations/gohere. However, if I do a google search and click on the link from the search results for https://www.oursite.com/locations/gohere it will redirect to my TLSv1.2 page but the images don't display. if I view the link of an image it says https://www.oursite.com/locations/gohere/logo.png. Is there a way to handle this so if someone does do a google search and clicks on a link, the redirect page along with the images will display no matter where the page they are trying to get to is in the site structure? Here's the iRule code: when HTTP_REQUEST { if { [SSL::cipher version] ne "TLSv1.2" } { log local0. "Client from IP: [IP::client_addr] is using [SSL::cipher version], which is not TLS1.2 so redirected to maintenance page" switch [HTTP::uri] { "/fceLogo.png" { HTTP::respond 200 content [ifile get "fceLogo_png"] "Content-Type" "image/png" } "/fceHeader.jpg" { HTTP::respond 200 content [ifile get "fceHeader"] "Content-Type" "image/jpeg" } "/chromeLogo.png" { HTTP::respond 200 content [ifile get "chromeLogo"] "Content-Type" "image/png" } "/firefoxLogo.png" { HTTP::respond 200 content [ifile get "firefoxLogo"] "Content-Type" "image/png" } "/ieLogo.png" { HTTP::respond 200 content [ifile get "ieLogo"] "Content-Type" "image/png" } "/safariLogo.png" { HTTP::respond 200 content [ifile get "safariLogo"] "Content-Type" "image/png" } "/fceFooterLogo.png" { HTTP::respond 200 content [ifile get "fceFooterLogo"] "Content-Type" "image/png" } default { HTTP::respond 200 content [ifile get FarmCreditEastTLS ] "Content-Type" "text/html" } } } else { log local0. "The connection was initiated using TLSv1.2 and it was successful!!" } } Thanks.
An Irule for Client Ssl Profile that Allows Unassigned TLS Extension Values (17516)
Hello Community, I have a requirement to allow enriched https header enrichment. The SSL negotiation (I'm doing ssl termination on F5) fails because the enriched header from client contains reserved tls extension values. (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtmltls-extensiontype-values-1). The Client Hello request in the SSL Handshake was captured and contained an Extensions list, which included a reserved TLS Extension value (17156), which the F5 isn't presenting in Server Hello. I need an irule that can allow that Extension to be added on the client ssl profile so the ssl handshake doesn't fail.When was SSL mutual authentication introduced to Big-IP?
Hey f5'ers, I have a question around SSL Mutual Authentication. Does anyone know when was mutual authentication introduced to LTM and which version of Big-IP in was introduced with please? We are experiencing some difficulty in establishing a mutually authenticated TLS1.2 session between another organisation's f5 LTM and our NGINX server. We can see their f5 LTM sending a client certificate/signer/root bundle when prompted but our NGINX server is then closing the connection with an ASN1 parsing issue. They are claiming that they have discovered that their version of Big-IP is unable to perform mutual authentication with TLS1.2, but given that we see their client certificate arriving at our NGINX server and WE are closing the connection, that doesn't make sense. I just wanted to clarify when exactly MA was introduced to Big-IP as I've been using it for 6 years now and I imagine it must have been there for ages? Thanks in advance, PeterAn Irule for Client Ssl Profile that Allows Unassigned TLS Extension Values (17516)
Hello Community, I have a requirement to allow enriched https header enrichment. The SSL negotiation (I'm doing ssl termination on F5) fails because the enriched header from client contains reserved tls extension values. (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtmltls-extensiontype-values-1). The Client Hello request in the SSL Handshake was captured and contained an Extensions list, which included a reserved TLS Extension value (17156), which the F5 isn't presenting in Server Hello. I need an irule that can allow that Extension to be added on the client ssl profile so the ssl handshake doesn't fail.VIP SSL TLS v1.1 and TLS v1.2
Hello Friends, We want setup an encription VIP with the following consideration: The connection from the Client to the VIP F5 will be TLS v1.1 The connection from the VIP F5 to the server will be TLS v1.2 We only have one certificate for both connection. Which would be the step for that configuration? Thanks for your answers.
Has anyone successfully used TLSv1.2 on 10.2.4 ? I get a "decrypt_error" when there is client authentication enabled on server.
BigIP 6900 OS v 10.2.4 Recently our server teams told us they are disabling TLSv1 and 1.1 - only allowing TLSv1.2 The communication broke after they disabled - i captured and see only "Client Hello" from LB and no response from server. I forced the serverssl with DEFAULT:!TLSv1:!SSLv3:!SSLv2, Now the f5 makes a client hello over tls1.2 But there is a Alert- fatal: decrypt_error I tried with different servers. changed and played around with several different ciphers, but no luck.Disable TLS 1.2 from Cipher Suite
I have a SSL client using the DEFAULT cipher suite. We are currently running into issues with TLS 1.2 connections. As a temporary work around and for testing, I would like to disable TLS 1.2 as an option for making connections. Does anyone know how I might go about doing that? I've been looking for the correct cipher string to use to not use TLS 1.2, but I am having a tough time. I have gone through SOL13171, but it doesn't specificy how I would disable TLS 1.2 connections. Any help would be helpful. Thanks.A Protocol Profiler In a Few iRules
Protocol Profiler Hi everyone, In light of all the "packets you don't want on your F5 anymore" like TLS Heartbeat messages, certain TLS Cipher Suites, certain DNS messages, etc., etc.,... I have created something I dubbed a "protocol profiler". It's a longshot, and I'm pretty certain nobody will give it a try, but if you're curious, read on :) I must warn you, it's not your average iRule-to-go; if you're bold enough to want to see it in action, you'll probably have a hard time setting it up the first time. I've included a rough step-by-step process below. What is it? It's a protocol mapper that allows you to log/drop/reject/... based on any and all fields of any L5/6/7 protocol, without having to attach a protocol profile to the virtual server. The code is fairly well documented, but definitely not optimized for speed or efficiency, although I did run a full 100Mbit of continuous HTTPS POST connections through it, without crash/block/slowdown on a virtual edition. It is probably way to complex to ever put in production, but I'm having fun creating it, so if you're an iRule geek, try it out. :D What is it good for? A lot, and nothing at the same time. You can log, drop, reject, create statistics,... based on any and all fields of any protocol. Below are a few examples of possible usecases: F5 has no IMAP, POP3, IMAPS, ... profiles. You could create a protocol map that allows you to loadbalance based on recipient email address, or implement a "poor man's mail firewall". If you want to know which TLS Cipher Suite your F5 uses most in its ServerHello responses to clients, you can make this iRule log just that field. If you want to know how many people still connect to your F5s using SSLv3 in comparison to the other versions. You can protect the F5's or your backendserver's SSL/TLS-stacks by dropping connections based on something you detect on the wire, even before the F5 starts speaking SSL/TLS. Some examples of this are 'dropping connections using TLS heartbeat messages' or 'dropping connections from clients that support old/insecure/disallowed ciphers'. Hoe does it work? You describe a protocol in an array of hierarchical indexes. Each described field has a name, a length and a decoder-type. Fields can be grouped into containers. Each field can be used as reference for the lengthvalue in bytes of another field in the tree. Each field can be used as marker for another container in the protocol-tree. (Example: in TLS, there is a certain field that says if the record is a ClientHello or ServerHello; the value of this field is matched with the actual data, so the algorithm can continue mapping the correct part of the tree) The decoder types are actually references to procedures, so you can interpret any piece of the data the way you want. For example: 'represent the field's datavalue as a readable string', or 'parse the next 20 bytes as a DNS A query'. Decoders are created in the iRule named 'ProtocolProfilerDecoders'. How do I use it? It uses the TCL's 'proc' feature, so make sure you have v11.4 or better. Upload all the attached iRules to your F5. The iRules with names starting with 'ProtocolProfiler' are libraries, just upload them, let them sit. You will need to make the traffic pass through an 'analyzer virtual-server' first. The iRule linked to this analyzer virtual server allows you to set the name of the 'real' virtual-server to which it needs to forward the traffic post-analysis. The iRules with names starting with 'rule_' are the iRules you link to the 'analyzer virtual-servers'. This means that you need to change the original destination IP of the real virtual server to something 'useless' like 1.1.1.1 and use the original destination IP as destination IP on the analyzer virtual-server. This way, the traffic is received by the analyzer and the iRule linked to that analyzer makes sure the traffic is sent to your own virtual server with irules, profiles, persistence stuff and pool. In the CLIENT_ACCEPTED event of the iRule that you linked to the analyzer virtual-server you'll find a 'virtual ' statement. change the to the name of your real virtual server. This is the 'thing' that forwards traffic to your original virtual server, regardless of its destination address. I created a (good but incomplete) map for SSLv3/TLSv1.x and a very incomplete map for DNS; but it demonstrates the iRule's 'power'. You can link the rule_sslprofiler.tcl iRule to your analyzer virtual-server and watch the magic happen. For the lazy, here are some tmsh commands to set you up (beware though, modifying the real virtual server to another destination IP will render it useless until you add the next virtual server with correct iRule) tmsh modify ltm virtual vs_real-virtual-server { destination 1.1.1.1:443 } tmsh create ltm virtual vs_analyzer-virtual-server { destination 11.11.11.12:443 profiles add { tcp } rules { rule_sslprofiler }} With the last command executed, modify the iRule rule_sslprofiler to have the CLIENT_ACCEPTED event contain a statement "virtual vs_real-virtual-server"; remove any other 'virtual' statements. The code, the code, where is the code? ProtocolProfilerTMAPs.tcl => ">http://pastebin.com/1wK46AiW" target="_blank">">http://pastebin.com/1wK46AiW ProtocolProfilerDecoders.tcl => ">http://pastebin.com/reg3cmAH" target="_blank">">http://pastebin.com/reg3cmAH ProtocolProfilerProcs.tcl => ">http://pastebin.com/3Q3sCN27" target="_blank">">http://pastebin.com/3Q3sCN27 ProtocolProfilerInit.tcl => ">http://pastebin.com/VBzhNEPs" target="_blank">">http://pastebin.com/VBzhNEPs rule_sslprofiler.tcl => ">http://pastebin.com/SFJG7uNH" target="_blank">">http://pastebin.com/SFJG7uNH rule_dnsprofiler.tcl => ">http://pastebin.com/QLqug3yg" target="_blank">">http://pastebin.com/QLqug3yg Is this going anywhere? No, not really, it's a fun project and can teach you a lot about the underlying protocols and iRules in general. I'm not far off making it capable of decrypting 'normal' TLS on the wire, provided RSA key exchange is being used. The code can see both client- and server-random values, the public key for the server and the encrypted premaster secret; one could feed it the server's private key and generate the keys necessary to decrypt the data, much like Wireshark does, by using PMS-files or the actual private keys. Imagine that: no SSL profiles, no SSL offloading, full visibility, totally useless, but epically cool! :) Look ma' no profiles! Greets, Thomas Schockaert
