The Return Of Bleichenbacher’s Oracle Threat (ROBOT) attack takes advantage of an old vulnerability discovered by Daniel Bleichenbacher in 1998. We have previously seen the Bleichenbacher attack in 2016 when it was used in the DROWN attack on SSL 2.0.

The use of a ROBOT attack fully breaks the confidentiality of SSL/TLS when used with RSA encryption. It enables an attacker to perform RSA decryption and signing operations with the private key of an SSL/TLS server. As a result, an attacker could record SSL/TLS traffic and decrypt it at a later time.

Several servers that were vulnerable to ROBOT have provided patches. The researchers have stated the patch list will be kept up to date as more patches are released.

In addition to patching servers, the researchers state that RSA encryption should be disabled from SSL/TLS cipher suites. This means all cipher suites that start with TLS_RSA should be disabled, for example:


Not only is RSA encryption vulnerable to ROBOT, it does not support perfect forward secrecy. Most SSL/TLS connections use the Elliptic Curve Diffie Hellman key exchange (ECDHE) and need RSA only for signatures, for instance:


There may be a concern about browser compatibility costs associated with browsers that do not support ECDHE. Cloudflare, which runs a content delivery network, advised the researchers that about one-percent of their connections use RSA encryption modes. As such, you may want to consider connection losses before disabling RSA encryption.

Here’s How System Administrators Can Protect Servers

In summary, administrators can perform the following to protect their servers:

  • Perform the ROBOT test on the server to discover if you have a vulnerability
  • Contact your server vendor to determine if the server is vulnerable and if there are any patches
  • If your server vendor does not have a patch, you may consider disabling TLS_RSA cipher suites
  • Even if the ROBOT vulnerability is mitigated, you may consider disabling TLS_RSA cipher suites as they appear to be high risk and do not support perfect forward secrecy
  • Note, no action is required for SSL/TLS certificates as the certificate private key is not exposed by this vulnerability