30 June 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.
Let’s Encrypt saw its name endangered by several trademark registration attempts from Comodo. In October 2015 Comodo tried to register three trademarks, “‘Let’s Encrypt”, “Comodo Let’s Encrypt” and “Let’s Encrypt with Comodo”. Let’s Encrypt was first publicly announced in November 2014, almost a year earlier, therefore it can be assumed that these registrations didn’t happen by accident and that Comodo had been aware that a competitor under that name was planning to start operating soon.
Shortly after the Let’s Encrypt announcement, a post on the Comodo forum stated that the company had filed a request for express abandonment of these trademark applications. Let’s Encrypt confirmed that.
Comodo’s CEO Melih Abdulhayoğlu indicated that the registration of the trademarks was a response to the fact that Let’s Encrypt had copied Comodo’s business model of offering free certificates with a validity of 90 days. However, the comparison is questionable: Comodo offers 90 day trial certificates, but prolonging them is not free; Let’s Encrypt uses 90 day certificates that are free to renew.
A team of researchers from EFPL and the University of Leipzig achieved a new record in calculating discrete logarithms. By using the number field sieve and a cluster of 200 cores running since February 2015, the team was able to compute a discrete logarithm in a prime field with a 768 bit long prime.
The discrete logarithm problem is the basis of cryptographic algorithms like DSA and the Diffie-Hellman key exchange. While it has been known for a long time that discrete logarithms with group sizes of 768 bit are potentially insecure, they were still in use up to quite recently. After the Logjam attack, browsers increased the minimum size of the Diffie-Hellman group to 1024 bit, which caused incompatibilities with a sizeable number of devices.
IETF published RFC 7905, which is an official specification for the use of the algorithm ChaCha20 and the mode Poly1305 in TLS. ChaCha20 is a stream cipher developed by Dan Bernstein and a variant of the Salsa20-cipher, which was one of the winners of the ESTREAM competition. Poly1305 is an authenticated encryption mode.
The deployment of this new cipher was a response to many attacks discovered against other widely used TLS cipher suites. Many variants of so-called padding oracle attacks have challenged the security of CBC-based TLS ciphers. And biases in the keystream of RC4 enabled attacks on these cipher modes as well. The only cipher modes left in TLS were those based on the Galois/Counter-Mode (GCM).
There haven’t been any significant attacks against GCM, but the mode is not very popular among cryptographers. It has a reputation of being hard to implement safely. Another concern with GCM in TLS is the fact that implementations have to choose a nonce value, and that is a problem because if that nonce value is ever repeated, the cipher fails catastrophically (see the May edition of this newsletter). The new ChaCha20/Poly1305-specification considers this problem and doesn’t leave the choice of the nonce up to the implementer.
Google, Cloudflare and others have been using preliminary versions of the new cipher modes for quite some time. Firefox supports the new cipher suite since version 47, and OpenSSL will support it in the upcoming version 1.1.
Google developer Adam Langley wrote a detailed explanation of the challenges of algorithm and version agility in TLS. Langley expects that version fallback workarounds will come back with TLS 1.3. This was confirmed by Google developer David Benjamin on the TLS working group mailing list.
TLS version fallbacks were introduced by browsers in the past, because some servers misbehave if a browser tries to connect with a higher version of TLS than the server supports. A correctly behaving server can signal the client that it only supports a lower version.
These version fallbacks enabled some attacks in the past, notably the Virtual Host Confusion attack and the POODLE attack.
Cloudflare developer Filippo Valsorda recently pointed out that Symantec had issued an intermediate certificate to the company Blue Coat. That caused some uproar because Blue Coat has a questionable reputation in the cryptographic community. It has been named an Enemy of the Internet by Reporters Without Borders.
Shortly after that incident Symantec announced that they have acquired Blue Coat.
Amazon has long been one of the most significant web pages that did not use HTTPS by default. Up until recently, the company only used HTTPS for the login itself, but not for the whole web page. Such constructions are not secure due to SSL stripping attacks. Amazon has now moved to HTTPS by default and HTTP requests to the Amazon domain are now redirected. However, Amazon still doesn’t use HTTP Strict Transport Security (HSTS).
The British newspaper Sun and the IT news site Techcrunch recently joined the few media web pages that use HTTPS by default. News media sites have been slow in adopting HTTPS, because many ad networks refuse to support the encrypted protocol.
Telemetry data from Firefox suggests that 45% of web connections use HTTPS these days. Let’s Encrypt suggests that this number could surpass 50% this year.
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.