Google Chrome to make certificate transparency mandatory in 2017
Tue 25 Oct 2016
The development team behind Google’s Chrome browser has announced its aim to make Certificate Transparency mandatory for website domain certificates issued after October 2017. New domain certificates with unclear, compromised or otherwise unmonitorable chains of trust will thereafter be accompanied by at least a warning to Google Chrome viewers.
The announcement, by Google software engineer Ryan Sleevi, makes clear that the Chrome team will extend all necessary help to certificating authorities to prepare them for compliance in the next twelve months.
‘Although the date is a year away, we encourage any participants that wish to have their use cases addressed to bring them forward as soon as possible during the next three months. This will ensure that the IETF, the CA/Browser Forum, and the broader community at large have ample time to discuss the challenges that may be faced, and find appropriate solutions for them.’
The problem being addressed by Certificate Transparency problem is that certificates can be compromised and abused far more quickly than is reflected in the traditional chain of trust, since new information or updates to certificates traditionally take days, weeks or months to propagate around the world.
It’s a window of opportunity that’s more than adequate for the purposes of hackers and scammers. As the Certificate Transparency site notes, Dutch certificate authority DigiNotar was compromised in 2011, allowing an attacker, apparently from Iran, to issue public key certificates for some of the biggest sites on the planet, including the likes of Microsoft, Google and Facebook.
Effectively this allows a successful ‘intervener’ to perform man-in-the-middle (MitM) attacks on some of the most trusted digital providers around, potentially gaining access to critical personal or business information.
Certificate Transparency adds three new facets to the chain-of-trust: logs, monitors and auditors. Though CT does not use blockchain architecture, the certificate logs it maintains are similarly protected from alteration by encryption using the Merkle Tree Hash; this means that a log can only have information appended to it, not removed or any existing information amended. Neither can a log be forked without setting off warnings to the auditing processes that are monitoring the chain of trust. Logs are also publicly auditable.
The monitoring processes in the scheme are looking for strange certification behaviour or permissions, and check that the entire chain is visible and verified. Since various monitors may exist among different authorities, these can collate and compare their information, to more quickly determine compromised certificates, through a ‘gossip’ protocol.
Auditors are intended to be run by certificating authorities, but anyone can create one, and their form can vary between a browser’s TLS client, a server-based standalone service or even an ancillary function of a monitor – and likewise auditors can use the gossip mechanism to ensure rapid agreement about the security and/or status of a certificate.
Though the Certificate Transparency open framework promises to shave days, weeks or perhaps even months off the laggard network updates which govern the certification process, and though it monitors effectively in real time, it cannot act in real time, and actors which are able to compromise certificates and who need only a very narrow window of opportunity are not necessarily locked out of all opportunity.
The Chrome team will be proposing a possible new http header protocol at the next Internet Engineering Task Force (IETF) meeting in November. A dedicated header would permit individual sites to opt in to Certificate Transparency requirements before autumn of 2017, and avoid what seems likely to be an avalanche of false positives and late fixes.