• 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.

• 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.

• 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.

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

Read more...
]]> 165@http://www.matrixssl.org/ Announcements 2011-12-06T06:50:56-08:00 http://www.matrixssl.org/archives/000163.html 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.

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.

• 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.
]]> 162@http://www.matrixssl.org/ Releases 2011-06-07T15:57:36-08:00 http://www.matrixssl.org/archives/000161.html 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.
]]> 161@http://www.matrixssl.org/ Releases 2011-01-11T15:15:04-08:00 http://www.matrixssl.org/archives/000160.html 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.

• 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.

• 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.

• 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.

• 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

• Windows project files for library and example application builds are now based on the freely available Microsoft Visual Studio C++ 2008 Express Edition

• The USE_MULTITHREADING define in matrixConfig.h is now off by default so that POSIX platforms will not require pthreads by default.

• Fixed the size calculations for SSL_FULL conditions when encoding the FINISHED flight of handshake messages
• Additional checks and proper error handling for the following types of malformed X.509 certificates as tested by Orange Labs. These do not constitute a remote attack vector for the Open Source release.
  • Testing for Serial Number encodings that use bad length specifications
  • Testing for Distinguished Name extension encodings that use bad length specifications
  • Error handling for Subject Alternate Name extensions that use bad length specifications

• The matrixRsaParsePubKey routine has added support for X.509 SubjectPublicKeyInfo formatted keys
• Full parsing support of the subjectAltName extension in certificates

• Allowing clients to send multiple compression parameters in the CLIENT_HELLO message
• The matrixX509ReadCert routine supports additional PEM file header and footer formats

• Corrected filename misspelling in httpsReflector.c for loading example CAcertCln.der certificate

• Internal API change to accommodate MatrixSSH users.

• Ignore TLS extensions sent with SSL 3.0 ClientHello. Thunderbird sends these extensions if negotiating down from a TLS connection, even though they are meaningless.
• Enhanced the parsing of the Key Usage certificate extension.

• Assure file reads into memory are NULL terminated. This was an issue flagged by Valgrind that doesn't present a problem in practice.
• 2008 copyright update.

• MatrixSSL 1.8.4 was not a public release.