Forum Discussion

meena_60183's avatar
meena_60183
Icon for Nimbostratus rankNimbostratus
Sep 21, 2008

https connections become http - how to secure it?

I have SSL termination configured for a virtual server. The backend connection to the server is a http (clear text) connection.

 

 

In my case, the server is perforimg an http 300-series redirect to another http URL. This redirect is causing the client to perform an http request even though the client performed an https request initially. I want all client connections to be SSL.

 

 

In Cisco world, I configure an URL rewrite so that all http connections will be rewritten as https connections.

 

 

I do not know how to this on F5 and please let me know how I can secure these redirect URLs?

 

 

thanks,

 

Meena

6 Replies

  • I think I found the answer in the following link

     

     

    https://support.f5.com/kb/en-us/solutions/public/6000/900/sol6912.html

     

     

    On the packet capture, I am seeing http GET requests but the application data is encrypted.

     

     

    Meena
  • When I examined the packet capture closely, I see http POST messages with clear text that contains the username and password for a login.

     

     

    This is after applying "redirect rewrite" to all.

     

     

    Meena
  • Hi Meena,

     

     

    You've done some nice research...

     

     

    Can you use a browser plugin like Fiddler for IE or LiveHttpHeaders (and viewing the page source) for Firefox to check how the client is getting directed to make a request via HTTP? It might be a 30x redirect or it could be content within the payload.

     

     

    If it's a redirect in the response headers using rewrite redirects or an iRule. If that's not working, the HTTP reference might be in the payload. If that's the case, you could rewrite the HTTP reference to HTTPS using a stream profile and iRule. Take a look at the STREAM::expression wiki page (Click here) for examples.

     

     

    Aaron
  • OK. That was very useful to use LiveHTTPHeaders. I found out the HTTP references are made in the payload. Even though the response from F5 was a 302 redirect ( I enabled http to https redirection on the F5), it was too late for the POST messages since the username and password is already sent in clear text.

     

     

    I looked at the STREAM example and I think I have some idea on how to do it, but it seems like each HTTP reference needs to be handled separately. is this correct or did I misunderstand it?

     

     

    thanks,

     

    Meena
  • You can configure the STREAM::expression to replace every reference to http:// with https://, or you can do a more specific search/replace using a regex. If neither of those two options work for you, you can set a stream expression to match all http:// references and then add a test in the STREAM_MATCHED event to determine whether to replace that particular match with https://. There are examples of each case on the stream expressio wiki page.

     

     

    If you have some anonymized examples of URLs you do and don't want to replace in the payload post it here and I can try to help with more examples.

     

     

    Aaron
  • Besides trying to have the BigIP deal with it entirely on its own you need to be aware of the applications behind it. These applications need to know they're sitting in a reverse proxy/ssl proxy configuration, so that they can return back the correct URLs when redirecting. For example, I recently went through this with SiteMinder, Apache and WebSphere Application Server (WAS).

     

     

    SiteMinder redirects out to an authentication server where the 302 location URL contains the loginserver and URL encoded parameter called TARGET which is the URL back to the application/webserver. SiteMinder uses the 'httpsports' config param and one other hostfromheader or somethign like that. When SiteMinder redirects it will use the HOST header for the port number and the protocol part of the URL will be dermined by the same. So if httpsports="5643", then if the host header has 5643 then SiteMinder will ensure that https is put on any redirects or re-authentication directives.

     

     

    WAS and Apache both have "/" trailing slash redirects. Apache can be configured using mod_rewrite to avoid this, but not if content is served from the App Server and the WebSphere plugin is used. In this case the server must be configured with a custom property called HttpsIndicatorHeader (http://publib.boulder.ibm.com/infocenter/wsdoc400/v6r0/index.jsp?topic=/com.ibm.websphere.iseries.doc/info/ae/ae/uweb_custom_settings.html).

     

     

    Both SiteMinder and WAS required BigIP work. For SiteMinder our SSL VIPS required an iRule to modify the HOST header and stick :443 on it. For WAS, we added an http header to match the HttpsIndicatorHeader property.

     

     

    I hope this helps. Just double check with your applications because they can redirect without 302s or hand back to the browser urls back into your system that you're not accounting for.