Question about HSTS and WAF

[Ross Helfand]

Hello,

I have a bit of a strange issue.  I think I understand what is going on, but not how to fix it.

If I run my URL though SSLLabs, it tells me that Strict Transport Security (HSTS) is set to "no."

However I have enabled HSTS using a rewrite action (and I also tried binding the options to my SSL virtual server).  If I run a 'curl' to the root of my application, I don't see the HSTS headers, and I get a "403 Forbidden" response.  If I run a 'curl' to a known static image or page behind my Netscaler, I get the image and the expected 'Strict-Transport-Security' headers.

I assume what's happening is that my WAF is blocking access to "/" and therefore the rewrite action is never getting hit.  Is there a way that I can get SSLLabs to recognize HSTS?  Do I just need to set my WAF to allow access to "/"?

Thanks!

 

[Morten Kallesøe]

Why are you not allowing access to "/" - seems like a legit place to start - no?

but yes, you are right, if the rewrite policy is not hit (and therefor the action also) no HSTS headers are set.

[Ross Helfand]

3 hours ago, Morten Kallesøe said:

Why are you not allowing access to "/" - seems like a legit place to start - no?

but yes, you are right, if the rewrite policy is not hit (and therefor the action also) no HSTS headers are set.

Fair question!  This is part of our PCI environment, and we only allow access to very specific URLs.  It's been like that for longer than I've been here, so I'll need to see if it's ok to grant access to "/".

Thanks for the info!

[Nicola Campaci]

Hi 
Regardless of whether or not you should block the URL "/"
You can try removing the policy from the vserver and binding it to GLOBAL. 
Remember that if you leave the expression "TRUE" it will be applied to all VIPs so you will have to use an expression targeted to your service (e.g. hostname requested with the request)

Another test is to remove the policy from the vserver and configure HSTS using the built-in ssl settings of the vserver object or via the same settings on ssl profiles
 

add ssl vserver <vServerName> -maxage <positive_integer> -IncludeSubdomains ( YES | NO)
set ssl vserver <vServerName> -HSTS ( ENABLED | DISABLED )

OR

add ssl profile <name> -maxage <positive_integer> -IncludeSubdomains ( YES | NO )
set ssl profile <name> -HSTS ( ENABLED | DISABLED )

Reference:
https://docs.netscaler.com/en-us/citrix-adc/current-release/ssl/how-to-articles/ssl-support-for-hsts.html

Let me know if that works

[Ross Helfand]

1 hour ago, Nicola Campaci said:

You can try removing the policy from the vserver and binding it to GLOBAL. 

1 hour ago, Nicola Campaci said:

Another test is to remove the policy from the vserver and configure HSTS using the built-in ssl settings of the vserver object or via the same settings on ssl profiles

I had previously tried this second option of binding the HSTS options using the 'set ssl vserver' command, but since the WAF was blocking access to "/" the request was never able to get to the SSL vserver (basically, the same behavior as having a rewrite policy bound to the vServer).

Binding it to global was a great suggestion!  I just tried it out, and I was surprised that it didn't work.  Same behavior.  If I un-blocked access to "/" via the WAF, I was able to see the headers.

I talked to the team and we decided to just un-block access to "/" as we can't see any reason why it's blocked in the first place.  But would love to hear other suggestions if anyone has them!