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.