- How does the new attack work at top level?
They used BEAST-like Man in the Browser attack by using Cache-like attacks to perform a downgrade attack against any TLS connection to a vulnerable server. With this, they showed the feasibility of using Cache-like attacks.
Even over the years, numerous mitigation techniques are deployed against the padding oracle attacks, they showed that some implementations are still vulnerable to various microarchitectural side channels. They target PKCS #1 v1.5 implementations that leak information via microarchitectural side channels.
Their attacker requires 3 capabilities:
Side channel capability: attacker must be able to execute code on the victim machine to mount microarchitectural side channel attack. They used Flush+Reload attack.
Privileged Network Position Capability: The attacker must be in the man-in-the middle position so that padding oracle attack with the private key can be exploited. The attacker downgrades the communication to TLS 1.2 RSA key exchange with Jager et. al.'s attack and used BEAST method.
Decryption Capability: The attacker needs an ability to start decryption of ciphertext chosen by him on the target system. They utilized Bleichenbacher and Manger’s Attack attack.
A concrete scenario of the attack:
A physical device shared between a TLS server and the attacker's virtual machine. This requires a determined adversary.
Second and third can be achieved by the controlling a node between the server and client
Note: Manger’s Attack that requires $\log_2(N)$ perfect Oracle queries. Bleichenbacher's attack requires millions of Oracle calls but can tolerate false negatives. They mounted an improved Manger’s Attack's attack with only 6144 queries due to an error.
Although the timeout of the browser limits the attack, they were able to parallelize the attack by using TLS servers that share the same public key certificate.
- Which TLS implementations are affected?
They tested the following implementations:
- Amazon s2n
- Apple CoreTLS
- Mozilla NSS
All, except the BearSSL and BoringSSL are affected by their attack.
- How one can mitigate from the attack?
- Keep the system up-to-date: don't support different versions.
- The backward compatibility is the main issue of this attack. TLS 1.3 security doesn't help you if your server can be downgraded to an earlier version.
- Deprecate the RSA key-exchange.
- Certificate Separation: Don't use the same key for singing and RSA-key exchange.
- Constant-Time Code and Safe API as in BearSLL and BoringSSL API.
- Using Large RSA Keys. The attack requires $\approx \log N$ oracle calls. Use larger keys $>2048$-bits to make the attack less practical.
- Reduce the TLS Handshake Timeouts in order to make MitM attack harder.
- Use BearSSL or BoringSSL
Note: The 30-second timeout in Firefox can be extended see Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice. by Adrian et. al.
Note 2: There is a related question in SecuirtySO about effected cipher suites.