A lot of hours go into debugging the cause of and tweaking the HTTPS error warnings that pop up in Google’s Chrome browser.
Researchers from Google, Purdue University, the International Institute of Information Technology Hyderabad, and the Leibniz University of Hanover Germany have spent the last several years combing through 2,000 error reports, synthesized from more than 300 million errors that Google Chrome users encountered, to better classify certificate error warnings.
The goal of the researchers, which include Google’s Emily Stark, Adrienne Porter Felt, and Ryan Sleevi, to name a few, was to identify the source of the error messages in hopes of improving user experience. Ideally the objective of the project was to craft a more actionable HTTPS warning, something that would decrease the likeliness of either scaring a user or causing a user to blow through them.
The researchers published their findings in a paper, “Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors” (.PDF) last Friday and plan to present it at a conference, the 24th ACM Conference on Computer and Communications Security (CCS) in Dallas, Tex., at the end of October.
https://twitter.com/__apf__/status/908780673137205248
our CCS cert errors paper is up!!! https://t.co/CgMMviYOzN (cc @meacer @__apf__ @laparisa @sleevi_)
— Emily Stark (@estark37) September 15, 2017
Many of the errors, the researchers found, stemmed from client-side or network issues.
“Prior work emphasized the role of developers in HTTPS errors,” the researchers write, “however, we find that client and network problems are at least as influential as server misconfigurations. Of the reports that we can automatically classify, half are server errors (31.2% of all reports) and half are client or network errors (31.6% of all reports). Per a manual review, the unclassified reports are even more weighted towards non-server errors.”
Captive portal errors, which can cause name mismatch errors when users connect to certain networks—airports, hotels, and the like—were responsible for a chunk of them.
The researchers say that Chrome now displays a special captive portal error UI message instead of a security warning in hopes of better informing users. It also maintains a list of “candidate captive portal certificates” it ships with Chrome’s developer channel to supplement captive portal detection.
Misconfigured client clocks on Windows machines led to a surprisingly high number of what the researchers called “spurious warnings” too. 33.5 percent of certificate warnings were caused by a user’s local system clock being set incorrectly. If a clock is set to the future it could make it appear to Google that the user is using an expired certificate.
Chrome now combats clock errors by displaying a special warning to users – a red clock above the words “Your clock is ahead.” To prevent malware authors from changing a users clock – Google made it so users can’t click through to sites that display the warning.
“To improve client clock error detection, we implemented a secure time service that Chrome queries when it encounters a certificate date error. Upon encountering a certificate with invalid dates, Chrome queries an update server for the current time (an HTTP URL, with the response signed by the private key corresponding to a public key baked into Chrome), and delays showing a warning for up to three seconds. If the query returns within three seconds and indicates a timestamp that is significantly skewed from the local system clock, then Chrome shows the clock warning,” the researchers wrote.
The researchers say the company has recently made tweaks to how Chrome for Android works to address insufficient intermediates, a big culprit – 36 percent—of certificate warnings on Android. Insufficient intermediate errors occur when a client can’t build a valid chain because a server failed to include the correct certificates. Google added something called Authority Information Access, or AIA fetching in Chrome 58 to fix the issue.
“When the platform certificate verifier returns an authority invalid error, Chrome looks at the last certificate for which there is no issuer in the server-sent chain. If this certificate has an AIA URL, Chrome fetches it and again attempts a platform certificate verification. If it again fails, Chrome repeats the process, until a valid certificate chain has been found or until exhausting a maximum number of fetches.”
The process has helped eradicate certificate errors. Researchers claim that since they implemented it back in May with Chrome 58, cert. errors caused by missing intermediates declined in August from 36 percent to just three percent.
Researchers with the company have taken multiple steps over the past several years to refine the warnings users see in Chrome. In 2014 Chrome debuted a red screen when Google believed there was malware or phishing on the other side of warnings. In 2015 Chrome dumbed down warnings and simply began telling users “Your connection is not private,” in red letters on a grey background with a red padlock with an ‘X’ on it.
In just a few weeks Chrome will mark HTTP pages that ask for information, like credentials and passwords, as “Not secure.” Google plans to eventually display the warning for all HTTP pages, regardless of whether the user is accessing the page in incognito mode or not, in hopes of better informing users that HTTP pages send data in the clear from the browser to a webserver.
