MatrixSSL 3.7.1

Security Fixes

• X.509 and ASN.1 Parsing Improvements - The Advanced Threat Research team at Intel Security discovered several issues as part of their research on the BERSerk attack on RSA signature verification. MatrixSSL does not contain this vulnerability which can result in a MITM attack, however some other ASN.1 fields were not consistently checked against remaining buffer length when parsed. These have each been fixed, and the getAsnLength() internal API now also does a double check against the remaining buffer length for variable length fields in all cases.
• Constant-Time Memory Compare - Calls to memcmp() have been replaced with a memcmpct() implementation to reduce the effectiveness of future timing based attacks.

New Features

• Application-Layer Protocol Negotiation - Implemented RFC 7301.
• X.509 RSASSA-PSS Signatures - MatrixSSL now supports the more secure RSASSA-PSS signature algorithm in X.509 certificates.
• Run-Time TLS Feature Control - Truncated HMAC use, Maximum Fragment Length requests, and Elliptic Curve specification can now be enabled on a per-session basis when creating a new session..

API Changes

• Several - Please see the release notes included in the package for details.

MatrixSSL Unaffected by SSL 3.0 POODLE Vulerability

Security Measures

• POODLE Vulnerability in SSL 3.0 - An attack against the SSL 3.0 random padding method for block ciphers was proven to be feasible. This was a known weakness and fixed in TLS 1.0 (SSL version 3.1), but only recently was attack code produced. MatrixSSL is not affected by the POODLE vulnerability: SSL 3.0 is disabled by default since version 3.3.1 on July 16, 2012. We recommend deprecating use of SSL 3.0 and moving directly to TLS 1.2.

MatrixSSL 3.6.2

Security Fixes

• ECC Key Validation - A security researcher reported that maliciously crafted ECDHE keys could be used to expose an error in the library that could cause an infinite loop or crash, on some platforms. ECDHE cipher suites are not enabled in the default configuration, however users that have enabled ECDHE cipher suites should update to the current version of MatrixSSL.
• AES-GCM Mode on Big Endian - Fixed a bug that was preventing the AES_GCM tag from being created correctly on big endian platforms.
• X.509 PathLen with Root Certs - Clients were incorrectly calculating the pathLen constraint in X.509 certificate chains when servers sent the root CA as part of the chain. It is not advised servers send the root CA but it is now handled correctly if those servers are encountered.

Other Changes

• Simultaneous Re-handshake - Clarified the behaviour if client and server sent a re-handshake simultaneously.
• Library Repackaging - The Makefile framework now generates three module libraries when compiling MatrixSSL: core, crypto and matrixssl. Previously these were packaged as a single library. This change makes it easier to share crypto and core libraries with other libs like MatrixSSH, MatrixDTLS and MatrixCMS.
• Additional Changes - See the relase notes in the package for a complete list of changes in this version.

MatrixSSL 3.6.1

Security Fixes

Note: - All versions of MatrixSSL are unaffected by the recent OpenSSL "Heartbleed" bug. That bug is due to an OpenSSL implementation error, not an attack against the SSL/TLS protocol.

• Explicit Length Testing in Parsing Code - A security researcher reported a 'length underflow' vulnerability, which led to an internal audit of message parsing in MatrixSSL. This identified a handful of places in which explicit tests were needed in areas that read 'length' bytes from message streams. The primary areas of change were the TLS extension parsing for ECC cipher suite parameters and Secure Renegotiation. The code now confirms values are within valid ranges to prevent underflow decrements of unsigned integer counters that would result in bad loop logic and could potentially cause a memory access violation.

MatrixSSL 3.6.0

This release aligns the commercial and GPL version numbers of MatrixSSL and moves most of the previously commercial only features into the GPL version.

Security Features

• Stronger X.509 Enforcement - Improved X.509 certificate parsing and validation. V1 and V2 certs no longer supported. Enforcement of critical extensions, certificate chain path length, subject alt name, AuthorityKeyIdentifier, minimum key strength and several other constraints. Moved date range parsing into X.509 library.
• Runtime Configuration of Ciphersuites - CipherSuite, TLS version and AllowResumption can now be set on a per SSL session basis.
• Heartbleed Bug - All versions of MatrixSSL are unaffected by the recent OpenSSL "Heartbleed" bug. That bug is due to an OpenSSL implementation error, not an attack against the SSL/TLS protocol.

