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 Hanno Böck.

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.

Short News

• OpenSSL developer Matt Casswell explains a security issue with pointer arithmetics in a blog post. While the security impact of the issue is likely low, it points to a common way of using pointer arithmetics in C that is actually undefined behavior.
• Michał Trojnara, the developer of stunnel, released version 5.35 fixing a high severity security issue regarding client certificates.
• GnuTLS fixed a security bug affecting applications that use the p11-kit certificate trust store. The issue is fixed in versions 3.3.24 and 3.4.14, while version 3.5 is not affected.
• A severe security flaw has been discovered in the certificate validation of IPSEC connections on Juniper devices. Certificates would be considered valid if the “Issuer” text field in the certificate matches an accepted certificate authority. The signature was however not checked, so everyone could trivially create a certificate that would be accepted.
• The HTTPOXY vulnerability affects CGI web applications when they use HTTP implementations which respect the HTTP_PROXY environment variable. In this case an attacker can redirect web requests over a proxy under his control. Noteworthy about HTTPOXY from a TLS perspective is that the consequent use of HTTPS and certificate validation for API requests by web applications prevents most of the impact of HTTPOXY. An attacker might still be able to redirect traffic over a server under his control, but he cannot manipulate or read the transmitted data.
• The German E-Mail provider Posteo introduced a STARTTLS enforcement feature. If customers of Posteo enable that feature, emails will only be delivered if the target server supports STARTTLS. It would refuse to transmit mails to servers that only allow plain text connections or only support outdated encryption methods like SSLv3 or RC4. The introduction of the feature uncovered that some prominent domains in Germany don't support STARTTLS for SMTP yet. This includes the domain of the Socialdemocratic Party (SPD) and the Internet providers Congstar and KabelBW. The case is interesting from a TLS advocacy perspective: while Posteo is only a small email provider, it has immediately caused a lot of attention for the lack of STARTTLS encryption. Most of the affected domains are likely to soon deploy STARTTLS. However, it should be mentioned that while the use of STARTTLS is desirable, it only provides protection against passive attacks, as certificates usually aren't validated on the SMTP level.
• The latest Java update (JDK 8u11) added the root certificates of the Identrust certificate authority to Java's certificate store. Certificates from Let's Encrypt are cross-signed by Identrust, therefore this update is required in order to use Let's Encrypt certificates with Java clients.
• Troy Hunt comments in a blog post about the speed comparison between HTTP and HTTPS. A site that has been available for a while compares the speed of both protocols and claims that HTTPS is much faster. The reason for that is that the HTTPS variant uses HTTP/2. Critics say that this is an unfair comparison, as it compares HTTP/1.1 with HTTP and HTTP/2 with HTTPS. Troy Hunt argues however that what matters is the speed one gets. While it is in theory possible to support HTTP/2 over plain text HTTP, most browsers don't implement this. HTTPS is usually a condition for using HTTP/2. It could be added that in the future HTTPS is likely to be even faster, as other features that impact performance are also most often only available over HTTPS (for example the Brotli compression). The reason that new features are often only implemented over HTTPS isn't only HTTPS advocacy by the browser vendors. It is also because existing middleware may prevent new features from working if they are delivered unencrypted.
• A heap overflow in the ASN.1 parser of an important library used on mobile phone basebands has caused headlines. While the issue isn’t directly related to TLS it highlights the fact that ASN.1 parsers are notorious for memory corruption vulnerabilities - and ASN.1 is an important building block of the certificate ecosystem.
• Researchers discovered an issue with the web crawler from Apple News, which may cause many unneeded requests to websites using Let’s Encrypt certificates. According to Daniel Aleksandersen, the bot will try to fetch the robots.txt file and will get forwarded to https, but will subsequently fail to connect with an HTTPS host using Let’s Encrypt. Subsequently several bots tried repeatedly to request that file, causing ressources on the server to be exhausted. Aleksandersen says that he reported the issue to Apple three months ago, but that it is still not fixed.
• On the discussion list about the WebVR standard there was a longer discussion about the HTTPS requirement. WebVR is a technology which allows use of virtual reality devices like the Ocolus Rift on web pages. Like many new web technologies it’s intended that these are only allowed in secure contexts, meaning that HTTPS is required to use them.
• Eric Mill created a public document listing major sites switching to HTTPS.
• Rustls, a TLS implementation in the programming language Rust, has been published. It uses the ring library for cryptographic operations. Rust is a programming language developed by Mozilla that is designed to avoid many common memory safety issues by design. Ring is using BoringSSL’s libcrypto for low level cryptographic operations, therefore both ring and rustls still depend on C code.
• Chrome has recently started experimental support for TLS 1.3. It is currently available in the Canary builds of Chrome and disabled by default.
• The Mozilla Observatory is an experimental tool which allows testing of web sites’ security, including testing for several TLS configuration issues. The source code is available under a free license.
• The Caddy webserver was released in version 0.9. The major new feature is the support for Google’s QUIC protocol. Caddy is a web server written in Go with support for HTTPS by default by automatically requesting certificates via Let’s Encrypt
• Google announced some changes in the way Android Nougat will handle certificates. User-added certificates will no longer be accepted by apps making TLS connections.
• Remy van Elst published a method to extract keys from Nitrokey HSMs.
• The Indian company Airtel is supposedly intercepting connections between Cloudflare and their customers. Cloudflare offers TLS by default on the frontend, but the encryption for the backend part - between Cloudflare and the content server - is not mandatory. This is often criticized, because it may give the impression that a connection is secure while parts of it still happen in plain text.
• The BBC announced that it will support HTTPS for all of its pages within the next 12 months.
• Cisco researchers presented a method to detect malware traffic inside TLS connections in a research paper published on Arxiv.
• The Paypal main domain paypal.com no longer accepts connections with TLS 1.0 or 1.1. This can cause compatibility issues with older browsers. The webpage subdomain www.paypal.com can still be accessed with TLS 1.0.
• The company Nightwatch Cybersecurity points out that older versions of the Amazon Kindle browser don’t access the Google search over HTTPS and prevent HTTPS forwarding when accessing the webpage.
• MatrixSSL released version 3.8.4 that fixes a security vulnerability discovered by the author of this newsletter that allows crashing servers and potentially causing memory corruption.