Forum Discussion

Patrick_Mullane's avatar
Patrick_Mullane
Icon for Nimbostratus rankNimbostratus
Aug 27, 2013

SSL Offload causes "warning" on browser

We're using SSL offload but have run into a problem that I can't seem to find the answer for.

 

Our redirect and SSL offload are working. The cert is valid and we have no issues with the session setup. Our problem is that the client browser is posting a warning about non-secure content in the page because the webserver is including code that has http:/// instead of https:.

 

There must be a simple answer to prevent this, but I can't seem to find it.

 

Any help will be very appreciated.

 

  • Is the content redirects or absolute paths to page objects (images, etc.)?

     

    If redirects, you can simply enable Redirect Rewrite in the HTTP profile. Either "all" or "matching" should suffice.

     

    If page content, probably your best bet is an empty STREAM profile and a simple STREAM iRule.

     

  • The STREAM::expression wiki page actually has a great example of doing this:

     Example which replaces http:// with https:// in response content
     Prevents server compression in responses
    when HTTP_REQUEST {
         Disable the stream filter for all requests
        STREAM::disable
    
         LTM does not uncompress response content, so if the server has compression enabled
         and it cannot be disabled on the server, we can prevent the server from 
         sending a compressed response by removing the compression offerings from the client
        HTTP::header remove "Accept-Encoding"
    }
    when HTTP_RESPONSE {
         Check if response type is text
        if {[HTTP::header value Content-Type] contains "text"}{
             Replace http:// with https://
            STREAM::expression {@http://@https://@}
             Enable the stream filter for this response only
            STREAM::enable
        }
    }
    
  • So far, all our app servers can be configured or recognise via a header the fact that SSL offloading is in place. It's best to use the STREAM technique only when that's not possible.

     

    For example, Apache Tomcat has some attributes you need to add in server.xml. If the application is written correctly, adding scheme="https" attribute to the Connector node will do it.

     

    Other app servers simply recognise a header injected into the request. Check out this stack exchange question for ideas... http://stackoverflow.com/questions/16042647/whats-the-de-facto-standard-for-a-reverse-proxy-to-tell-the-backend-ssl-is-used