For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

6 Replies

  • Any application layer (OSI layer 7) processing will happen AFTER SSL processing.

     

  • Hi Chells,

    if you gonna redirect the user using an iRule within the

    HTTP_REQUEST
    event (aka. client side), then you don't have to care about SSL-Offloading (aka. server side) and any possible response rewite. Just try the snippet below to see if this is working out for you...

    when HTTP_REQUEST {
        if { [string tolower [HTTP::host]] equals "website1.com" } then {
            if { [string tolower [HTTP::uri]] starts_with "/abc" } then {
                HTTP::redirect "http://website.com[HTTP::uri]"
            }
        }
    }
    

    Cheers, Kai

  • If I may clarify, if you're performing an HTTP redirect on an HTTPS/SSL virtual server, you DO have to care about the SSL in so much as you have to apply a client SSL profile to first decrypt the SSL between the client and VIP BEFORE any HTTP events will fire. An HTTP redirect will preempt traffic flow through the proxy, so nothing will pass to the server side (where you may or may not have to do SSL as well).

     

  • I definitely agree, but his original question was about the order of processing with SSL and HTTP.

    In any case, I'll take this opportunity to step up onto a soapbox.

    [soapbox]
    Dear reader, please consider the security ramifications of doing this. One of the primary tenets of SSL security is that you either encrypt everything or encrypt nothing. If you have something worth protecting within an encrypted channel, it is far easier to support that secure channel throughout the entire application than to safeguard against the vulnerabilities that exist when you switch back and forth between encrypted and unencrypted data flows within the same application.
    [/soapbox]
    
  • It depends on what you're redirecting to and why. Let's start with a simple example where you own both sites, under a single domain (ex. web1.domain.com, web2.domain.com) and either of the applications deploys domain cookies. A redirect from the HTTPS to HTTP site will potentially transmit that (session) cookie in the clear to the HTTP site. I'm assuming chells2 isn't simply redirecting to some external non-affiliated site (ex. Google), but rather some other site within the larger organization, or affiliate organization. In which case you should be very worried about what information is available in the clear and how an attacker can take advantage of that unencrypted channel. It probably begs some clarification of intentions, but I see this use case far more often than I'd hope.

     

  • Backend servers (node servers) are configured to use the Cnames (myacceslist.intranet) to communicate internally between the servers.

    Ahhhh. I think I finally see what you're saying. And actually it's a fairly common misconception that an HTTP redirect is used to change the host name for backend servers. An HTTP redirect is a flow control command. When this command is triggered it will preempt traffic from and respond directly to the client. No traffic will flow to the servers. What you need in this case is to simply change the Host header with the "HTTP::host"

    when HTTP_REQUEST {
        HTTP::host "myacceslist.intranet"
    }
    

    This will rewrite the Host header field as the HTTP request flows through the proxy to the servers.