25 February 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. Maintained by Hanno Böck.
OpenSSL published a security advisory and updates. One high severity bug was fixed in the 1.0.2 branch of OpenSSL affecting the Diffie-Hellman key exchange (CVE-2016-0701).
In the Diffie-Hellman key exchange, the calculations need a large prime as a parameter. The prime is part of the Diffie-Hellman parameters of a server. The primes usually used for this are called safe primes. They have the property that for a prime p there is another prime (p-1)/2. This other prime is called Sophie Germain prime.
OpenSSL 1.0.2 does not use safe primes by default; instead it uses primes of another form that were specified in RFC 5114. In combination with another property of OpenSSL this becomes a security problem: OpenSSL had the ability to cache and re-use ephemeral keys for several connections. Most common server applications like Apache and Nginx disable this key caching, but it was enabled by default.
OpenSSL 1.0.2f introduces an additional check that prevents attacks against this issue. Also, the caching of ephemeral keys in Diffie-Hellman key exchanges has been disabled and cannot be enabled any more. The Elliptic Curve Diffie-Hellman key exchanges have a similar ephemeral key caching property. This is independent of this vulnerability, but it may lead to security risks in other situations.
A second vulnerability (CVE-2015-3197) with low severity was also fixed: If SSLv2 cipher suites were disabled on a server, but the SSLv2 protocol was still enabled, the server would still allow connections with the disabled cipher suites.
The US National Institute of Standards and Technology (NIST) published a report on the state of Post-Quantum Cryptography. Quantum computers threaten the security of almost all cryptographic protocols in use today.
The biggest announcement in the report is that NIST plans to start a standardization process for post-quantum cryptography. NIST plans to publish preliminary evaluation criteria during 2016 that should be finalized by the end of the year. After that NIST will accept proposals for quantum-resistant algorithms.
The problem with existing post-quantum algorithms is that they are usually either not very well researched, or not very practical for production use. Last year an EU-funded research project led by Tanja Lange published preliminary recommendations for post-quantum cryptography.
Newer versions of the Chrome browser disallow certain features if they are not in a secure context. A web page is a secure context if it is delivered over HTTPS. In case it’s embedded as a frame or an iframe, the top web page also must be delivered over HTTPS.
Chrome has already disabled the possibility to access certain media features like the microphone or the camera in insecure contexts. Access to the geolocation API over insecure contexts will be forbidden in Chrome 50.
This move was not without controversy. On the Chromium security mailing list the owner of a company that provides microphone-based services embedded via Iframes complained that many users don’t see the need to move to HTTPS. However, given that access to a microphone might allow secret listening to sensitive conversations it seems sensible to restrict the access to secure websites.
These changes are implementing the Secure Contexts standard that was published by the W3C. Firefox also plans to implement this standard.
Researchers from the Concordia University in Montreal, Canada, published a paper analyzing the security of so-called TLS interception solutions. They found a large number of security problems.
Many software products install a root certificate into the browser in order to be able to inspect or manipulate traffic. This can happen through a locally installed proxy or a network device. Technically this is a Man-in-the-Middle attack. The researchers analyzed various antivirus and parental control applications.
Four applications (CYBERsitter, KinderGate, PC Pandora and G DATA) allowed attackers to trivially attack them, because they simply accepted all certificates presented to them. Several less severe problems were found in the other analyzed applications.The authors came to the conclusion that “all the analyzed products in some way weaken TLS security on their host”.
German IT magazine c’t also analyzed antivirus applications doing TLS interception and found that the ESET NOT32 antivirus software had a similar problem and didn’t properly verify certificates, thus allowing attackers to forge HTTPS websites.
TLS interception products have often been the source of security vulnerabilities in the past. The most prominent example was the Superfish adware that came preinstalled on Lenovo laptops. The author of this newsletter [Hanno Böck] also analyzed a number of such products in the past and found various security issues (1, 2, 3, 4).
On February 21st the Internet Society held a workshop with the title “TLS 1.3 Ready Or Not? (TRON)”. Several cryptographers analyzed the current draft version of TLS 1.3 and presented their findings. All papers are linked to from the workshop’s program web page.
Research presented at the workshop has already caused a discussion on the TLS mailing list about the removal of client authentication in zero-round-trip (0-RTT) connections. A paper by researchers from the Ruhr University Bochum about Bleichenbacher attacks against QUIC and TLS 1.3 was awarded best contribution to the workshop. We wrote about that research in our December newsletter.
This subscription is just for the newsletter; we won't send you anything else.
Designed by Ivan Ristić, the author of SSL Labs, Bulletproof SSL and TLS, 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.