New Features

• TLS 1.2 - Full support open sourced from commercial codebase.
• ECC Cipher Suites - ECDHE_ECDSA, ECDH_ECDSA, ECDHE_RSA and ECDH_RSA open sourced.
• DH Cipher Suites - DH, DHE and DH_anon open sourced.
• AES-GCM Cipher Suites - Full suite of GCM ciphers open sourced, optimized for Intel AES-NI extensions.
• Preshared Key Cipher Suites - Full suite of PSK ciphers open sourced.
• IDEA and Seed Ciphers - Open sourced.
• SHA-2 Hashes - SHA-256, SHA384, SHA512 and HMAC counterparts open sourced.
• Server Name Indication - SNI extension now supported.
• Stateless Session Tickets - Session Tickets now supported for cacheless session resumption.
• Session Cache Improvement - Very large session caches are now managed more efficiently and can effectively scale to memory constraints.
• Truncated HMAC - Truncated HMAC extension open sourced.
• ZLIB Support - Minimal SSL compression support, disabled by default for security reasons.

API Changes

• Several - Please see the release notes included in the package for details.

MatrixSSL 3.4.2

Bug Fixes and Improvements

• Improved Run-Time Checks of Certificate Algorithms Against Cipher Suites Checking the public key and signature algorithms of the certificate material during initialization and cipher suite negotiation is now stricter. Servers now look at the signature algorithm of their certificate when negotiating cipher suites to ensure the authentication mechanism is consistent with the cipher suite. This enables the handshake to fail early in the process if the certificate material does not support a requested cipher suite. This is mainly a protection against user configuration errors because a server should not enable cipher suites it isn't prepared to support. Clients now confirm the server certificate signature algorithm as a pre-emptive measure during the parsing of the CERTIFICATE message. Previous versions would terminate the connection later in the handshake process when the unsupported algorithm was encountered for the public key operation itself.
• SSL Alert Sent on Handshake Message Creation Failure Previous versions would silently terminate the SSL connection if handshake message creation failed. Now an INTERNAL_ERROR alert is sent before closing the connection.
• Expired Session Resumption Fix Fixed server support for scenarios in which a session that is already in a resumed handshake state will correctly fall back to a full handshake if the client attempts a resumed re-handshake after the session has expired in the server cache.
• Disable Yarrow by Default and Simplified PRNG Reseeding The USE_YARROW define is now disabled by default in cryptoConfig.h because the two default entropy gathering sources are PRNG sources themselves so it isn't necessary to run that data through Yarrow. This change will result in a minor connection speed improvement. If Yarrow is needed, the logic for reseeding that algorithm has been simplified to update only on the amount of data read rather than including the number of function calls to the PRNG retrieval function.
• Removed the USE_RSA Configuration Define The open source version of MatrixSSL only supports RSA cipher suites so the removal of that option makes this explicit.
• Example Applications Load Full CA List To aid in testing, the example client and server applications now load the full list of sample Certificate Authority files so a recompile is not needed if changing the sample certificate material of the peer.

MatrixSSL 3.4.1

Security Features

• Lucky Thirteen Countermeasure - An attack against block cipher padding was proven to be feasible. This affects CBC ciphers including AES and 3DES. This update adds timing countermeasures that reduce the effectiveness of this attack.

MatrixSSL 3.4.0

Security Features

• Certificate Revocation List (CRL) - Two new APIs have been added to support CRLs. If a Certificate Authority uses the CRL Distribution Points extension to identify the URI where a CRL can be found, use the new matrixSslGetCRL API to aid in the fetch. If a local CRL is available use the matrixSslLoadCRL API to register the revoked certificates with the CA for testing during the SSL handshake. The client example application implements these two new APIs as a reference..
• Client Certificate Authentication - This has been a feature in the commercial MatrixSSL release for some time. Client Certs are being deployed more often now, so we were asked by some open source users to include this feature under GPL. Enable the USE_CLIENT_AUTH define in matrixsslConfig.h to add support for this feature to the library. Clients and servers are both supported and the example applications implement client authentication for reference. The sslTest utility will exercise the client authentication handshake variations as well.

New Features

