Strict Transport Security (STS, sometimes HSTS for HTTP Strict Transport Security) is a novel protocol complement to https that allows a website owner to make https the only method that the browser may use for accessing the site. Also, it enforces certificate integrity. This post shows how the extensible architecture of Citrix NetScaler makes adding this feature to a NetScaler-deployed site a piece of cake. Even this new feature is just a few commands or clicks away (probably) without even having to update the software.
Many Internet services from private on-line banking to accessing corporate websites or even XenDesktop infrastructure relie on the web browser’s SSL/TLS security. While this stack of security protocols is – with reasonable settings – widely believed to do what it’s supposed to do, it is the user that facilitates the following attack scenario:
Let’s assume a user – let’s call him Alex – wants to (securely) access the web site of his bank (Bob’s Bank) from his notebook sitting on a park bench tuned into the public hot spot at his favorite coffee dealer nearby. He loves the full 5 bars of signal strength (even when he touches the display with his left hand) and is enjoying a bottle of lemonade he has brought from home. Let’s further assume that the computer is uncompromised. He has his credentials ready and knows that the banking portal of the bank is at www.bank.foo. Eagerly he is launching his web browser and typing away at the URL. He hits enter and the following things may happen.
In a perfect world, the browser is assuming that the method of access to this site should be http as is true for most public web sites in the Internet. Thus it resolves the name www.bank.foo to an IP address – say 198.51.100.17 and opens a connection to port 80 on this box. Also, it assumes that the user wants the root document and issues a GET / via http. The bank – being security aware – knows that banking transaction should be secured by SSL. Thus, they have implemented a so-called http redirect telling the web browser that he should proceed to https://www.bank.foo/ to get what it desires. It follows the redirect and contacts the same IP on the https standard port. There the web server begins the SSL handshake and presents its server certificate that states he is correctly impersonating www.bank.foo with a third party certificate authority (CA) vouching for it by signing the certificate. The browser cryptographically checks if this an organization it trusts and since this is the case Alex can proceeds transacting his millions. The grass is green and the birds are singing and he’ll be living happily ever after.
Not so fast!
Attack Scenario 1
On another bench behind a tree, evil Chuck is operating his notebook that is connected to the Internet using a 3G connection. His wireless is in Access Point mode and he is using the WLAN identifier CAFFEINE. Evil Chuck is working for Alex’s soon-to-be-divorced wife Eve who is suspecting that Alex has money he hasn’t told her about. Since Alex has logged into his system believing it to be the caffeine dealer’s he is also sending its request for resolving www.bank.foo to Chuck’s computer who is sending him to his own server at 203.0.113.7. From an earlier sniffing attack he knows that Alex is contacting www.bank.foo from time to time and is eager to find what he is doing there. Thus, he registered the URL www.blank.foo at a popular CA and he has downloaded the bank’s login page to his own server that Alex has been lead to. Contacting the unauthenticated port 80 as in the perfect world, Chuck is redirecting the request to https://www.blank.foo/ resolving to the same server and presenting the correct certificate matching the name redirected to and signed by a CA trusted by the browser. Also, Alex is presented with the familiar bank logo. He doesn’t notice the slight change in the URL name and – as Steve would put it – BOOM – provides his credentials to Chuck who shuts down his access point and makes nice screen shots of Alex’s account balances. Alex who has lost connectivity is swearing loudly but decides not to complain since he did not actually pay for the service. Interestingly, his divorce does not take the financial outcome that he had hoped for….
Analysis: While this example is a targeted attack, it is not at all unlikely. Assume that an attacker is not impersonating an AP but ARP spoofing it’s IP address or by hacking the DNS server of a popular ISP. Whenever a user is contacting an http address of a given web site, say your favorite book retailer, he redirects to a site that tries to steal user credentials and sells them on the black market for a couple of Euros. The only mistakes Alex is guilty of is not using https:// in the first place and in the second step not detecting that the URL is not exactly the one he wanted to access.
Attack Scenario 2
Let’s assume he read this bog entry until here and was typing https://www.bank.foo/ into the browser. Again, he is de facto connected to Bob’s server, this time serving a www.bank.foo certificate. Since bank.foo is owned by named organization he created a CA for himself and used it to ascertain he is the owner of this domain. However, since SSL is such a fancy protocol, the browser immediately detects it doesn’t trust Chuck’s CA and notifies the server. Usually a pop-up pops up, broken padlocks are displayed – Google Chrome even displays a jolly roger next to the crossed out https symbol. However, since the browser is just a tool, it politely asks Alex if wants to override this warning…
Since Alex is a Facebook black belt and is followed by 327 people on Twitter he is pretty sure he knows what he is doing. Also, he has seen this message many times and has clicked it away just as many time without every having problems. Thus, he clicks away the warning, again feeding his creds to Chuck with a similar outcome.
Analysis: This scenario is far more likely since it does not require a correctly registered domain. Also, users are usually trained to click away messages to get what they want. Even if newer browsers really make it tough to do so.
How does Strict Transport Security address that?
What if the browser would have a list of sites that it knows can only be validly accessed via SSL and that every unencrypted attempt is as incorrect as any attempt that raises an SSL warning? If www.bank.foo would be in the list of sites with “Strict Transport Security” – a recent IETF proposal – entering www.bank.foo or even http://www.bank.foo into the URL field would result in the browser correctly translating to https completely avoiding attack scenario 1. In case of scenario 2 the browser would not present Alex with a way to suppress the warning since it knows that no matter how much Alex knows, the real owners of the web server know even more, avoiding scenario 2.
This list and how to deploy it is the core of Strict Transport Security that is a new browser feature as of e.g. FireFox 4 and recently released Google Chrome builds. The owner of a site can ask the browser manufacturer to deliver the browser with the name of his site in the STS list resulting in the behavior described above. While this is ultimately the most secure it has the drawback that the browser guys have to make sure they are talking to the real owner to avoid annoying site owners that do not have Citrix NetScaler and thus think that SSL will put too much of a strain on their web servers. The second method is a little less secure but so cool it hurts not having had that idea myself.
It works as outlined here and depicted below: A given https site with a valid certificate adds a header called Strict-Transport-Security to its http response headers. The value of the header is a number that denotes the maximum time in seconds that a browser keeps this site in the list of STS sites – measured from the last access.
Isn’t this cool? If bank would have had that header set with an expiry to say 10 years and what if Alex would have made his first run to this URL in an uncompromised environment? Then his browser would have kept the info about how to access and what never to accept when talking to bank. In this case, Alex’s secrets would have been safe. No matter how desperately he would have wanted access, his browser wouldn’t have allowed him to give away his credentials. The attack vector would be limited to the first connection.
How can this be used with Citrix NetScaler?
First, with a NetScaler Application Switch adding SSL to your site is a no-brainer since it can not only handle the certificate management for your web server farm but also keep away the resource-intensive computations from your valuable back ends. Also, it is capable of handling http completely with its Policy Engine making it the Swiss army knife of application delivery.
To prove my point, the following three configuration lines are all it takes to have a Strict-Transport-Security Header on all your sites running on port 443.
First, we create a so-called action, i.e. the operation that we want to perform on the http responses selected. Here, it is of the type that inserts a header which makes sense because we want to insert a header.
add rewrite action insert_STS_header insert_http_header Strict-Transport-Security "\"max-age=157680000\""
The parameter is approx. 5 years, expressed as seconds. That means that only if the time between consecutive accesses is more than 5 years, http would be considered as a correct way of access.
Second, we create a policy which is acting as a selector for the action that we have created above. The logic we’ll apply here is simply “do it for whichever objects we bind this policy to”, equivalent to the Boolean “true” which is – who would have guessed – “true” in the advanced policy syntax.
add rewrite policy enforce_STS "true" insert_STS_header
The third and last step is binding the policy. Typically, this is done for virtual server objects of type SSL (which is de facto the NetScaler lingo for https), because the Strict Transport Security IETF draft advises that the header should be only used on https connections (this makes sense because only the browser is sure that he is talking to the site owner he should restrict communication to it). Assuming we have a virtual server called vs1 the binding would be typically done as follows:
bind lb vserver vs1 -policyName enforce_STS -priority 100 -gotoPriorityExpression END -type RESPONSE
To secure an Access Gateway vserver that do not support the binding of rewrite rules, the rule has to be bound locally. To avoid STS headers to be injected in all http traffic passing through the box, I recommend changing the selector to port 443 traffic on the Access Gateway vserver. Assuming it runs on 198.51.100.17, the logic would be
add rewrite policy enforce_STS "client.IP.DST.EQ(198.51.100.17) && client.tcp.DSTPORT.EQ(443)" insert_STS_header
bind rewrite global enforce_STS 100 END -type RES_OVERRIDE
So, what do we do with our (legacy ) port 80? The IETF draft recommends a http 301 redirect to the https version of the site. This can be accomplished by implementing http://support.citrix.com/article/CTX115747 . Please be aware that this is actually better than the standard NS redirects that tend to be 302s which only means “moved temporarily”. Assuming that the port 80 vserver is called vs2, the rules to do this would be
add responder action 301redirect respondwith "\"HTTP/1.1 301 Moved Permanently\r\nLocation: https://www.bank.foo\r\n\r\n\""
add responder policy always_301redir true 301redirect
bind lb vserver vs2 -policyName always_redir -priority 100 -gotoPriorityExpression END
Believe me, this is not a secret hacker feature and can also be accomplished using our excellent GUI. Even His Majesty Steve would be impressed of how easy our GUI guides you through the process of creating these rules. The sky is the limit here. An idea that might make sense in certain environments could be to detect browsers that do not incorporate the STS feature (as of today anything but FireFox/4 and a current Chrome build (at least version 6). For the old browsers I’d display a page educating the users about browser security basics, not to click away warnings etc. The new ones get the redirect and live happily ever after.
Still, it is important to know that there are some things in modern browsers that should IMHO still improve.
- There should be system wide STS store to stop users from changing the browser if they get a warning.
- The process of registering STS URLs for browser predeployment could be automatized, e.g. google could easily “write down” the STS header when crawling the web. This information could be used to be fed automatically into the browser teams.
- What is still very bad are the error messages the user gets. This also holds true for user certificate errors. For the common user, these messages look equivalent to provider problems which is not how it should be.
The most important measure to be taken is better user education. I know that cloud service providers and even banks are reluctant to do so because it is against the “ease of use” aura that they’d like these services to have. However, STS is giving you an additional piece of automated security. If you have a NetScaler with just a few configuration steps.