29 September 2016
Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Hanno Böck.
The certificate authority WoSign came under fire for various security incidents. Gervase Markham from Mozilla started the debate with an email to Mozilla’s security policy mailing list. Someone was able to generate a certificate for github.io by controlling a subdomain. For some time it was possible to generate certificates by controlling unprivileged port numbers.
In a third incident it was possible to generate SHA-1-signed certificates, which happened through the certificate issuance system from StartCom, indicating that the two companies share parts of their infrastructure. It later turned out that Wosign had backdated several certificates in order to circumvent the SHA-1 ban starting January this year.
During the debate several further issues came up and a former employee of StartCom claimed that WoSign is now the sole owner of StartCom. This was later confirmed by investigations from Mozilla.
Mozilla now proposes that new certificates from WoSign and StartCOM should no longer be trusted in their browser. They could reapply for browser inclusion in a year under certain conditions. Existing certificates would still be trusted. This would theoretically allow WoSign to create backdated certificates, however Mozilla announced that if they saw any evidence of this they would immediately distrust all Wosign/StartCOM certificates.
Comodo issued a certificate for the top level domain sb to a user who owns the domain www.sb. Top level domains are not supposed to have TLS certificates. This was due to a bug where control over the www subdomain indicated ownership of the upper domain.
According to an incident report sent to Mozilla’s policy mailing list, Comodo had known about this bug for several weeks. A certificate for the top level domain tc had already been issued due to the same bug. "Since 'www.tc' and 'tc' both belong to the same entity, we took the view that the cert had not been misissued and that an incident report was not warranted. We also took the view that this flaw did not require an urgent hotfix”, Comodo wrote in the incident report.
It seems that Comodo had issued similar certificates in the past for other top level domains. The certificate transparency logs contain a certificate for re that expired in 2015.
OpenSSL released fixes for several security bugs. The most severe bug affected the OCSP handling and allowed crashing affected servers. The bug was discovered by the company Qihoo 360. They even created a logo for it!
Shortly after that security update OpenSSL released another security advisory. Two of the bug fixes had introduced other security bugs. In OpenSSL 1.1.0 a use after free bug was introduced.
For quite some time Google had been announcing that in the future Chrome would mark HTTP connections as insecure. However until recently this was an announcement without any date attached to it. Now Google got a bit more precise about when it will implement the first steps.
In January 2017 the new Chrome version will mark as insecure those sites that are unencrypted and have a form with a password or credit card field in them.
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 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.