• Assembly Language Opimizations - Assembly code optimizations that were previously only available in commercial versions of MatrixSSL are now included in the open source packages. Optimizations for common processors such as ARM, x86, x86_64, and MIPS32 can now be enabled with the use of compile-time defines. RSA operations gain a significant speed advantage using these optimizations.

Public API Changes

• Client management of the session ID for resumption is now more explicit. The new matrixSslNewSessionId and matrixSslDeleteSessionId APIs enable library control of the sslSessionId_t parameter used in matrixSslNewClientSession. Refer to the API documentation for more details.
• An additional parameter has been added to the matrixSslNewServerSession and matrixSslNewClientSession APIs for compatibility with MatrixDTLS packages. For SSL usage, the final parameter should be 0 to both of these functions.
• This function prototype previously used a void return value. This change to an int return type was made simply to keep the core/ module APIs consistent.

Bug Fixes and Improvements

• X.509 certificate parsing now includes separate time format fields for the notBefore and notAfter identifiers. UTCTIME and GENERALIZEDTIME are still supported. However, it is not correct to assume both must be the same type. The psX509Cert_t structure accessible through the certificate callback will contain notBeforeTimeType and notAfterTimeType members instead of timeType.
• The alert type and description were not correctly passed to the user via matrixSslReceivedData when the TLS 1.1 protocol was being used.
• The length parser in the internal X.509 parseGeneralNames function assumed values less than 255. All lengths are supported now. Optional Attributes in a PKCS#8 format are now properly recognized. The PKCS#12 key generation algorithm is now more flexible. Previous implementations assumed a salt length of 8 bytes. Salts may now be up to 20 bytes. Also, certificates will be re-ordered in a child-to-parent hierarchy after the parse is complete.

MatrixSSL 3.3.1

Security Features

• Fine Grained TLS Version Support - USE_TLS_* configuration options now allow for specifying only TLS 1.1, or only TLS 1.2 support for users with very strict security policies. TLS 1.1 and above support explicit-IV and so it may be desirable to limit negotiation to only this version and above. SSL 3.0 is now disabled by default in compile time, and if required must be manually be enabled by commenting out the define for DISABLE_SSLV3 in matrixsslConfig.h

• RFC 4366 - Maximum Fragment Length Extension The max_fragment_length extension defined in RFC 4366 has been added to MatrixSSL. This extension allows TLS clients to suggest the maximum record size that can be used in communications with a server. Support for this extension has been added to both MatrixSSL clients and servers. The new define REQUESTED_MAX_PLAINTEXT_RECORD_LEN in matrixsslConfig.h has been added to control this feature. Small footprint clients can see significant socket buffer memory reduction when negotiating this option.

Public API Changes

• The API for raw RSA encryption now has an additional parameter.

Bug Fixes

• Fixed issue with ARC4 ciphers related to multiple records in a single network buffer. Previously, the connection could be incorrectly closed prematurely in some cases.
• Fixed a compile issue with MATRIX_USE_FILE_SYSTEM on Windows platforms.
• Fixed an initialization issue with a potential double free in an error path loading an RSA key from disk. Affected users would have seen this error immediately upon initialization.

MatrixSSL 3.3

Security Feature

• Rehandshake Denial of Service - A denial of service attack against SSL servers was uncovered where a malicious client could repeatedly ask for a rehandshake at very low cpu cost to itself but at high CPU cost to the server (due to the private key operation).

  New compile-time defines DEFAULT_RH_CREDITS and BYTES_BEFORE_RH_CREDIT have been added to matrixsslConfig.h to reduce the number of allowable re-handshakes per connection. This feature is enabled by default.

  As with previous SSL vulnerabilities, this DOS attack has been known since the early days of SSL, but it had not been applied until recently.

• The sample SSL server now utilities False Start support within MatrixSSL to allow the Google Chrome browser to connect. Support for False Start has been available in MatrixSSL since version 3.1.4 but the sample server was not taking advantage of this feature.
• All file headers and documentation updated and branded to reflect the AuthenTec acquisition of PeerSec Networks and MatrixSSL.

Public API Changes

• None.

Bug Fixes

• None.

PeerSec Acquired

AuthenTec Acquires PeerSec Networks to Strengthen Leadership in Embedded Security

Combination of AuthenTec QuickSec® and PeerSec Matrix™ Product Lines Creates Comprehensive Embedded Secure Networking Portfolio

