Cybersecurity glossary
What is the ROBOT Attack?
Learn what the ROBOT attack is, how TLS RSA PKCS#1 v1.5 padding oracles returned in 2017–2018, which servers were affected, and how disabling RSA decryption suites stops the threat.
Definition
ROBOT (Return Of Bleichenbacher's Oracle Threat) is a practical revival of Bleichenbacher-style RSA PKCS#1 v1.5 padding-oracle attacks against TLS servers that still perform RSA key exchange and leak whether crafted RSA ciphertexts decrypt to correctly formatted premaster secrets—allowing attackers to decrypt or sign with the server’s RSA key under vulnerable conditions.
Why ROBOT mattered
Nearly twenty years after Daniel Bleichenbacher’s RSA PKCS#1 attack, the Internet still depended on TLS RSA key exchange in many places. In 2017–2018, Hanno Böck, Juraj Somorovsky, and Craig Young showed that numerous products again leaked just enough decrypt-status information for practical exploitation. They named it ROBOT—Return Of Bleichenbacher's Oracle Threat.
ROBOT was unsettling because the industry thought this lesson was already learned. Patches had shipped in the late 1990s and 2000s, yet subtle differences in TLS alert behavior, timing, or connection teardown recreated usable oracles on modern HTTPS infrastructure.
What ROBOT actually is
ROBOT is not one buffer overflow. It is the rediscovery that TLS servers performing RSA decryption can act as PKCS#1 v1.5 padding oracles. Attackers send crafted ClientKeyExchange RSA ciphertexts and watch how the server reacts. Distinguishing “looks like a valid premaster secret” from “clearly malformed” enables adaptive attacks that decrypt or sign.
Legacy mechanism
TLS RSA key-exchange cipher suites where the client encrypts the premaster secret to the server certificate.
Oracle signal
Distinct alerts, timeouts, or timing when PKCS#1 padding or premaster format checks fail.
Attack heritage
Direct descendant of Bleichenbacher 1998, adapted to contemporary TLS stacks and middleboxes.
Impact classes
Decrypt RSA-mode TLS sessions or produce signatures verifying under the server’s RSA key.
How the ROBOT attack works
Confirm RSA key exchange is offered
Probe the server for TLS_RSA cipher suites that trigger server-side RSA private-key decryption.
Send crafted RSA ciphertexts
Submit many ClientKeyExchange values carefully chosen to test PKCS#1 v1.5 format hypotheses.
Classify server reactions
Map alerts, drops, and latency into ‘possibly valid padding’ versus ‘definitely invalid’ categories.
Iterate the Bleichenbacher search
Use oracle answers to narrow the plaintext space until the premaster secret or signing capability is obtained.
Decrypt or forge
Recover recorded RSA-TLS session keys or create signatures the certificate’s public key accepts.
Oracle strength varied by product. Some hosts were quickly exploitable; others required more queries or were only weakly distinguishable—still unacceptable for Internet-facing TLS.
ROBOT compared with related RSA oracles
| Property | ROBOT | Bleichenbacher 1998 | DROWN |
|---|---|---|---|
| Era | 2017–2018 disclosures | 1998 SSL PKCS#1 attack | 2016 SSLv2 cross-protocol |
| Oracle surface | Modern TLS RSA decrypt | SSL/TLS RSA PKCS#1 checks | SSLv2 with shared RSA keys |
| Needs SSLv2? | No | No | Yes (as helper protocol) |
| Primary lesson | Oracles keep returning | Never leak padding validity | Legacy protocols poison shared keys |
| Operational fix | Disable RSA kex; patch stacks | Uniform errors; OAEP later | Disable SSLv2; isolate keys |
Who was affected
Any TLS server that still offered RSA key-exchange suites and distinguished decrypt failures insecurely was a candidate. That included popular web servers, TLS appliances, load balancers, and certain FIPS or enterprise products that preserved RSA suites for compatibility.
Organizations that had already disabled RSA key exchange and relied only on ECDHE + AEAD were largely outside ROBOT’s reach—even before patches—because the private key was no longer used to decrypt attacker-supplied TLS RSA blobs during handshakes.
Mitigations
Disable RSA key exchange
Remove TLS_RSA_* (and similar) suites so handshakes never feed attacker ciphertext to RSA decrypt.
Patch TLS products
Apply vendor fixes that unify error handling and close timing or alert oracles.
Prefer TLS 1.3 / PFS
TLS 1.3 and ECDHE suites provide forward secrecy and avoid RSA key transport entirely.
Retest with scanners
Use ROBOT-oriented checks after config changes; middleboxes can reintroduce RSA suites silently.
What practitioners should do today
- Audit cipher suites on every terminator and disable RSA key-exchange options.
- Require ECDHE (or DHE) with AEAD; treat RSA-only kex as a finding, not a preference.
- Enable TLS 1.3 where clients allow and keep TLS 1.2 configurations equally free of RSA kex.
- Patch F5, Cisco, Java, OpenSSL, and other stacks historically implicated in ROBOT advisories.
- Re-scan after CDN or WAF cutovers—edge TLS config is easy to desync from origin policy.
- Monitor for unexpected TLS_RSA negotiations in telemetry as a regression signal.
- Keep certificate private keys in HSMs with minimal decrypt surface area for legacy exceptions.
- Document residual RSA-kex exceptions with owners and removal dates.
Lessons ROBOT left for TLS operations
ROBOT taught that cryptographic vulnerability classes outlive individual patches. As long as a dangerous interface remains—here, RSA PKCS#1 v1.5 decryption of untrusted TLS blobs—implementations will keep finding new ways to leak. Removing the interface is more reliable than promising perfect constant-time, identical-alert behavior forever.
It also rewarded defense in depth: even imperfect oracle hardening matters less when RSA key exchange is simply off.
The practical takeaway
The ROBOT attack revived Bleichenbacher padding oracles against TLS servers that still decrypted RSA key-exchange ciphertexts and leaked validity. Disable RSA key exchange, patch TLS stacks, prefer TLS 1.3 and forward-secret AEAD suites, and continuously verify that no edge device brings TLS_RSA_* back for compatibility.
Related security terms
Bleichenbacher Attack
The original 1998 RSA PKCS#1 v1.5 padding-oracle attack that ROBOT revived against modern TLS stacks.
DROWN (CVE-2016-0800)
Related RSA oracle theme using SSLv2 as a cross-protocol decryption helper.
RSA
Public-key algorithm whose TLS key-transport mode ROBOT abused.
Padding Oracle Attack
Symmetric CBC cousin of the asymmetric padding-oracle idea.
TLS Handshake
Where RSA-encrypted premaster secrets were processed and oracle responses observed.
Frequently asked questions
What is ROBOT in simple terms?
ROBOT showed that many HTTPS servers still answered RSA handshake puzzles in a way that revealed whether attacker-made ciphertexts ‘looked like’ valid TLS secrets—enough to decrypt traffic or forge signatures using the server’s RSA key behavior.
What does ROBOT stand for?
Return Of Bleichenbacher's Oracle Threat.
Is ROBOT a single CVE?
No. ROBOT was a class of implementation flaws across vendors. Multiple products received distinct CVE IDs and patches when their RSA decrypt error handling leaked information.
Does ROBOT affect TLS 1.3?
TLS 1.3 removes RSA key-transport cipher suites, so classic ROBOT oracles against RSA premaster decryption do not apply to pure TLS 1.3 configurations. Servers that still offer TLS 1.2 RSA key exchange remain in scope.
What could attackers achieve?
Depending on the oracle strength and server behavior, attackers could decrypt recorded RSA-key-exchange TLS sessions or craft signatures that verify under the server certificate’s RSA key.
How do you mitigate ROBOT?
Disable TLS_RSA_* cipher suites (RSA key exchange), prefer ECDHE with AEAD, patch TLS stacks, and verify that RSA decrypt failures are indistinguishable.
Was ROBOT only theoretical?
No. Researchers demonstrated exploitable oracles on widely deployed servers and worked with vendors through coordinated disclosure before public release.
References
Explore authoritative guidance and frameworks related to robot attack.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.