July 16, 2012
MatrixSSL 3.3.1
Releases
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.
New Features
- 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.
February 22, 2012
MatrixSSL 3.3
Releases
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.
Feature Updates
- 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
Bug Fixes
October 07, 2011
MatrixSSL 3.2.2
Releases
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.
Feature Updates
- 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.
June 07, 2011
MatrixSSL 3.2
Releases
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.
January 11, 2011
MatrixSSL 3.1.4
Releases
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.
September 02, 2010
MatrixSSL 3.1.3
Releases
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.
May 28, 2010
MatrixSSL 3.1.2
Releases
Feature Updates
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.
April 15, 2010
MatrixSSL 3.1.1
Releases
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.
March 08, 2010
MatrixSSL 3.1
Releases
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.
November 10, 2009
MatrixSSL 1.8.8
Releases
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
June 24, 2009
MatrixSSL 1.8.7
Releases
New Features
- Windows project files for library and example application builds are now based on the freely available Microsoft Visual Studio C++ 2008 Express Edition
Functional Changes
- The USE_MULTITHREADING define in matrixConfig.h is now off by default so that POSIX platforms will not require pthreads by default.
Fixes
- 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
September 10, 2008
MatrixSSL 1.8.6
Releases
New Features
- The matrixRsaParsePubKey routine has added support for X.509 SubjectPublicKeyInfo formatted keys
- Full parsing support of the subjectAltName extension in certificates
Functional Changes
- Allowing clients to send multiple compression parameters in the CLIENT_HELLO message
- The matrixX509ReadCert routine supports additional PEM file header and footer formats
Minor Fixes
- Corrected filename misspelling in httpsReflector.c for loading example CAcertCln.der certificate
March 11, 2008
MatrixSSL 1.8.5
Releases
API changes
- Internal API change to accommodate MatrixSSH users.
Functional changes
- 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.
Bug fixes and optimizations
- 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.
Notes
- MatrixSSL 1.8.4 was not a public release.
February 07, 2007
MatrixSSL 1.8.3
Releases
API changes
- ‘const’ qualifiers added to literal string parameters for matrixRsaReadPrivKey, matrixRsaReadKeys, matrixRsaReadKeysEx and matrixX509ReadPubKey.
Functional changes
- Additional error reporting in RSA public decryption routine.
Bug fixes and optimizations
- Improved the enforcement of maximum certificate chain length.
- Added the –fPIC compile option to default POSIX builds.
- Fixed one time memory leak on error conditional during certificate parsing.
- 2007 copyright update.
October 05, 2006
MatrixSSL 1.8.2
Releases
API additions
Functional changes
- New "leaky bucket" algorithm for empty message denial-of-service countermeasure. Previously, the count of empty messages was continually being incremented by the MatrixSSL library regardless of any interleaving valid messages. This could potentially cause the connection to be closed if a peer was sending many blank SSL messages. The count will now decrement on valid messages. This change is most relevant to use-cases that involve an OpenSSL client communicating with a MatrixSSL server, as these clients tend to periodically send a blank record.
Bug fixes and optimizations
July 11, 2006
MatrixSSL 1.8.1
Releases
API additions
Functional changes
- Cleaner POSIX cross platform compiles for newer versions of Linux.
- Build support for Intel Macs (tested on OS X 10.4 CoreDuo).
Bug fixes and optimizations
- Minor compile warnings fixed.
- Graceful handling when MAX_CHAIN_LEN limit is exceeded in certificate parsing.
- Added ASN.1 BMPSTRING format support to certificate parsing.
- Fixed matrixSslReadKeysMem so that private key parameter is optional.
- Fixed one time memory leak for client initialization issues that include non-parsable certificates.
July 11, 2006 |
Comments (0)
April 06, 2006
MatrixSSL 1.8
Releases
API additions
- Addition of two new server APIs that allow the user to add a custom flag value to client sessions. Servers may now assign persistant custom data to connected sessions that can be later retrieved from a session that was established with a session resumption handshake. See the API documentation for matrixSslSetResumptionFlag and matrixSslGetResumptionFlag for more details.
Functional changes
- Ability to put multiple certificates in a single PEM file.
- The handshake will now fail on an un-authenticated cert if no user validation callback has been defined with matrixSslSetCertValidator. It is still encouraged that a callback be registered.
- Users can now reply to a closure alert with a closure alert of their own using matrixSslEncodeClosureAlert. Previously, the SSL_CLOSED flag prevented this. Now only error cases will prevent the closure alert from being created.
Bug fixes and optimizations
- Numerous compile warnings fixed. Especially in the area of unsigned char / char type mismatches.
- Added explicit ‘void’ types to empty parameter functions.
- Fixed a bad shift operation in cipherSuite.c (no functional change).
- Fixed possible memory leak of pre-master secret if deleteSession called on some corner failure cases.
- Fixed compile and link issues when USE_FILE_SYSTEM was turned off in matrixConfig.h.
- Fix for unknown X.509 certificate extension parsing in which the extensions did not provide explicit data lengths in the encoding.
- Fixed parse issue with an empty AuthorityKeyIdentifier certificate extension.
- Created new sample certificates with updated dates.
April 06, 2006 |
Comments (0)
November 16, 2005
MatrixSSL 1.7.3
Releases
Bug fixes and optimizations
- Fixed issue with certificate extension parsing causing a cert with some unrecognized extensions to fail validation.
- Fixed requirement when USE_CLIENT_SIDE is enabled with ReadKeysMem - CA is no longer required.
November 16, 2005 |
Comments (0)
September 17, 2005
MatrixSSL 1.7.1b
Releases
Bug fixes and optimizations
- Fixed packaging issue causing a build error on Windows and Linux. No functional change from 1.7.1
September 17, 2005 |
Comments (0)
September 13, 2005
MatrixSSL 1.7.1
Releases
Bug fixes and optimizations
- Fixed certificate chain parsing bug where a valid certificate chain was marked as invalid under certain circumstances. The result of the fix is that more cert chain configurations are supported.
- Added support for cert validation when the server sends the Root CA cert in addition to the lower levels of the chain. Typically the Root CA cert is loaded into the client, and not sent by the server. We have encountered some deployments where the server does send the root CA as well, and now successfully validate this chain.
- Relaxed parsing of the CertificateSerialNumber field within AuthorityKeyIdentifier. Although officially defined as an ASN.1 INTEGER type, some certificate generators use a non-integer value. Parser now supports these technically incorrect datatypes.
September 13, 2005 |
Comments (0)
August 17, 2005
MatrixSSL 1.7
Releases
Overall changes
- Explicit support for anonymous RSA handshaking
- New APIs to support anonymous handshaking and re-handshaking over
existing connections with new key material
Functional changes
- Version updated from 1.2.5 to 1.7 to mirror commercial MatrixSSL versioning
- Directory and file reorganization
Bug fixes and optimizations
- Significantly accelerated RSA handshake speeds
- Additional parsing of X.509 certificate extensions
August 17, 2005 |
Comments (0)
April 04, 2005
MatrixSSL 1.2.5
Releases
Overall changes
- No API changes from 1.2.4 release
Functional changes
- Updated expiration date in sample certificates
Bug fixes and optimizations
- Remove unnecessary link to -lcrypto on Linux
- Fix prevTicks compatibility on non-i386 Linux platforms
April 04, 2005 |
Comments (0)
February 24, 2005
MatrixSSL 1.2.4
Releases
Overall changes
- No API changes from 1.2.2 release
- There was no public 1.2.3 release
Functional changes
- Client will reply with NULL cert message if client authentication is requested.
Bug fixes and optimizations
- Generate static libraries in addition to shared objects on Linux
- AMD64/Nacona x64 compile support on Linux
- Changed all instances of int types to int32 to be more explicit and to allow easy global redefinitions for porting
- Corrected the maximum message size limit to match the SSL specification
- Cert parse can handle duplicate distinguished name entries.
- ASN.1 parse fix for AlgorithmIdentifier missing the trailing NULL
- Checking certificate version before doing checking the 'ca' member of the basic constraint entry during certificate validation.
- Developers may notice some internal routines using a psPool_t parameter. These parameters allow deterministic memory support in the commercial version of MatrixSSL. They are unused in the GNU version of MatrixSSL.
February 24, 2005 |
Comments (0)
September 23, 2004
MatrixSSL 1.2.2
Releases
Functional changes
- Added legacy certificate support
- for certificates without basic constraints
- MD2 support for older certificates (Because it is a less secure algorithm, it must be explicitly enabled).
Bug fixes and optimizations
- Sanity check against invalid key lengths from certificate (potential DOS fix)
- Fixed 64 bit issue with mpi.c
- Fix potential leak in certificates with duplicate fields
- Allow application data parsing within re-handshake state
September 23, 2004 |
Comments (0)
August 16, 2004
MatrixSSL 1.2.1
Releases
Bug fixes and optimizations
- Increased max SSL record length to 16K + 2K for Apache compatibility
- Validate outgoing record length in matrixSslEncode()
- Sanity check mac padding loop
- Validate all ASN.1 length fields in X.509 certificates
August 16, 2004 |
Comments (0)
July 08, 2004
MatrixSSL 1.1.2
Releases
Bug fixes and optimizations
- Remove newline requirement for private key parsing
- Allow NULL certificate for matrixSslReadKeys()
- Cleaned up some spurious compiler warnings
July 08, 2004 |
Comments (0)
June 11, 2004
MatrixSSL 1.1.1
Releases
Functional changes
- Enabled SSL_RSA_WITH_3DES_EDE_CBC_SHA by default. The footprint remains the same, since 3DES was already included with the USE_ENCRYPTED_PRIVATE_KEYS define. Note that this is the preferred cipher for many SSL clients, so by enabling this cipher, communications will default to a stronger, but slower cipher.
Bug fixes and optimizations
- Safer memory usage for RSA blinding function. Code was already safe for 1024 and 2048 bit keys, but this ensures the safety.
- Properly compare the time in the session cache to ensure the oldest unused session is replaced first. Previously the oldest session may not have been chosen, and a newer one replaced instead.
- Fixed a null-termination error in a static buffer that caused a crash on some platforms using encrypted private keys.
- Improved example code handling of return codes of sslRead(). Clarified that a 0 return code may indicate either a successful parse of a record with no application data, or an EOF. Previously both cases were treated as EOF, which fits the examples, but isn't as useful for other applications.
June 11, 2004 |
Comments (0)
June 01, 2004
MatrixSSL 1.1
Releases
Enhancements
- Added session cache expiry code (defaults to 24 hours)
- Added optional support for RSA blinding (USE_RSA_BLINDING, off by default)
- Support for VxWorks
- Support for MacOS X
- Support for Microsoft Windows CE
- Support for platforms without native 64 bit integers (USE_INT64, on by default)
Changes
- Split matrixSsl.c into two additional files: sslDecode.c and sslEncode.c
- Updated matrixSslSetCertValidator() API and callback to support user supplied argument
- Added sigHash and sigHashLen parameters to sslCertInfo_t structure for public access to the certificate fingerprint
- General code formatting and cleanup
- Removed strtok() and va_args use for better portability
Fixes
- Support for (ignoring) TLS extensions in ClientHello
- Fixed bug in handling of static strings for matrixSslReadKeys()
- Fixed maximum 4 byte memory compare overrun in certificate parsing
June 01, 2004 |
Comments (0)
May 03, 2004
MatrixSSL 1.0.2
Releases
This release fixes two issues; an error in parsing packed handshake records, and a corner case memory leak in the socket example code. Neither of these issues presents a security risk, but could affect interoperability and resource usage.
May 03, 2004 |
Comments (0)
April 19, 2004
MatrixSSL 1.0.1
Releases
We've released a minor update to 1.0. Support has been added for validation of X.509 certificates with serial numbers using more than 32 bits, improving compatibility with more certificates. This change affects the public sslCertInfo_t structure serialNumber field type and adds a new element, serialNumberLen to the structure.
April 19, 2004 |
Comments (0)
March 29, 2004
1.0 Release
Releases
We've posted our 1.0 release of MatrixSSL. Thank you to all the beta testers who sent us feedback and suggestions. We're sure the requirements will continue to be enhanced as additional products use MatrixSSL, but thanks to the open source community, this has been a strong 1.0 release.
March 29, 2004 |
Comments (0)
March 11, 2004
Beta2 R2
Releases
We've released an updated Beta 2 package to fix an issue with the example certificate file included with the initial release. This certificate contained extensions that were not readable by Netscape 7 or Mozilla. We have regenerated the certificates and included them in the latest source download, with an update to asn1.c. These certificates are only for testing purposes and should not be used in an actual release.
March 11, 2004 |
Comments (0)
March 02, 2004
MatrixSSL 1.0 Beta 2
Releases
We have just released a second beta version of MatrixSSL for download. Final release is just around the corner, but we wanted to get our client side SSL implementation some beta time.
Release Notes:
- RC4-MD5 and RC4-SHA are now enabled by default.
- httpClient and httpReflector must be "Set As StartUp Project" project in their respective VisualStudio solutions in order to run automatically in the debugger in Windows.
- Certificate validation currently checks only that the certificate was signed by the root CA, and that other internals are consistent. User level checks of the distinguished name will be added in final release.
Change Log:
- Added client side SSL support
- Added X.509 certificate parsing and basic validation
- Added httpClient example
- Added several new APIs for client side SSL
- Enhanced client and reflector example with support for pipelined requests
- Fixed length check in record parsing that could lead to a comparison beyond memory boundaries.
- Fixed SSL record version check that could allow invalid record versions to be sent. As only SSLv3 was supported, this did not cause a security concern.
- Added workaround for bug in Microsoft Internet Explorer, where negotiated version is sent in the encrypted premaster secret, rather than the requested version as per specification.
- Minor updates to cryptography code suggested by Tom St. Denis.
March 02, 2004 |
Comments (0)
January 26, 2004
MatrixSSL 1.0 Beta
Releases
First general public release of MatrixSSL.
January 26, 2004 |
Comments (0)