Read more...

MatrixSSL 3.2.2

Security Feature

• BEAST Vulnerability - 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).

  A new compile-time define USE_BEAST_WORKAROUND has been added to matrixsslConfig.h to thwart the attack. It is enabled by default.

  As with previous 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 to become a MIM. They will also have to have knowledge of the first couple blocks of underlying plaintext in order to mount the attack.

  A zero length record proceeding a data record has been a known fix to this problem for years and MatrixSSL has always supported the handling of empty records.

  This BEAST fix is on the sending side and moves the implementation down to the SSL library level so users do not need to manually send zero length records. This fix uses the same IV obfuscation logic as a zero length record by breaking up each application data record in two. The first being just a single byte of the plaintext message.

  This issue only effects TLS 1.0 (and SSL) and only if the cipher suite is using a symmetric CBC block cipher. Enable USE_TLS_1_1 above to completely negate the need for any workaround if TLS 1.1 is also supported by peers.

• PKCS#12 Key Parsing - Support for parsing the most common PKCS#12 formats has been added to this version of MatrixSSL. PKCS#12 is the recommended format for securely storing certificates and their associated private key in the same file. The parsing has been introduced through the new public API matrixSslLoadPkcs12 and should be used as a replacement for matrixSslLoadRsaKeys where appropriate. Please see the full details of this new function in the API documentation.
• RC2 Cipher Added - PKCS#12 formats often encrypt the public certificate using the legacy RC2 cipher. This should be the only reason to enable this outdated and insecure algorithm.
• ASN.1 Parser Accepts Indefinite Length Formats - The addition of PKCS#12 uncovered the use of indefinite length encoding. Low level calls to getAsnLength will now return ASN_UNKNOWN_LEN rather than an error beginning in this release.

Public API Changes

• x509SubjectAltName_t structure renamed to x509GeneralName_t - This structure type has been renamed to reflect the correct generic X.509 type rather than the specific Subject Alternate Name (SAN) of a certificate. This change should have a very low impact as this structure type was never a direct parameter to any public API. This structure type is currently only used as the san member in the x509v3extensions_t which a user might be examining as part of the custom validation of a certificate in the certificate callback function. See the section The Certificate Validation Callback Function in the API document for full details.

Bug Fixes

• Server Clears Session Entry On Failed Handshakes - An issue was discovered in which the server would leave a partial session resumption entry in its table even though the initial handshake with the client failed. If the client, for some reason, choose to use that session ID in subsequent CLIENT_HELLO messages, the server was locating the entry and attempting a resumed handshake with an erroneous master secret. Of course, the connection would not succeed since the secret was not correct between the peers but the server should not have been finding the entry to begin with. The table entry is now removed on handshake failures.
• AES Cipher Contexts Internally Zeroed - An issue was discovered in which the standalone use of the AES cipher could fail if the initialization function was called with a context structure that contained non-NULL data. The key initialization functions now internally memset the context structures to 0x0 to prevent this problem.
• No Double Frees When Deleting Key Material After Errors - An issue was discovered in which a call to matrixSslDeleteKeys after the failure of matrixSslLoadRsaKeys would perform a second memory free on data members that had been handled in the error cases of matrixSslLoadRsaKeys itself. The error handling internal to matrixSslLoadRsaKeys will now NULL any freed memory to prevent this problem.

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.

MatrixSSL 3.2

Feature Updates

• Added TLS 1.1 protocol support - TLS 1.1 protocol support is now available in the open source version of MatrixSSL. The protocol is enabled/disabled through the compile time define USE_TLS_1_1 in matrixsslConfig.h. If enabled, the protocol negotiation will default to TLS 1.1 for any communicating SSL peer that also supports it. It is also now possible to disable SSL 3.0 using the DISABLE_SSLV3 define if only TLS version protocols are desired.
• Added PKCS#8 private key parsing - The PKCS#8 standard is becoming more widespread for newly issued private keys. PKCS#8 parsing is now included by default in the open source version of MatrixSSL. This support is built into the existing matrixSslLoadRsaKeys API.
• IN and OUT default buffer sizes - Previous versions of MatrixSSL used a single compile time setting for the default internal input and output buffers. This define has now been split into SSL_DEFAULT_OUT_BUF_SIZE and SSL_DEFAULT_IN_BUF_SIZE defines to give the user more memory control for the specific use case. For example, if the integrator knows that incoming data will be short requests and the outgoing reply data will be large files, the SSL_DEFAULT_IN_BUF_SIZE may be set smaller that SSL_DEFAULT_OUT_BUF_SIZE to help streamline this implementation.
• Zero length SSL records now returned to user - Callers of matrixSslReceivedData will now be informed of zero length SSL records with the standard return code of MATRIXSSL_APP_DATA and length values of 0. Previous versions of MatrixSSL would silently discard empty records.

