27 October 2016
Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space. Received monthly by more than 50,000 subscribers. Maintained by Hanno Böck.
Google developer Ryan Sleevi announced that starting with October 2017 the Chrome browser will require that all new HTTPS certificates get logged in the Certificate Transparency system. Certificate Transparency is a system of public logs of certificates. The idea is to bring transparency into the certificate system and make it much harder to abuse certificates.
In the past Certificate Transparency was already helpful in uncovering numerous instances of wrong certificate issuances. Most notable was an incident in 2015 with the certificate authority Symantec (see our past newsletter on the incident).
Up until now Google only required Extended Validation certificates to be logged. In practice, however, most certificates were already logged. Now Google is taking the next step and requires logging of all certificates.
Three research papers lately looked into the possibility of backdoored parameters for the Diffie-Hellman key exchange. A research team was able to construct a 1024 bit prime number that contains a secret backdoor. This research was based on very old attacks from the 90s.
Two research papers (, ) investigate suspicious Diffie-Hellman parameters in the wild, several of which allow compromising the security of TLS connections. In light of this recent research questions were raised about RFC 5114, which specifies prime numbers for Diffie-Hellman, but doesn’t explain their origin.
Earlier this year David Wong already investigated the possibility to backdoor Diffie-Hellman parameters if a composite number is used instead of a prime.
The certificate authority Comodo recently had to report a security vulnerability in their domain validation process. Some top level domain authorities provide the whois data only with a picture of the email address. Comodo used an OCR text recognition software to extract these email addresses. However, the text recognition could result in errors. Thus, it was sometimes possible to receive the domain validation emails by registering a similar looking domain. Two security researchers discovered this and the German news magazine heise.de reported about it.
This is the third security issue in Comodo’s domain validation process in the past months. As we reported in this newsletter last month, due to an error Comodo issued certificates for various top level domains. In our August newsletter we reported that the domain validation emails from Comodo had a script injection flaw.
We wrote in the last month’s issue about the incidents involving the certificate authority WoSign, who misissued certificates in various instances and backdated certificates in a deception attempt. Mozilla has now decided to finally distrust all WoSign certificates, as well as the certificates from StartCom, as they are now owned by WoSign. Earlier this month Apple announced that they will do the same.
WoSign is now owned by the company Qihoo 360. This has caused some debates about the 360 secure browser developed by that company. It allows connections to sites despite certificate validation errors. In light of these issues Mozilla developer Gervase Markham created a list summarizing the behaviour of various browsers in different cases of certificate validation issues.
This subscription is just for the newsletter; we won't send you anything else.
Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.
Remote and trainer-led, with small classes and a choice of timezones.
Join over 1,500 students who have benefited from more than a decade of deep TLS and PKI expertise.