Full proxy not working when try to use SSL offload + HTTP-to-HTTPS redirect

Hi Kridsana,

 

If you configure the virtual server to listen on HTTPS:433 and a pool to listen on HTTP:80, then the application could be reached whenever a browser (or rich-clients) request a ressource over HTTPS:433. And the response would normally follow this path transparently in a reversed order. So far so good...

 

But if the application is not specifically designed and/or configured to support those kind of SSL-Offload scenarios, you will nevertheless experience issues which may break your application logic (best case) or silently nullify the added security of HTTPS (worst case).

 

So if the application does not explicitly support SSL-Offload the received responses may contain...

 

• Embeded HTML/CSS/JS/etc. links or embedded objects.
• Embeded HTML FORMS with based POST-backs.
• Certain server side HTTP-redirects pointing to locations
• Sensitive session cookies that are not flaged for SSL-only request.

In addition your application may also check certain client side generated information...

 

• Validate the HTTP referers, to make sure the previous request was comming from a specific sub-site
• Trigger JScripts to read and postback the location bar information.

A quick and dirty patch to solve those misdirected * request, would be to implement an iRule to transparently redirect those HTTP:80 request back to *. But unfortunately this wouldn't catch every previously mentioned problem.

 

The stuff that would raimain problematic is...

 

• Embeded HTML FORMS with based POST-backs. (can't be fixed with redirects)
• Sensitive session cookies that are not flaged for SSL-only request. (imposes a security risk)
• Validate the HTTP referer so that the previous request was comming from a specific sub-site (may break your application)
• Trigger JScript to read and postback the location bar. (may break your application)

In addition to that, the HTTP:80-to-HTTPS:443 redirection of misdirected * request, would put your HTTPS:443 site still on risk for Man-in-the-Middle attacks. In the end it would degrade the overall security back to HTTP-only. You would enable HTTPS to protect something, but the resulting security level wouldn't increase... (placebo effect)

 

To make it right, you have to either...

 

• Verify that your web application have a build-in support for SSL-Offload scenarios and that its configured propertly.

... or ...

 

• Dig into the HTTP requests and correct every reference to
• Dig into your HTML/CSS/JS/etc. and correct every reference to
• Correct the security flags of sensitive session cookies

If the outlined approaches are both not suitable, then you may have to get rid of SSL-Offloading and use a HTTPS-to-HTTPS bridging scenario, to not confuse your application and/or degrate the resulting security. This is in my opinion far better than having SSL-Offloading enabled but with broken functionalities or imposed security risks...

 

Cheers, Kai

 

Hi Kai

 

Thank you for your answer.

 

I've some question about this problem which still can't solve when perform irule HTTPS-redirect.

 

1.) From this condition, How can it can't fix with redirect? when client request HTTP form base post, it still redirect to HTTP normally, didn't it? -- Embeded HTML FORMS with based POST-backs. (can't be fixed with redirects)

 

2.) From these condition, Application server (server-side) will still receive HTTP traffic (just like when not perform SSL-offload). So how this condition may break application? -- Validate the HTTP referer so that the previous request was comming from a specific sub-site (may break your application) -- Trigger JScript to read and postback the location bar. (may break your application)

 

Thank you very much

 

I can see the whole picture now

 

Thank you very much Kai :)