Google is adding HTTP Strict Transport Security (or HSTS) to the Google.com domain, an extra layer of protection that prevents visitors from using a less secure HTTP connection.
By using HSTS, visitors following HTTP links to Google.com will be automatically redirected to the more secure HTTPS version of the Google domain. The effort, announced Friday, is meant to protect against protocol downgrade attacks, session hijacking and man-in-the-middle attacks that exploit insecure web connections.
“HSTS prevents people from accidentally navigating to HTTP URLs by automatically converting insecure HTTP URLs into secure HTTPS URLs. Users might navigate to these HTTP URLs by manually typing a protocol-less or HTTP URL in the address bar, or by following HTTP links from other websites,” wrote Jay Brown, a senior technical program manager for security at Google in blog post on Friday.
The HSTS mechanism ensures that if their is an HTTPS connection the browser will use it. If no HTTPS version of the site is available the less secure HTTP version of the site is still available.
The introduction of HSTS impacts traffic not only to the Google search engine, but it will also secure traffic to other Google services that use the Google.com domain such as Google Alerts, Analytics and Maps. Google has already added HSTS to its YouTube service.
Google has been a staunch supporter of HTTPS and has rolled out support for HTTPS encrypted communications across a large swath of its internet properties under the banner of its HTTPS everywhere initiative, announced at Google I/O in 2014. Much like the HTTPS initiative, many within the security industry have been advocating for more websites to implement HSTS such as the Electronic Frontier Foundation.
“Without HSTS, browsers have no way of knowing that a website should be delivered securely, and so cannot alert you when a website that ought to be loaded securely (e.g. your bank’s website) is instead loaded via a normal connection (i.e. the unencrypted version the attacker sends to you instead),” wrote Jeremy Gillula, senior staff technologist at the EFF. HSTS solves the problem and instructs the servers to send a message to the browser to request the encrypted version of the web page.
While the HSTS security policy was proposed in 2012 within the Internet Engineering Task Force it has taken years to get the support of major websites and browser companies and to work the kinks out of its implementation. Today, baked into Chrome, Safari, Firefox, Edge and IE 11 is support for HSTS. However, some Google-owned domains and many other non-Google sites concede flipping the switch on HSTS support isn’t as simple as they would like because of issues surrounding sites that contain mixed content, bad HREFs, and redirects to HTTP.
Google blamed a less than perfect implementation of HSTS for breaking its widely popular Santa Tracker website just before Christmas in 2015.
“We’ve turned on HSTS for www.google.com, but some work remains on our deployment checklist,” Brown wrote. “In the immediate term, we’re focused on increasing the duration that the header is active (‘max-age’). We’ve initially set the header’s max-age to one day; the short duration helps mitigate the risk of any potential problems with this roll-out.”
In other implementations of HSTS, the duration can be much longer (up to a year). As security expert Troy Hunt, creator of the cyber-breach service Have I Been Pwned? and author at Pluralsight points out in a blog post regarding HSTS:
“Once this header is returned by the site, the browser will not make an HTTP request to the site no matter how hard you try and instead it’ll do (return a) 307 (redirect error). It’ll do that for the number of seconds described in the “max-age” attribute (that 315… value is one year in seconds) after which the browser could make an insecure request… until the response header is set again the next time the above process is repeated.”
