Posts Tagged ‘HSTS’

HSTS RFC Finalized

Wednesday, November 21st, 2012 | Bruce Morton

HTTP Strict Transport Security (HSTS) has been finalized and published as RFC 6797.

The purpose of HSTS is to allow a website to declare to complying users’ agents that they should interact with it using a secure connection such as HTTPS.

In order to implement HSTS, a website must have a statement in its header, such as:

  • Header always set Strict-Transport-Security “max-age=31536000; includeSubDomains”

When a complying browser sees this header, it will take any insecure link and turn them into secure links. For example, http://www.example.com would be modified to https://www.example.com. If the connection cannot be secured, the browser will show an error and not allow the user to access the site.

In the above example, the maximum age for HSTS is set at 31536000 seconds (12 months). This can be changed to other periods and will keep on being updated every time the browser accesses the site.

HSTS-complying browsers include Google Chrome 4+, Firefox 4+ and Opera 12.

I would like to congratulate Jeff Hodges, Collin Jackson and Adam Barth for their work in completing this standard.

Tags: , , ,
Posted in SSL Deployment, Secure Browsing | Add Comment | No Comments »

Living with HTTPS

Friday, July 20th, 2012 | Bruce Morton

Here is a post by Adam Langley, a transport security person at Google. These were his notes before a talk that he did at HOPE9 last week. HOPE stands for Hackers on planet Earth.

Adam’s talk does not focus on CAs and certificates. His notes deal with HTTPS issues and he really pushes for the use and adoption of HSTS. This information would be good for those people that deploy SSL/HTTPS on their Web servers.

Please take a look.

Updated October 5, 2012: Adam’s presentation has been posted.

Tags: , , , ,
Posted in SSL Deployment | Add Comment | No Comments »

HSTS Update

Monday, July 16th, 2012 | Bruce Morton

HTTP Strict Transport Security (HSTS) will soon be finalized and available in an IETF standard. The request for comment (RFC) is at version 11 and the IESG has put out a last call for comments.

HSTS is a security policy mechanism where a Web server tells a supporting browser that it can only connect to it over secure connections (i.e., SSL). HSTS allows website operators to force secure connections with users that are using an HSTS-supporting browser. Supporting browsers include:  Google Chrome 4+, Firefox 4+ and Opera 12.

I have spoken about HSTS before in a previous blog post and will update again once it has been finalized.

Updated October 3, 2012: Jeff Hodges announced that HSTS has been approved by IESG as a proposed standard RFC.

Updated November 21, 2012: HSTS has been published as RFC 6797.

Tags: , , , , ,
Posted in SSL Deployment, Secure Browsing | Add Comment | No Comments »

SSL/TLS Deployment Best Practices

Tuesday, July 3rd, 2012 | Bruce Morton

SSL Labs has created an SSL/TLS Deployment Best Practices guide. The guide contains valuable information on how to deploy SSL in your environment.

The data from SSL Pulse shows us there are plenty of SSL implementations that could be executed more securely. These problems are not from the CA, the certificate, the browser or the server. These problems are from the user not deploying the server properly.

Here are some notes from the guide that could help:

I recommend the guide to help learn how you can deploy your webserver more securely.

Tags: , , ,
Posted in SSL Deployment | Add Comment | No Comments »

Public Key Pinning

Thursday, May 26th, 2011 | Bruce Morton

In the wake of the Comodo attack, the Internet industry is looking for ways to mitigate similar attacks in the future. Public key pinning may prove to be effective.

Google has developed the public key pinning concept that will debut in Chrome version 13 for most Google Internet properties (e.g., https://www.google.com).

Public key pinning means that a certification authority public key will be white-listed in the browser for a specific domain or set of domains. The white-listed public key is referred to as an HTTPS pin. If the pin is not present when browsing a protected website, then an error will occur in the browser and the requested page will not be presented.

The idea is that Google knows who it has authorized to issue its SSL certificates. If a certificate is found to be issued by another CA – even a legitimate publicly trusted CA - then the certificate will not be trusted. The result is that an unsuspecting browsing party will not be compromised with the help of a fraudulent SSL certificate.

Potential incompatibility issues with corporate man-in-the-middle (MITM) proxies, parental controls and debugging tools have been addressed by allowing user-installed CA certificates to override the pins.

Google appears to be open to offering pinning to other large, high-security websites. For others, the expectation is that pinning will be available through HTTP Strict Transport Security (HSTS). We’ll have to wait and see if other browsers will support Public Key Pinning as well.

Tags: , ,
Posted in Secure Browsing, Technical | Add Comment | No Comments »

How to Deploy HTTPS Correctly

Sunday, December 5th, 2010 | Bruce Morton

I came across ‘How to Deploy HTTPS Correctly’ written by Chris Palmer of the Electronic Frontier Foundation. Chris does a great job  explaining why web site operators should use HTTPS versus just HTTP. He points out a couple of good practices that were not previously addressed in my blog post, ‘SSL Deployment Mistakes’:

  • Scope sensitive cookies to the secure origin to avoid cookie “leak” to potentially less secure hosts in the same domain.  See another paper by Chris for more information.
  • Use HTTP Strict Transport Security (HSTS), see my blog post for more details.

Chris concludes, “HTTPS provides the baseline of safety for web application users, and there is no performance- or cost-based reason to stick with HTTP. Web application providers undermine their business models when, by continuing to use HTTP, they enable a wide range of attackers anywhere on the internet to compromise users’ information.”

I wholly endorse Chris’ recommendations and conclusions. If you are in the need of deploying HTTPS, please read his paper. Of course if you need SSL certificates, please contact Entrust.

Tags: , ,
Posted in SSL Deployment | Add Comment | No Comments »

HTTP Strict Transport Security (HSTS)

Friday, November 26th, 2010 | Bruce Morton

I recently blogged about Firesheep, the Firefox extension that can be used to compromise a secure connection to a website that you have connected to from an open Wi-Fi hotspot. The truth is the vulnerability that Firesheep exposes is not new, but little was done about it. Not so anymore, help is on the way.

HTTP Strict Transport Security (HSTS) or STS is a new security policy mechanism where a web server tells a supporting browser that it can only connect to it over secure connections (i.e. SSL). HSTS allows web site operators, serious about security, to force secure connections with users that are also serious about security (or lucky enough to have a supporting browser). HSTS is supported in Google Chrome and the Firefox extension NoScript. Firefox 4.0 will also support HSTS when it is released in early 2011.

HSTS is simple for browsers to support. When a browser connects to an HSTS site it finds a new header in an HTTPS (i.e. secure SSL conection) reply such as:

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

When the HSTS supported browser sees this, it will remember for the specified period (i.e. “max-age” in seconds) that the current domain can only be contacted over HTTPS. If the user subsequently tries to connect to the site with HTTP only, the browser will default to HTTPS. The “includeSubDomains” extension will enforce the HSTS policy on all pages under the current domain.

Now the onus is on the web site operators to configure their sites to support HSTS. Details can be found in the IETF Internet Draft specification. As more web sites adopt and more browsers support HSTS, the end users browsing experience will become a safer one.

Tags: , , , , , ,
Posted in SSL Deployment, Secure Browsing | Add Comment | No Comments »