Google has made accessing www.google.com a little more secure by turning on HSTS (HTTP Strict Transport Security).
With HSTS, Google ensures its servers are telling browsers that all future attempts to connect should be over HTTPS, Jay Brown, senior technical program manager of security at Google, wrote on the Google Security blog .
When the user connects to a site for the first time, it typically uses a regular connection. Even if users don't manually type http:// in the address bar, browsers tend to treat the address as going over HTTP. The server can be configured to redirect to HTTPS, but the initial communication over HTTP happens every time the user attempts to connect.
The HSTS header is an effective tool for protecting user and data privacy -- if the network attacker tries to use a man-in-the-middle attack to serve up an insecure page for a URL the user has accessed before (such as a banking site), the browser will not attempt the connection.
For example, the user may enter a URL in the address bar, at which point the browser makes the request to the server over HTTP. If the site is a HTTPS site, the server would respond with an HTTP 301 "Moved Permanently," at which point the browser will make the request again, this time securely. A rogue network actor monitoring this transaction could then step in and serve up a phishing page, and victims will not realize it was fraudulent because the URL bar is correct. But if the site has HSTS and the user has accessed the page before, the browser won't make the HTTP request and instead will go with HTTPS.
The HSTS header has some limitations. There is a max-age value that specifies the time period during which the browser should attempt secure connections. After the period has passed, the next time the user accesses the site, the connection is initially over HTTP, then the HSTS header clock starts again and forces the browser to use HTTPS for all future attempts.
HSTS also cannot enforce secure connections until the user attempts to connect that first time; otherwise the browser doesn't know there is an HSTS header from the host.
For initial launch, google.com 's header has a max-age value of one day. The short duration helps mitigate the risk of any problems that may arise during the rollout. The goal is to eventually increase the time period over the next few months to at least a year. Google plans to roll out HSTS for other domains and products over the next several months as well.
If for whatever reason the site changes and the secure connection is no longer possible, users would be unable to access the site until the time period has elapsed because the header won't let the browser load the page over a regular connection. The problem with such a short period, however, is that there are more "initial" attempts, and more times the page is served insecurely.
Ordinarily, implementing HSTS for a domain is "a relatively basic process," but there were challenges, such as pages with mixed content -- some secure elements on the same page as insecure elements -- bad HREF tags, redirects to HTTP, and other issues, such as updating legacy services. The team accidentally broke Santa Tracker shortly before Christmas 2015 implementing HSTS. "We fixed it before Santa and his reindeer made their trip," Brown said.
Google has been working on encrypting all its data communications in transit. It switched the search page to HTTPS and encrypted communications between its datacenters. Shortly after the documents leaked by Edward Snowden showed the National Security Agency monitoring traffic within the datacenters, the company encrypted all traffic within the datacenters as well.
"We've worked to increase the use of encryption between our users and Google," Brown said. "Today, the vast majority of these connections are encrypted, and our work continues on this effort."