Monthly Archives: September 2015

HTTP Strict Transport Security (HSTS): Overview

A while back I asked the question “Is HTTP being left behind for HTTPS?”. If you are looking to make the move to an HTTPS only web space one of the settings you can configure is HTTP Strict Transport Security, or HSTS. The idea behind HSTS is that it will tell the browser to only communicate with the web site over a secure channel. Even if the user attempts to switch to HTTP, the browser will make the change before it even sends the request.

HSTS is implemented as a response header with a few options shown in the below example:

Strict-Transport-Security: max-age=31536000; includeSubDomains

In the example above, the max-age (required) is specified in seconds ( a year in this case) and indicates how long the browser should remember this setting. Setting a max-age of 0 will tell the browser to stop enforcing HSTS for the domain.

The includeSubDomains is optional and indicates if HSTS should be enforced an all of the sub domains as well.

You might wonder why this is needed when a user can just go to the HTTPS version of a site. If you watch most users, I am guilty of this myself, they just type the domain of the site they are going to. For example, I might just type developsec.com into the browser. With no indication of which protocol I want to use, the browser will start with HTTP and then the server may respond to switch it to HTTPS. With HSTS enabled, the goal is when a user types http://www.developsec.com or www.developsec.com into the URL, the browser will make the switch automatically.

There are some considerations for this to work as expected. The response header is not respected until the first time you visit the domain using HTTPS with a trusted certificate. Until this happens the browser doesn’t know not to use HTTP. There is a way around this by signing your domain up on the preload list. The preload list can be used by browsers to find out about your domain’s HSTS status before accessing the site. The linked site shows what needs to be done to be allowed on the preload list. Both with the preload list and support for HSTS in general, your browser has the final say. For a list of browsers that support HSTS you can go to the OWASP site.

Self Signed Certificates
One of the security features of HSTS is that tries to block man in the middle (MitM) type of attacks. An attack where your traffic is redirected through an attacker so they can view your data. To do this, HSTS requires the certificate to be a trusted certificate. If it is not a trusted certificate, for example a self-signed one, then you will see the following image indicating it cannot connect:

Hsts1

You may notice that this looks very similar to when you try to connect to a site with a certificate issue with one major difference. There is no way to allow the exception. For testers that use a proxy, such as Burp Suite, you can tell your browser to trust the certificate generated from the proxy tool and it should work just fine.

If you are working toward implementing this feature, make sure you perform appropriate testing to make sure it is working properly. If you use the “includeSubDomains” setting make sure your test environments are using SSL or you may have some trouble shooting to do during testing. If your site is HTTPS only, this is a great feature to add to make sure that your users are only making requests over HTTPS. Hopefully the links included will provide any other information you may need on HSTS.

HIV clinic Data Breach: Thoughts and Takeaways

One of the most common ways for sensitive information to be released outside of an authorized environment is by simple, common mistakes made by employees. These types of incidents usually have no malicious intent and are generally innocent in nature. An example of this was recently reported regarding a newsletter that was sent out to HIV patients (and others) that the sender made a simple mistake. Rather than use the BCC for each recipients address, they used the CC field. For those that may not realize, you don’t see the users listed as BCC (blind carbon copy), as opposed to the CC field which is shown to all recipients.

Think about any mass emails you may be a part of and which ones use the CC field instead of the BCC field. I have a few that I am on that share my information with the rest of the list. In many cases, this may not be that big of a concern, but in a health related situation like this one, it becomes more severe. The issue becomes a privacy and compliance issue as it deals with HIPAA and personal health information.

Is the solution as straight forward and simple as creating a procedural check list to ensure that BCC is used instead of CC? This may work, but it still opens up the opportunity for someone on a tight deadline to skip the checklist and make the same mistake gain. We are all aware that after an incident we will be more aware, but as time goes on that awareness slips to the way side.

A company could engage a 3rd party mailer, like MailChimp, to do their newsletter mailings. This route raises different concerns because you are placing your critical or private data, the patients related to the health issue, in the hands of a 3rd party. If that vendor suffers a breach you will incur some risk there as well. Different vendors have different policies and security practices, so if you are thinking about taking that option make sure you understand what is and is not offered.

There may be add-ons for your mail program that can help send newsletters individually, rather than as a bulk email. One such solution for Microsoft Outlook is Send Individually created by Sperry Software. (Full disclosure, I used to work with Sperry Software, but I am not compensated by mentioning their product. I am not a reseller nor do I have any affiliation at this time) There may be other add-ins by other vendors that can do this as well.

Whichever direction you go, make sure that you are reviewing your processes and the risks they expose. This type of human error is easy to make, but quick to be crucified. Don’t cut corners due to quick timelines and have another person review before sending anything externally. Sometimes that second pair of eyes can catch the simplest of mistakes that are so easily overlooked by the original writer. It is important that we take time to understand these situations and learn from them. Attention to detail can save a lot of hassle in the future.