BEAST Attack on SSL

In Sept. 2011 security researchers demonstrated how a previously known CBC encryption weakness could be used to decrypt HTTP data over SSL. The attack was named BEAST (Browser Exploit Against SSL/TLS). As with previous man-in-the-middle SSL vulnerabilities, the attack is generally considered a very low risk for individual browsers as it requires the attacker to have control over the network. Additionally, in this specific exploit they will also have to have a mechanism to elicit known HTTPS responses from the client. Most MatrixSSL users do not fall into the category of vulnerable uses.

Solutions

1. MatrixSSL 3.2.2 - Released on October 7th, version 3.2.2 includes a fix to thwart this attack for client implementations. The solution has been implemented internally to the library and uses an IV obfuscation technique by breaking up each application data record in two. The first being just a single byte of the plaintext message, the second containing the remainder. This is the same approach the Chrome team at Google introduced in their solution to the issue. This fix is enabled by default for clients that are using SSLv3 or TLS1.0 coupled with a CBC block cipher.
2. MatrixSSL 3.2.* - This exploit can also be thwarted simply by using TLS protocol version 1.1 or by using a cipher suite that implements a stream cipher such as SSL_RSA_WITH_RC4_128_SHA. TLS 1.1 is enabled by default in MatrixSSL 3.2 and above and will be negotiated to if the peer also supports that version.
3. All MatrixSSL Versions - A zero length record proceeding a data record has been a known fix to this problem for years and MatrixSSL has always supported the encoding and processing of empty records. Current MatrixSSL users can manually add this fix to existing versions by simply calling matrixSslEncodeWritebuf with a 0 length prior to encoding the actual application data. It should be noted that some SSL implementations do not handle 0 length records and this is the primary reason this solution did not become widespread.

Session Expiry Times

Update: Fixed in 1.1

Background
SSL session resumption allows session keys to be cached after a session is closed. Future sessions can be negotiated much more quickly, without an expensive private key operation with this functionality. MatrixSSL does not automatically flush cached session information based on a fixed time period.

Solution
Sessions are deleted based on their age in the session cache; once it is full, the oldest unused session data is deleted and must be re-negotiated by a client reconnecting. Cache entries are also cleared if there was an error on the SSL connection of any kind, or if the SSL server process is restarted. ARC4 cipher data throughput is also monitored to force re-keying after a maximum safe amount of data is encrypted (MatrixSSL block ciphers do not require this restriction). A future MatrixSSL release will prevent the lookup of sessions that are "stale" by a predetermined period (several days) time.

Workaround
The session cache may be periodically flushed manually if desired by the calling application.

RSA Blinding

Update: Fixed in 1.1

Background
MatrixSSL does not currently support RSA Blinding, a technique used to combat a specific timing attack against the RSA math operations. Information on the RSA timing attack is available in this PDF. The attack works by sending millions of specific handshake messages to an SSL server and measuring the response times. If network latency variations are low, the time taken to do the RSA operation on each handshake can be used to statistically determine the RSA private key.

Solution
The most well regarded solution for this issue is to "blind" the operation by including a calculation based on random data for each RSA operation. This will make it impossible to guess the keys based on timing the operation. We are looking to provide this solution on a future MatrixSSL release.

Workarounds
In the short term, a workaround that is suitable for many embedded devices is to throttle the number of SSL connections per second to limit the number of attack messages that can be sent. Alternately, forcing the response time for the handshake message to, for example, 100ms can provide blinding as well.

Certificate Validation Limitations

Update: Fixed in 1.0

Support for certificate validation is limited in the beta release. Certificates are validated either as self signed or as signed by a single parent root CA if specified in the matrixSslReadKeys() API.

The certificate contents are parsed but not currently accessible to the client application, so validation on expiration date or certificate name are not supported.

The next release of MatrixSSL will expose the parsed certificate through an API which will allow application level validation.

Beta Software Disclaimer

Applies to: MatrixSSL 1.0 Beta

This beta software is currently undergoing public evaluation and security audit. Please contact support before using this code in production systems.