Bulletproof TLS Newsletter #18
Version Intolerance and TLS 1.3, Google uses Post-Quantum Cryptography, StartEncrypt vulnerabilities
28 July 2016
Author: Hanno Böck

This issue was distributed to 28,367 email subscribers.

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.

In this issue:

  1. Nearing TLS 1.3 shipment causes worries over version intolerance
  2. Google starts using Post-Quantum Cryptography in TLS
  3. StartEncrypt security vulnerabilities
  4. Symantec’s controversial issuance of SHA-1 certificate for TSYS
  5. Other news

Nearing TLS 1.3 shipment causes worries over version intolerance

While no date is set, it is generally expected that the TLS version 1.3 will be finalized in the near future. However, deploying the new version may pose some challenges that are familiar from previous switches to newer TLS versions.

When a client tries to connect with a server, it includes its highest supported version in the ClientHello message. If a server receives a ClientHello with a version higher than the ones it supports, it is supposed to still establish a connection with the highest version it can provide. However, a significant portion of servers don't implement this version negotiation correctly and will simply either terminate the connection or produce an error once a client tries to connect with TLS 1.3 or higher. These servers are called version intolerant. According to scans done by various researchers, the share of TLS 1.3 intolerant servers is around 3 percent.

In the past, browser vendors implemented fallbacks to work around these broken server implementations. In case of a connection failure, a browser would retry to connect with a lower version. These version fallbacks turned out to be quite problematic and enabled security vulnerabilities like Virtual Host Confusion and POODLE. The reason for that is that an attacker can trigger connection failures and thus force a connection to a lower and less secure TLS version. Sometimes fallbacks can be triggered simply by poor Internet connections. To counter the issues introduced by version fallbacks, a new mechanism to prevent fallbacks called SCSV has been introduced.

Given the trouble version intolerance and version fallbacks have caused in the past, they have recently been removed or disabled in most browsers. But now it seems that they will make a comeback with TLS 1.3. Google developer David Benjamin, while clearly stating that he opposes the fallbacks, wrote that he is certain he will have to implement them again. Benjamin proposed an alternative version negotiation mechanism based on TLS extensions, but it was received with little support during the IETF 96 meeting in Berlin.

So it looks like version fallbacks with TLS 1.3 will come, even though nobody seems to like them. How long they will stay will depend on how fast the community is in fixing existing version intolerant devices. Several people have started doing scans and tried to find out which devices and software products are responsible for version intolerance.

Servers can be checked for version intolerance with the Qualys SSL Labs test. A more thorough test is part of the TLS Fuzzer tool from Red Hat developer Hubert Kario and the testssl.sh script also has a preliminary test.

Apart from these potential deployment issues, TLS 1.3 is progressing and is expected to be finalized within the upcoming months. A major change was recently discussed: instead of the existing system of cipher suites, coupled with a complicating elliptic curve extension, a new negotiation mechanism was proposed that separates the selection of a symmetric cipher, key exchange and signature algorithm. The proposal was welcomed at the IETF 96 working group meeting by most participants.

By now there are seven implementations of the preliminary TLS 1.3 specification and several test servers. Firefox and Chrome already ship test implementations of TLS 1.3 that are disabled by default, but can be manually enabled.

Google starts using Post-Quantum Cryptography in TLS

Worries about cryptographic attacks on public key encryption using quantum computers have increased the research in post-quantum cryptography in the past years. But Google now pushes the issue forward by implementing a supposedly quantum safe key exchange algorithm in its Chrome browser and some of its servers. Google has chosen the New Hope key exchange, an algorithm based on the Ring Learning With Errors problem that was published last year.

While this may seem like a bold and risky move, Google has put a safeguard into its experiment. The security of the TLS connection doesn't rely entirely on New Hope – that indeed would be risky, as such a new algorithm cannot be considered secure. Instead, the new TLS mode uses a combination of the X25519 elliptic curve key exchange and New Hope. So even if New Hope turns out to be completely insecure, the connections will still get the security from X25519.

Such hybrid key exchanges have been proposed before for post-quantum cryptography. In 2014 a research team published a draft and an experimental OpenSSL patch for a combined elliptic curve and RLWE key exchange. The Tor project is currently also discussing use of X25519 and New Hope, as we have reported in our last Newsletter. However, Google is the first company to actually use such a key exchange in production.

Only a small number of connections will use this new key exchange. Google is interested in gaining experience with potential problems. The larger handshake messages that come with New Hope (and most other post quantum schemes) may cause trouble with network middleware.

New Hope and other algorithms based on Ring Learning With Errors belong to the field of lattice-based cryptography. The security of lattice schemes is disputed amongst cryptographers and many are wary and point out that much more research is needed until one can be confident in security of such schemes.

StartEncrypt security vulnerabilities

StartSSL has recently launched a system called StartEncrypt that was supposed to automate certificate issuance. While that was not stated explicitly, it was likely designed to offer similar features as Let’s Encrypt.

Security researchers from Computest found some severe security issues with StartEncrypt. The most significant was that StartEncrypt allows validation of domain ownership over a URL that is given by the certificate requester. This means that one could generate a certificate for every domain that allows uploading arbitrary files, such as Github or Dropbox.

StartSSL has reacted and has temporarily disabled the StartEncrypt service. In the future they plan to use ACME, the protocol developed by Let’s Encrypt.

This incident highlights potential security issues with domain ownership verification by certificate authorities. ACME wasn’t without flaws either. During the beta phase Andrew Ayer showed a vulnerability in one of the ownership verification mechanisms. It was good that Let’s Encrypt started deploying ACME in a beta test and allowed the security community to review the protocol before it got used for production certificates.

Symantec’s controversial issuance of SHA-1 certificate for TSYS

A request by Symantec for the issuance of SHA-1-signed certificates for the payment company TSYS has caused some debate. SHA-1 certificates are officially deprecated, but exceptions have been made in the past. The CA/Browser Forum had many debates on how to handle these cases.

At first, Symantec issued the certificates without asking the browser vendors and immediately announced that the issuance was a mistake and the certificates were revoked. Then Symantec officially asked for the issuance of seven certificates.

On a Mozilla mailing list Nick Lamp pointed out that the certificate requests contained very unusual strings in the Organization Unit (OU) field, for example “TDS-2-Ashburn-SCA-bbL6gMDyTZU8”. This was worrying because a potential attack on the weaknesses of SHA-1 - a collision attack - would very likely include such random looking strings somewhere in the certificate. The explanations provided by TSYS and Symantec were considered insufficient by many.

A proposal for a rigid construction that avoids concerns about collisions was discussed. In the end Symantec issued the certificates without the questionable strings in the OU field.

Other news