Sophos Cloud Optix
Although the Firefox team has an entire page on the mozilla.com website dedicated to the new security features in Firefox 4, they seem to have forgotten to mention HTTP Strict Transport Security (HSTS).
While HSTS may not be the sexiest security feature for the average Joe, I was thrilled to see it implemented in the world’s second most popular browser. Google Chrome has supported HSTS since September, 2009 in versions 4.0.211.0 and higher.
What is HSTS? Currently it is a draft RFC that tries to address some of the insecurities present in the HTTPS specification.
The easiest way to describe the core idea is that it allows a website operator to describe how they want the use of SSL to be handled for their domain. Supporting web browsers will honor HTTP headers and ensure this security policy is applied.
As an example, paypal.com has elected to use HSTS headers on their service. The first time you visit http://www.paypal.com from a compliant browser, your browser will receive a header that explains that PayPal should only be accessed via HTTPS and that any browser certificate errors should not allow the user to override them.
When specifying this header the website can also specify a Time To Live (TTL). This allows the updating of security certificates and changes in certificate authorities without a denial of service.
After receiving this header, if you try to surf to http://paypal.com, your browser will automatically intercept the request and not send anything unencrypted across your network connection so long as you visit the site before the TTL expires. It will reformat your request to HTTPS and only communicate over SSL/TLS with PayPal.
The second important action is the ability for sites to not allow you to override certificate errors. We have mentioned previously the tendency for every day internet users to click yes/accept/ok to any prompt that is presented.
Online banking sites, financial sites or even Facebook and GMail now have the option to not only enforce HTTPS for users of compliant browsers, but also limit the ability for users to harm themselves through a lack of understanding of technical warnings.
I hope that Microsoft and Apple adopt this draft standard sooner rather than later to provide security for nearly all web surfers. While it has not yet been ratified, this proposal has my support and can make the web a safer place.
My org inspects HTTPS before we allow users to see the content. Obviously done using MIM techniques at the security boundary. I suspect we’d prefer a non compliant browser, or else we’d use compliant browsers to better secure internal transactions, but would want to modify the HTTP headers for Internet based sites to ensure SSL inspection could still take place. HSTS sounds like a bit of a dream for hackers to better get their malware into orgs. ps isn’t Mutual TLS just as effective??
If your solution (like our Sophos Web Appliance) is not actually performing a man-in-the-middle trying to masquarade as the original CA, but is a trusted authority for your clients then this still works fine. The self-signed certificate that is intercepting HTTPS and inspecting it simply must be trusted by the client.
I still waiting for the new SSL stuff to finally be implemented. The standard that allows a normal HTTP connection to be renegotiated to SSL after some headers have been sent.
This would allow SSL vhosts on a single IP to be used and it would remove the biggest hurdle to the whole world using SSL for normal browsing…
"The first time you visit http://www.paypal.com …"
I thought HSTS headers could only be sent over an HTTPS connection? Otherwise, a MITM attack could specify HSTS for a host that doesn't support SSL, resulting in a DoS.
Correct, when you visit http://paypal.com you are redirected to https://paypal.com which sets the header. Thanks for clarifying.
"your browser will automatically intercept the request and not send anything unencrypted across your network connection"
Tricky statement. When I looked at the HTTPS Everywhere extension from EFF for Firefox, and tried to find comparable extensions or plug-ins for other browsers, it seems that nearly all major browsers reject pre-fetching interception and rewriting of URLs. Thus, if you use Chrome or Safari, any HTTPS force option there will allow a user to visit the unencrypted site first (if that's the URL they provide), at which point any valid tokens in cookies are sent in the clear before a redirect happens to the secure site.
I should go read the HSTS spec, but it seems like there would have to be a commitment from sites to not write tokens into cookies on non-secure versions of their sites if they want users to rely on SSL/TLS. Or the implementation of HSTS should perform a head request before sending cookies on the first visit within a period of time to determine whether the full request should be sent.
Has this been considered here?
A relatively new extension for Firefox called HTTPtoHTTPS can be used in addition HTTPS Everywhere. I just used it on this site and with Waterfox, and it locked the site (with no restart), affording AES-256 encryption. It can be found here: https://addons.mozilla.org/en-US/firefox/addon/httptohttps/?src=api
Any idea if safari browser for iPad and iPhone running iOS 11.2.6 support this? Paypal safer to use I feel if run as a dedicated smartphone app rather than a browser website since the app can be verified by the App Store operator
As far as I know, Safari on iOS supports HSTS but I haven’t actually verified this myself through testing…
…anyone got the evidence of their own eyes for this?