The first vulnerability, published in February, can potentially be used to decrypt data blocks from an SSL conversation. Data in an SSL channel must often be padded to match the block size of the encryption cipher used, and this padding is in a particular format. Essentially, OpenSSL would finish processing a block quicker when it detected an error in the padding (because it would not spend time performing other checks on the block) – and this difference is measurable on a good network (“Password Interception in a SSL/TLS Channel”). This creates an information leak that can be used to extract the plaintext from an encrypted block, as shown by earlier research published in 2002 (“Security Flaws Induced by CBC Padding”). The fix from the OpenSSL team causes OpenSSL to verify other aspects of the received block even if the padding is wrong, so there is no timing difference for an attacker to use (OpenSSL advisory); the fix is included in OpenSSL 0.9.6i and 0.9.7a.

A second attack was reported in March, also using the response of the server to errors to reveal information. It builds on an attack reported in 1998 against the PKCS encoding used for data before encryption – old SSL implementations would reveal whether decoded data met the expected PKCS format. Submitting bad data and seeing whether it decrypted to a valid PKCS header reveals information to an attacker about the private RSA key. This information leak was fixed, but the developers overlooked an extension used in SSL, where the first two bytes of the payload contain the SSL version number, also validated by the server; again this can be used to reveal information about the decryption key for the session (“Attacking RSA-based Sessions in SSL/TLS”). The OpenSSL team has now published a patch that treats a failure of the version check in the same way as a failure of the PKCS header (advisory).

An attack was also reported during March that could allow the secret key to be extracted by observing timing differences in the response to packets (“Remote timing attacks are Practical”). This attack works best locally, but is possible over a good network too; it takes typically around a million queries to the server to extract the key. It exploits differences in the time that it takes to decrypt data with the server’s private decryption key according to the exact value of the data and the key: some of these differences are due to optimisations performed by OpenSSL, but even without these it is hard to avoid slight differences in timing depending on the key value.

The most robust solution to this problem is “RSA blinding”: the server multiplies the data to be decrypted by a random number before decryption, and reverses this after decryption, so any timing variations in the operations involving the private key will depend on this random number that is unknown to the attacker, preventing them deducing anything about the private key. Some other SSL products already use RSA blinding; a number of vendors of OpenSSL-based products are now coming out with patches to enable RSA blinding, and the latest OpenSSL releases now enable blinding by default (OpenSSL advisory). There is a performance penalty for using RSA blinding, due to the extra calculations involved, but it is estimated to be less than a 10% loss in performance, which is a small price to pay for security.

The RSA timing attack requires a local account or a good network connection, so this will be most threatening for hosting companies and internet datacenters where third parties will have access to the server or closely connected machines on the same network. Of the three vulnerabilities, it also has the most serious consequences: whereas the other two attacks reveal data from one particular session, this attack reveals the main RSA key, potentially compromising all SSL sessions. The block padding attack, while potentially serious, is limited because it only affects block ciphers, whereas most browsers use stream ciphers (where no padding is needed). The PKCS attack is more theoretical, as it requires enormous effort to decrypt a small amount of data. Fixes for all three attacks are included in OpenSSL versions 0.9.6j and 0.9.7b.

Due to the openness of its source code, OpenSSL has become the target of choice for many researchers into both the theoretical security of SSL, and the security in practice of its implementation. Linux users are benefiting from this research as the OpenSSL team continues to improve the code in the light of these attacks. Other SSL implementations may be affected by at least some of these attacks, however: the paper about the PKCS attack examined a random sample of public sites and found that around two-thirds appeared to be vulnerable to this attack, so this at least seems to affect more than just OpenSSL sites. It remains to be seen whether other vendors of SSL implementations will issue patches for these attacks. Hopefully they are not ignoring these important issues just because their own products were not specifically named.