Security Changes in Chrome 58: Common Name Support Dropped, A Nasty Homograph Vulnerability Fixed and More…
The latest version of Google Chrome has hit the stable channel, which means we have another round-up of the security changes in Chrome 58. We’ll be covering everything related to SSL/TLS along with other security enhancements.
NOTE: Chrome 59 has released, click here to see security changes in Chrome 59.
This month, Chrome has finally dropped support for Common Name checking, which they have been trying to do for years! If you manage/use a private root/PKI, you may want to make sure you are issuing your certificates properly (read below for more). Encrypted Media Extensions (EME) have been restricted to HTTPS-only, and the Notifications API will be joining it later this year.
Read on for the full breakdown of security changes in Chrome 58!
This is Apple.com, right?
This is a look-alike domain using a homograph attack – which exploits characters which are different but look similar. This particular trick works by combining a non-latin alphabet (in this case, Cyrillic) with a latin TLD (.com).
The internet (and most computing) has been designed around the English language. As billions of non-native English speakers come online, there have been efforts to provide support for other languages. IDNs (Internationalized domain names) are one of those major efforts, allowing for domains and TLDs to be registered in other languages.
However, this has also increased the effectiveness of homograph attacks – which use lookalike characters for phishing and other malicious purposes. For instance, our English letter “a” looks identical to the Cyrillic “a”, but from a computers point of view these are encoded as two entirely different letters. This allows domains to be registered that look just like legitimate domains.
A proposal for browsers to not be display IDNs has been considered unfairly prejudicial against non-English users. Chrome’s engineers have pointed out that domain registrars can implement a system for detecting domains that are attempting to abuse IDNs, and prevent their registration in the first place. They argue this is a more effective way of dealing with the abuse, and allows website’s around the globe to register a domain in their native language.
However, this specific example, which is mimicking Apple’s website, is a clear security vulnerability that Chrome has decided to address. They are mitigating this specific type of homograph attack by displaying the domain in its ‘punycode’ form (a method for displaying Unicode with the ASCII character set – similar to how ‘pinyin’ is used to write Chinese with English letters) when a domain is made entirely of Latin-look-alike Cyrillic letters and the TLD is not an IDN.
In Chrome 58, the same domain shown above looks like this:
Many people don’t know that the “Common Name” field of an SSL certificate, which contains the domain name the certificate is valid for, was actually phased-out via RFC nearly two decades ago. Instead, the SAN (Subject Alternative Name) field is the proper place to list the domain(s).
However, this has been ignored and for many years the Common Name field was exclusively used. Chrome is finally fed up with the field that refuses to die. In Chrome 58, the Common Name field is now ignored entirely.
This means certificates that were exclusively using that field to indicate the valid domain name are no longer supported. Publicly-trusted SSL certificates have been supporting both fields for years, ensuring maximum compatibility with all software – so you have nothing to worry about if your certificate came from a trusted CA.
This change will only affect private PKIs and other software that have not been following spec. If you notice any sites returning the error “NET::ERR_CERT_COMMON_NAME_INVALID,” it’s likely due to the certificate not using SANs properly. Users of products like Sophos’ HTTPS interception are now finding out that their software is not RFC-compliant. Eric Lawrence wrote more about this topic.
An enterprise policy has been added for those who need Common Name support for a while longer.
Recent research by Netflix has shown that Common Name handling can be exploited, demonstrating that this is one of the important security changes in Chrome 58
Chrome is incrementally moving forward on its plan to deprecate powerful features over insecure origins (aka, no privacy-exposing or persistent-access features over HTTP). The latest casualty is EME, or Encrypted Media Extensions. This is not a widely used feature, but still one of the valuable security changes in Chrome 58.
Notifications will require HTTPS (later this year):
The Notifications API – which allows websites to send desktop notifications to Chrome – will also be joining the exclusive HTTPS-Only club later this year.
In Chrome 58, a warning has been added to the console to inform developers. If your website relies on notifications, be prepared to lose access to this feature over HTTP in Chrome 61 (estimated release September 2017).
One of the more common causes of certificate errors are improperly configured certificate chains. When a server forgets to include all the intermediate certificates, clients may fail to path-build to a trusted root, and believe the certificate to be untrusted.
To combat this, certificates contain a field known as “AIA” that includes a URL where the proper intermediate certificate can be found. This gives clients the ability to get the file even if the server does not provide it.
However, only clients that implement ‘AIA fetching’ take advantage of this feature. Chrome supported AIA fetching on other platforms, and has now added the feature to its Android app.
A Certificate Transparency log operated by Beijing PuChuangSiDa Technology Ltd has been added to Chrome after successfully completing a compliance monitoring period. Each log can choose the roots that it will accept certificates from. The PuChuangSiDa log has said it will be open to all roots, but the specifics are still unclear and they have not stated if the service will be free for CAs.
The CAs WoSign and StartCom were entirely dis-trusted by Chrome after investigations revealed the CAs had failed to follow basic validation procedures. In order to minimize impact to users, Chrome implemented a whitelist to allow existing certificates to be trusted for a limited amount of time.
That whitelist, which is based on Alexa’s list of biggest websites globally, shrinks with each release of Chrome. In Chrome 58, the whitelist shrinks to the world’s 500,000 biggest sites (down from 1 million).
An obscure bug related to OID encodings had caused some sites, like BankOfAmerica.com to lose the EV treatment for their certificate. OIDs, or object identifiers, are a standardized set of values used to encode various values and data. In SSL Certificates, OIDs tell clients various information about the certificate such as the allowed key usage/EKU purposes.
OIDs are also used to indicate if a certificate is an EV (Extended Validation) certificate. Certain OID values were not being parsed properly by Chrome, causing some certificates to be treated as DV/OV. This bug has been fixed, restoring the EV treatment,
This is a bit of housecleaning for Chrome. ChaCha20-Poly1305 is an encryption and authentication cipher designed by Google and Redhat. Chrome had shipped an implementation of these ciphers based on a draft design, and is now removing them. These non-standard ciphers had already been deprecated (given an “OLD_” prefix) and this is the final step is removing them altogether.
The standardized version of this cipher has been included in Chrome since last year.
In addition to all this, there are more than two dozen security changes in Chrome 58, including $14,000 paid out to bug county contributors.
Update: A previous version of this post said that the Expect CT header had been launched in Chrome 58. That is incorrect, this feature is still in development and will land in a future version of Chrome.