On Dec 12th, 2017, researchers Hanno Böck, Juraj Somorovsky and Craig Young published a paper detailing an attack they called the Return Of Bleichenbacher's Oracle Threat (ROBOT)(https://eprint.iacr.org/2017/1189). This attack, as the name implies, is an extension of an attack published in 1998 (https://link.springer.com/content/pdf/10.1007%2FBFb0055716.pdf) that affects systems using certain implementations of RSA key exchange.
Customers have voiced concerns about this threat and asked how Akamai can help. Customers that use Akamai services are protected from this attack, because Akamai uses OpenSSL on all of our Edge servers, instead of the vulnerable implementation this threat targets. Since RSA key exchange is not used, this attack will fail against the Akamai Edge. An attacker communicates with an Edge server first, so the Akamai network prevents vulnerable origin servers from ever seeing the ROBOT attack. Additionally, customers who use Site Shield are protected from any related scanning and exploitation attempts as all requests will be forced through Akamai's Edge network.
There is one exception: Customers using the Akamai SRIP product should be aware the service proxies messages directly back to the customer's server and does not negotiate the key exchange. The ROBOT attack traffic would also be proxied in this manner and could result in a successful attack. Customers using SRIP need to patch vulnerable systems as quickly as their patching and risk mitigation processes allow.
The ROBOT attack works by allowing the attacker to to recover the plaintext from chosen ciphertext. In this scenario, the attacker queries the target server with an encrypted message. The server then decrypts the message and responds with 1 if the plaintext starts with 0x0002 or 0 otherwise. By modifying the messages sent, depending on the response from the server, the attacker can, over time, decrypt the ciphertext without obtaining the private key.. This attack is part of a family known as a chosen-ciphertext attacks.
In addition to the aforementioned exploit, this attack allows the attacker to sign arbitrary messages with the private RSA key of the server. Using a similar method, the attack treats the attacker's message as though it were eavesdropped ciphertext. Again the key is not stolen, but that attacker can still use it to sign messages. The researchers point out that this function is time consuming and only works on certain types of implementations.
The most important lesson to be learned from this attack is that current testing is insufficient and allows old vulnerabilities to work against modern TLS implementations. The paper's authors note how alarming it is they were able to successfully use a 19 year old attack with only simple modifications. The real solution is to fully depreciate RSA key exchange. While the current TLS 1.3 specification does so, legacy implementations and compatibility requirements will keep this attack and others a useful tool for years to come.