Public API Changes

• Added matrixSslEncodeToOutdata - An SSL record encoding alternative to the existing matrixSslGetWritebuf/ matrixSslEncodeWritebuf combination has been introduced. The new matrixSslEncodeToOutdata enables integrators to encode plaintext from where it exists in an external memory location. This differs from the matrixSslEncodeWritebuf API that requires the plaintext has been written or copied into the internal library buffer. The new matrixSslEncodeToOutdata function will leave the plaintext buffer untouched while encoding to the internal library buffer. The encoded data is still retrieved for sending using matrixSslGetOutdata. Please see the API documentation for more information on this new function.

Bug Fixes None reported.

MatrixSSL 3.1.4

Feature Updates

• Primary crypto algorithms now have configuration options for size vs. speed tradeoffs - Previous versions of MatrixSSL had an undocumented compile time define (SMALL_CODE) that influenced the binary code size of some symmetric cipher algorithms. Each algorithm that used this define has now been given its own define to control whether the user wants to build the library for faster algorithm support at the cost of an increased binary code size. The size vs. speed tradeoff is platform dependent but, in general, the speed improvements will be about 5%-10% at the cost of 10-20KB for each algorithm. The default, in each case, is that these defines are disabled in cryptoConfig.h to compile in favor of smallest binary footprint.
• RSA algorithm now has configuration option for memory usage vs. speed tradeoff -A pair of defines have been added to determine whether the RSA algorithm should be compiled for smaller RAM usage or faster performance. The default is to compile for smaller RAM usage.
• Servers can now disable specific cipher suites at runtime - Cipher suites that have been compiled into the library can now be programatically disabled (and re-enabled) on a per-session basis. This is useful for servers that wish to limit the supported ciphers suites for a specific connecting client. A new API, matrixSslSetCipherSuiteEnabledStatus, has been added to support this functionality. Please see the MatrixSSL API documentation for detailed information on this new feature.
• An Xcode project for iPhone development is now included - In the apps/iphone directory the user can now find a Mac Xcode project for developing SSL/TLS client applications for the iPhone.
• Server compatibility with Chrome browsers that use "false start" - The Google Chrome browser has introduced a new protocol mechanism called “false start” that is incompatible with strict TLS implementations that do not allow application data exchange before the handshake protocol is complete. Enabling ENABLE_FALSE_START in matrixsslConfig.h will allow newer versions of the Chrome browser to connect with MatrixSSL servers. Enabled by default.
• A new explicit int16 data type has been added - The osdep.h file now includes a typedef for a 16-bit integer type called int16. The initial internal use of this new data type can be found in the pstm.c math function to help improve performance on some platforms.
• Updated for Luminary Micro/TI Stellaris examples - Updated to support the new release of secure web server examples for the ARM Cortex-M3.

Public API Changes

• Compile-time define for file system support has been renamed - The USE_FILE_SYSTEM define has been renamed to include a PS_ prefix so that it is now PS_USE_FILE_SYSTEM. In addition, this define is no longer present in the coreConfig.h header file. It should be included in the platform build environment as a compile-time define if file system support is needed.
• Return types changed for osdep.c Open and Close routines - The platform interface functions implemented in osdep.c have undergone prototype changes.

Bug Fixes None reported.

MatrixSSL 3.1.3

Feature Updates

• New server-side configuration option to decrease binary executable size - Servers may now disable a new USE_CERT_PARSE define in crytpoConfig.h to exclude a relatively large portion of the x509.c source code.

  Previous versions of MatrixSSL would always pass the server certificate through an X.509 parse phase during initialization. This allowed the library to confirm the format of the certificate and perform algorithm tests based on the chosen cipher suite. However, these tests were in place primarily to prevent user error so if USE_CERT_PARSE is disabled, the user must be confident the certificate material is valid for the cipher suites that have been enabled in matrixsslConfig.h.

