Forum Discussion
Thomas_Schaefer
Nimbostratus
Nimbostratuspotential Security Issue when offloading SSL if app cannot tell request was SSL
I have seen this topic asked before (I even asked myself a few years ago), but a recent security scan has brought the issue up again.
In a scenario where the BigIP is doing the SSL handling (and termination) meaning that data to the pool member is in clear text, the application has no way to know if the data was truly SSL In the first place. The net effect is that the scanners were able to login to a form that requires SSL without using SSL. Since the app itself was not checking to see if SSL was enabled on the request, nothing stops the non-SSL request.
On an app where I control the source, this is not so bad. I have previously discussed in this forum where I set a custom header like SSL_ENABLED so the app can check to see if that header is set. I make sure this header is only set when the request was SSL and the header is stripped off if non-SSL.
The reason this has popped up again is I have a Drupal application that relies upon the Apache variable HTTPS. This check is built into a standard module so it is a bit hard to change and I really hate to ask the user base to make special consideration since we are running on a BigIP.
I submit there has to be a way that we can force the app to recognize the offloaded SSL request as having been SSL. I had thought of a custom Apache module to look at our header and set HTTPS in Apache, but what about IIS, etc. I do of course realize that we could enable the SSL to the server but that defeats the purpose of SSL acceleration.
The reason I used the alarmist headline on this post is that I suspect with sites that are performing SSL acceleration, the dirty little secret of SSL acceleration is that unless each app does something similar to what has been described here, a user could be duped into using a login form without SSL when the webpage expected SSL.If users on this site are writing applications that use SSL acceleration, then the backend apps have a flaw UNLESS the BigIP also has a list of the URLs that REQUIRE and they enforce it in an iRule. It would seem to me that this could be handled in a more streamlined fashion when the SSL profile is added so this important step is not overlooked. Without adding some way to check the form was originally secure, the app is exposing the user to revealing personal information.
Thoughts?
Thanks,
Tom Schaefer
hoolioCirrostratus
Hi Tom,
a user could be duped into using a login form without SSL when the webpage expected SSL
If an attacker could force a client to submit login credentials unencrypted to the legitimate site, having LTM redirect the request to HTTPS wouldn't help much. The victim would have already submitted their credentials in cleartext. Also, if an attacker could force the client to make a request, why wouldn't they send the client to their attacker site and steal the credentials that way?
That said, I think you've covered a lot of the answers to your points. For customizable applications, it's ideal if you can configure/re-code them to read a custom HTTP header indicating whether the front end connection was encrypted. For apps which this isn't possible for, here are a few options I can think of:
- encrypt all of the client to VS traffic
- re-encrypt the serverside connection
- move all of the content which needs to have clientside encryption enabled for into specific directories and then use an iRule to enforce any request to those specific directories is encrypted. This doesn't solve the issue of sensitive data being sent via cleartext traffic if an attacker forces the client to make a request though.
Here is a post with some related info and links:
http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&postid=1170635&ptarget=1170636
Aaron