https connections become http - how to secure it?

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.