• New Pseudo-Random Number Generation algorithms -An implementation of Yarrow is now included in the MatrixSSL source code package. Random numbers are now retrieved through Yarrow by default. An entropy source and implementation of psGetEntropy is still required for each platform.
• Windows project files updated to Microsoft Visual C++ 2010 Express - Previous versions used the 2008 Express Edition of Visual C++.

Public API Changes

• New members in x509DNattributes_t structure - The Distinguished Name attributes in X.509 certificates such as Common Name, Organization, and Country are now accompanied by the explicit ASN.1 data type and length. Previous versions of MatrixSSL attempted to treat these fields as NULL terminated strings using single byte characters. In order to support a larger variety of certificate formats the Type and Len fields have been added so the user will have all the needed information to interpret certificate information that is passed into the certificate callback routine.

  New x509DNattributes_t members:

  short countryType;
  short countryLen;
  short stateType;
  short stateLen;
  short localityType;
  short localityLen;
  short organizationType;
  short organizationLen;
  short orgUnitType;
  short orgUnitLen;
  short commonNameType;
  short commonNameLen;

  Type members will be one of the following:
  

  ASN_PRINTABLESTRING
  ASN_UTF8STRING
  ASN_IA5STRING
  ASN_T61STRING
  ASN_BMPSTRING

Bug Fixes

• Error return code fixed for matrixSslReceivedData - One code path through matrixSslReceivedData was performing an ‘unsigned char’ typecast on a potentially negative return code which converted it to a positive value. This resulted in an undocumented and ambiguous return code. The typecast has been removed and all error cases now return negative values as documented.

MatrixSSL 3.1.2

Feature Updates

• Explicit API support for processing multi-record data buffers - The 3.1.1 API set did not include a documented mechanism for processing buffers in which multiple application data records are concatenated in a single ‘recv’ buffer. This is not an uncommon scenario and users are strongly encouraged to update to this latest MatrixSSL version and implement the new matrixSslProcessedData function in their applications. Details can be found in the updated API documentation included in this package.
• MatrixSSL version defines added - A version.h file has been added that includes defines for the MatrixSSL major, minor, and patch build version. The new header is included by matrixsslApi.h and defines the full version and the individual components. For example:

  #define MATRIXSSL_VERSION       “3.1.2-OPEN” 
  #define MATRIXSSL_VERSION_MAJOR	3 
  #define MATRIXSSL_VERSION_MINOR	1 
  #define MATRIXSSL_VERSION_PATCH	2
  #define MATRIXSSL_VERSION_CODE	“OPEN”

• The sslTest application includes a timing mode - The sslTest application can now be built to measure the connection speeds for clients and servers for the various cipher suites.
• Improvements to HTTP parsing in example application code - The server and client example applications now identify partial and multi-record HTTP records.

Public API Changes

• New matrixSslProcessedData prototype and return codes - To support the processing of multi-record data buffers, the matrixSslProcessedData function prototype and return codes have changed. The new function has two additional parameters that are used to return the next decoded record in the buffer. The return codes for this function have been expanded to inform the user how that second record should be handled.

  Please see the API documentation and code examples for detailed information.

Bug Fixes

• Fixed return codes where unsigned data types were assigned negative values - The functions psRsaDecryptPriv, psRsaDecryptPub, and matrixSslDecode are now consistent in their use of unsigned vs. signed data types.

MatrixSSL 3.1.1

Feature Updates

• Secure Renegotiations - Turn re-handshaking support back on, MatrixSSL users! Beginning in version 3.1.1 support for the recently published TLS Renegotiation Indication Extension (RFC 5746 ) is included. SSL/TLS renegotiations enable servers to fine tune the security parameters or access controls for individual clients without having to reconnect. MatrixSSL enabled clients and servers now support the "renegotiation_info" extension and the TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling cipher suite to prevent any possibility of the "plaintext injection attack" that was disclosed November 2009 and described in CVE-2009-3555.
• CLIENT_HELLO extension support - Support for adding extensions to CLIENT_HELLO messages is now included in the open source version of MatrixSSL. More information on hello extensions can be found in RFC 3546.
• Client cipher suites on re-handshakes - Clients will now resend the full list of supported cipher suites on server-initiated re-handshakes. In previous versions, upon receiving a HELLO_REQUEST from a connected server, the client would only supply the cipher suite that was currently negotiated in the CLIENT_HELLO.
• Makefile auto detects 32 and 64 bit platforms - The top level Makefile now detects whether 32 or 64 bit Linux or Mac OS X is running, and sets some defines appropriately to optimize performance for 64 bit platforms.
• New documents - Migration to 3.1 and OS Porting Guide

