Forum Discussion

kridsana_52318's avatar
kridsana_52318
Icon for Nimbostratus rankNimbostratus
Jan 15, 2016

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

Hi Everyone

 

I've some question about Full proxy with SSL offload.

 

My scenario is I've web application which run on port 80. And then I try to make it to HTTPS for all path by using F5 LTM policie which redirect all HTTP request to HTTPS and perform SSL offload.

 

Problem is application doesn't working properly after do that. I'm not sure why it's not working.

 

From concept of Full proxy, This should working with no problem because F5 have isolate client-side and server-side (server-side still send traffic on port 80) . At first I think it due to HTML hardcode on application but it's not correct due to F5 still send traffic on port 80 the same as before.

 

Is there any concern when using HTTP-to-HTTPS redirect + SSL offload ?

 

Thank you

 

  • 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 :)