Forum Discussion
goyogi
Nimbostratus
NimbostratusSSL verification
We do SSL offloading on the LTM but some of our sites are built to detect if the connection is coming in encrypted or not. We would rather not re-encrypt it back to the server for several reasons. I was wondering if there is an industry standard or best practice to inject something into the header that would tell the server this come in securely? Something standard similar to XFF?
The application is .asp and they are using SERVER_PORT_SECURE currently.
http://www.w3schools.com/asp/coll_servervariables.asp
Thank you for your advice!
mazek_59373I just put additional header in each decrypted request, sth like "X-HTTPS: 1". You might want to remove that header before You put Yours to avoid double X-HTTPS headers after appending Yours.
maz
hoolioCirrostratus
Maz's suggestion is a nice simple one. If you configure a custom HTTP header with the header to remove set to 'X-HTTPS' and the header to insert as 'X-HTTPS: 1' you can prevent someone from inserting their own X-HTTPS header and do this without an iRule.
Aaron
Justinian_48178Would you guys do this through a custom iRule or by custom http profile(s)? We currently inject FRONT-END-HTTPS: on for our secure sites, but we found out that if the client injects that header, we accept it and send them as if they are secure.
For the simple test we did we were able to get around that issue by creating a non-secure http profile that removed the header, and a secure http profile that added the header. We then built two virtual servers and applied the appropriate rule to each VS (port 80 and 443). Is this what everyone else is doing, or are you guys building a iRule to detect it being sent from the client before injecting it to the server?- hoolioYour method is what I would have done. Using two custom HTTP profiles--one for HTTP which removes the header and one for HTTPS that removes and then inserts the header--should be the most efficient way to handle the scenario.
Aaron