Public API Changes

• New matrixSslNewClientSession prototype - An additional parameter has been added to this routine to improve hello extension support. Clients can now register a callback that will be invoked during the SSL handshakes to parse any SERVER_HELLO extensions that might be sent by the server.
• USE_INT64 renamed to HAVE_NATIVE_INT64 - This define in coreConfig.h has been renamed for clarity.

Bug Fixes

• Changing Cipher Suites on Re-handshake - A handshaking failure was discovered during re-handshake testing in some cases where the underlying cipher suite was changing, resulting in an invalid SSL Alert and connection close. This has been fixed as part of the overall handshake protocol change.
• Default size for pstm_digit - The default 32-bit platform now explicitly sets the psmt_digit type as a 32-bit unsigned integer rather than an unsigned long. This fixes a compile issue witbh running with 32-bit math on a 64-bit platform.

MatrixSSL 3.1

Major Revision and Feature Updates

• Celebrating 8 years of MatrixSSL! - New 3.x version of Open Source matches Commercial versioning.
• TLS 1.0 Protocol Support - Beginning in MatrixSSL 3.1 the TLS 1.0 protocol and AES cipher are now available in open source releases.
• Improved API - It is now easier than ever to integrate SSL into your application. MatrixSSL has always provided SSL integration to applications at a data buffer level to guarantee support for any given transport mechanism. Previous versions, however, left the management of these data buffers in the hands of the integrator. The new MatrixSSL 3.1 API incorporates size-optimized buffer management so the user is left only with the task of determining when data needs to be read or written, while still maintaing a transport-neutral, zero buffer copy API.
• Faster and Smaller RSA Cryptography - The public key cryptography operations required for RSA mathematics are the primary contributors to high water memory and CPU resources during the SSL handshake. MatrixSSL 3.1 includes specific optimizations that have resulted in major improvements to both speed and memory usage during public cryptography. These substantial memory savings and performance improvements allow MatrixSSL to be used on an even larger number of embedded platforms. The entire SSL handshake, including network buffers can now be completed in as little as 10KB of RAM, with a post-handshake dynamic memory footprint of less than 3KB.
• File and Functional Reorganization - The MatrixSSL 3.1 source code package has been organized to better reflect the individual functional areas. The core and crypto modules are now clear building blocks on which MatrixSSL relies and each module has an API and Configuration header to manage optional features and functionality.
• New Supported Client and Server Applications - New client and server examples are now provided as a starting off point for customer integration or new application development. The client application is an example of a simple, blocking sockets API HTTPS client that prints the response to a HTTP GET request. The server example demonstrates a non-blocking HTTPS server that handles multiple connections and session timeouts. The MatrixSSL API usage for both applications is very similar, and should help clarify how to integrate MatrixSSL with other applications.
• New Test Application - A SSL/TLS protocol test application is now included in the package so that new ports of MatrixSSL can quickly be verified and functionally tested, even before integration with a sockets layer. The application creates virtual SSL connections within a single process using memory buffers as the transport layer. Each supported cipher suite and handshake mode are validated.
• Additional Project File Formats - Project files for the MatrixSSL library, example and test applications are now provided for Microsoft Visual Studio Express Edition, Apple Xcode and standard GNU make. Projects for the Eclipse IDE can be directly imported from GNU Makefile.

MatrixSSL 1.8.8

Protocol Security Updates

• A security exploit around SSL re-negotiation has been discovered. This is a protocol level flaw, and affects all SSL and TLS implementations. The protocol sitting above SSL may or may not be affected. For example, HTTPS with keep-alive support on authenticated connections IS affected. MatrixSSL disables re-negotiation for server side SSL in this release, protecting secure servers from attack. When using MatrixSSL for client connections, care should be taken to only connect to SSL servers that have re-negotiation disabled.
• More information: HTTPS/SSL Attack Vector Discovered