OpenSSL and Heart Bleed Vuln
Get the latest updates on how F5 mitigates Heartbleed Hi Team, I know this question is eventually going to be asked - I may as well do it. With the news today about the Heartbleed OpenSSL Vulnerability (http://heartbleed.com) I wanted to confirm if we are at any risk. All of my LTM V11 and V10 instances are running OpenSSL 0.9.8x which does not appear to be a vulnerable version of OpenSSL... Does the F5 hook into this when we Sign/Request SSL Certs? If so we're sitting pretty, right? Thanks. Updates based on feedback: ul Update 2: F5 have published a security advisory on this issue - http://support.f5.com/kb/en-us/solutions/public/15000/100/sol15159.html
Redirect TCP connections from port 443 to 80
Hi All We have a port 80 and 443 VIP configured for 301 redirections to send sites to specific pages on a target branding site. We use 301 redirects and it works just fine via irule. However, for this to work for HTTPS requests, we need a cert and SSL profile to decrypt the request and then redirect it. The same irule is in use for both the 80 and 443 VIPs I'm wondering whether it's possible to do a basic 'when client_accept/connect' irule to force ALL connections to the VIP to go to the port 80 version so that we don't need to keep purchasing certs for 'old' websites. Perhaps another option would be to set a single client_ssl profile on the 443 VIP, use a 'when clientssl_handshake' iRule and try redirect to 80 that way, but I have my doubts. This is a bit beyond my current iRule skills.... Cheers
High CPU utilization (100%).
I observed high CPU utilization (100%) on F5 device, resource provision ASM nominal. I checked the client-side throughput and server-side throughput both are normal but found management interface throughput is very high and what i noticed this is happening in same time period for last 30 days. What could be the reason for this spike. Many thanks in advanced for your time and consideration.
How does https send string works ?
Hi Team , How does the below send string works ? What is the exact meaning of this send string path ?Can someone please explain in detail based on the below mentioned send string . Send string : GET /PasswordVault HTTP/1.1\r\nHost: example.xyz.com\r\nConnection: Close\r\n\r\n Receive string : 200
https connection with URI shows as not secured ?
Hi Team , We have a new VIP with url https://example.test.com , but when we try to access the url with uri it says "The information you're bout to submit is not secure " https://example.test.com >> WORKS https://example.test.com/sap/saml2/sp/acs/100 >> error : "The information you're bout to submit is not secure " Please advice .Incosistent forwarding of HTTP/2 connections with layered virtual
Hi, I'm using a layered virtual configuration: Tier1: Virtual applying SNI-Routing (only SSL persistence profile and LTM policy as described in https://www.devcentral.f5.com/kb/technicalarticles/sni-routing-with-big-ip/282018) Tier2: Virtual applies SSL termination and delivering the actual application, with the required profiles, iRules, .... If the required, an additional LTM policy is applied for URI-based routing and forwards to Tier3 VS. Tier3 (optional, if required): Virtual delivers specific applications, like microservices, usually no monolithical apps. This configuration is very robust and I'm working with it successfully since years. Important: The tier1 uses one single IP address and a single port. So all tier2 and tier3 virtuals MUST be externally available through the same IP address and port. Now I have to publish the first HTTP/2 applications over this concept and see strange behavior of the BIG-IP. User requests www.example.com. IP and port point to tier1 virtual. Tier1 LTM policy forwards the requests, based on the SNI, to tier2 virtuals "vs-int_www.example.com". Within www.example.com there are references to piwik.example.com, which is another tier2 virtual, behind my tier1 virtual. User requests piwik.example.com. IP and port point to tier1 virtual. Tier1 LTM policy forwards the requests to "vs-int_www.example.com" instead of "vs-int_piwik.example.com". Probably not based on SNI, but on the existing TCP connection. I'm afraid, that this bahvior is a result of HTTP/2, especially because of the persistent TCP connection. I assume that, because the connection ID (gathered from browser devtools) for requests to www.example.com and piwik.example.com is identical. From the perspective of the browser I wouldn't expect such a behavior, because the target hostname differs. I didn't configure HTTP/2 in full-proxy mode, as described in several articles. I've just enabled it on the client-side. I would be very happy for any input on that. Thanks in advance!
