In theory, when you visit an HTTPS website (https://) your connection is secured using SSL/TSL encryption. In order to ensure that the website you are connecting to is the website that you think you are connecting to, the website will present your browser with an HTTPS (also known an an SSL) certificate showing that the website (or more accurately ownership of the website’s public key) has been authenticated by a recognized Certificate Authority (CA), of which there are some 1200 in existence.
If a browser is presented a valid certificate then it will assume a website is genuine, initiate a secure connection, and display a locked padlock in its URL bar to alert users that it considers the website genuine and secure. This system, which is the cornerstone of security on the internet and is used just about every secure website that handles sensitive information (including banks, webmail services, payment processors etc.), therefore relies on trusting the CAs.
Unfortunately (as we have discussed before) it is fundamentally flawed because Certificate Authorities can (and have been known to) issue fake certificates (governments putting pressure on CA companies is the usual culprit, but criminals can also strong-arm CAs and hackers can compromise the CA their systems).
Google has now issued an alert over bogus certificates for Google domains,
‘On Friday, March 20th, we became aware of unauthorized digital certificates for several Google domains. The certificates were issued by an intermediate certificate authority apparently held by a company called MCS Holdings. This intermediate certificate was issued by CNNIC…. CNNIC is included in all major root stores and so the misissued certificates would be trusted by almost all browsers and operating systems.’
The post by Google Security Engineer Adam Langley does, however, go on the note that,
‘Chrome on Windows, OS X, and Linux, ChromeOS, and Firefox 33 and greater would have rejected these certificates because of public-key pinning, although misissued certificates for other sites likely exist.’
With public key pinning the browser associates a website host with their expected HTTPS certificate or public key (this association is ‘pinned’ to the host), and if presented with an unexpected certificate or key will refuse to accept the connection, and issue a warning to the user.
The issue highlights the two major flaws with the current certificate system:
- With hundreds of Certificate Authorities, it takes just one ‘bad egg’ issuing dodgy certificates to compromise the whole system
- Once a certificate is issued, there is no way to revoke that certificate except for the browser maker to issue a full update of the browser.
We have already looked at okTurtles’ ingenious if unproven solution for tackling the issue of a ‘broken’ HTTPS certificate system using blockchain authentication, and Langley pointed to Certificate Transparency as a more mainstream solution (helping to ‘eliminate these flaws by providing an open framework for monitoring and auditing SSL certificates in nearly real time’), although some continue to defend the system as is.