Cryptography & Security Newsletter

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 Ivan Ristić.

Logjam

Logjam is a newly-disclosed man-in-the-middle (MITM) attack that exploits a TLS protocol weakness, but works only against servers that use insecure Diffie-Hellman key exchange. To execute an attack, the MITM intercepts a client connection, then connects to the server, obtains and breaks weak DH parameters, and uses them to finalize the connection with the client. The attack is successful because the weak DH parameters are signed by the server’s strong key, allowing the MITM to impersonate the server. Conceptually, the attack is similar to the FREAK attack disclosed earlier this year.

If you’ve been following best configuration practices, Logjam doesn’t affect you. Only misconfigured servers that support DH parameters below 1024 bits are affected. If you are affected, the solution is to increase the strength of DH parameters to at least 1024 bits, but ideally 2048 (read on for more information). What if you can’t, for example if you’re using some older platform? One possible solution would be to put that old server behind a more secure proxy.

Another aspect that came out of the same research paper is that many server platforms use weak (1024-bit) DH parameters with common primes. Due to the way DH works, a powerful adversary (e.g., a nation state) could invest a lot of resources in breaking those common primes, allowing them to passively monitor all connections that involve them. Because this attack is passive (the attacker doesn’t influence TLS negotiations), the danger exists only if weak DH parameters are actively used with clients. Thus, for best results, upgrade to 2048-bit DH parameters. If you can’t do that straight away, you should at least try to configure your servers to use custom-generated parameters. In any case, you should be preferring the faster ECDHE key exchange with modern clients.

Logjam highlighted the fact that modern clients continue to accept insecure DH parameters. Microsoft recently changed that to enforce 1024 bits as the minimum strength. Chrome and Firefox will do the same in the near future, while Apple is planning to stay with 768 bits. As always, the issue is compatibility with older (misconfigured) servers on the Internet.

SSL Labs grading changes in v1.17

SSL Labs recently released version 1.17.10, which came with some interesting grading changes. First of all, RC4 usage with TLS 1.1+ is now discouraged with a C. Servers that support RC4 in any capacity (i.e., with older clients and protocols) have their score capped at B. Lack of support for TLS 1.2 is now penalised more heavily, also with a C. Finally, servers that use weak DH parameters below 2048 bits are capped at B. There is no change in the treatment of insecure DH parameters (below 1024 bits); they had been resulting in F even before Logjam.

Chrome and SHA1

I had written to you before about Chrome’s plans for SHA1 deprecation. They had a plan for multi-step process, but, with the release of Chrome 42 in April, that process is now complete. Today, if your SHA1 certificate expires during 2016, you get a warning; if it expires in 2017 and later, you get an error.

However, what’s not immediately obvious is that you can receive a warning or an error even if you’re serving a full SHA2 certificate chain. This is because Chrome doesn’t have full control of certificate chain construction; even when sites serve correct chains, client TLS stacks might decide to use different chains and submit them to Chrome. It’s not clear how many sites are affected, but I’ve heard from users of both SSL Labs and Feisty Duck web sites, complaining about seeing errors in Chrome. Apparently, the root cause is that some of these alternative certificate chains rely on SHA1 intermediates and cause warnings.

PCI DSS v3.1

In April, the PCI Security Standards Council released the v3.1 revision of the PCI DSS standard, effectively making SSL v3 and TLS v1.0 obsolete. New deployments are not required to rely on this older protocols. Existing deployments should start migrating straight away and have until 30 June 2016 to complete the process. As a special exception, SSL v3 can remain in use on platforms that can’t be attacked using the POODLE attack (which requires client-side JavaScript execution), for example POS terminals.

Public Key Pinning Extension for HTTP

Public key pinning is a powerful security technique that allows web sites to overcome the biggest weakness of Internet PKI, which is the fact that any CA can issue a certificate for any site. With pinning, sites can establish and enforce their own cryptographic integrities, restricting which certificates work for them. Now, finally, there is a standard for public key pinning in RFC 7469. At this time, Chrome and Firefox have near-complete support for this new standard.