Openssl 0.9.8d tls extensions patch

All instances of these calls have also been analysed too and it is believed there are no instances in internal usage where an overflow could occur.

This could still represent a security issue for end user code that calls this function directly. If an attacker is able to supply very large amounts of input data then a length check can overflow resulting in a heap corruption.

These are mainly used within the OpenSSL command line applications. These internal uses are not considered vulnerable because all calls are bounded with length checks so no overflow is possible.

User applications that call these APIs directly with large amounts of untrusted data may be vulnerable. This is no longer believed to be the case. Builds that are not configured with "enable-ssl2" will not support SSLv2. Reported by Nimrod Aviram and Sebastian Schinzel. Memory leaks can also occur. The first issue may mask the second issue dependent on compiler behaviour. If applications use these functions in this way then they could be vulnerable.

Therefore applications that print this data could be vulnerable if the data is from untrusted sources. Libssl is not considered directly vulnerable.

Additionally certificates etc received via remote connections via libssl are also unlikely to be able to trigger these issues because of message size limits enforced within libssl. The calling code has no way of distinguishing these two cases. Specifically, SRP servers that configure a secret seed to hide valid login information are vulnerable to a memory leak: an attacker connecting with an invalid username can cause a memory leak of around bytes per connection.

However, note that OpenSSL makes no strong guarantees about the indistinguishability of valid and invalid logins. In particular, computations are currently not carried out in constant time. In this case memory is allocated to the internal BIGNUM data field, but it is insufficiently sized leading to heap corruption. This is anticipated to be a rare occurrence. All OpenSSL internal usage of these functions use data that is not expected to be untrusted, e.

If user developed applications generate config file data based on untrusted data then it is possible that this could also lead to security consequences. This is also anticipated to be rare. This scenario is considered rare.

Reported by David Adrian and J. Alex Halderman University of Michigan. This leads to an efficient divide-and-conquer key recovery attack: if an eavesdropper has intercepted an SSLv2 handshake, they can use the server as an oracle to determine the SSLv2 master-key, using only 16 connections to the server and negligible computation. More importantly, this leads to a more efficient version of DROWN that is effective against non-export ciphersuites, and requires no significant computation. The ability to exploit this issue is limited as it relies on an attacker who has control of code in a thread running on the same hyper-threaded core as the victim thread which is performing decryptions.

More recently in version 1. The primes used in such files may not be "safe". Where an application is using DH configured with parameters based on primes that are not "safe" then an attacker could use this fact to find a peer's private DH exponent. This attack requires that the attacker complete multiple handshakes in which the peer uses the same private DH exponent.

It is not on by default. If the option is not set then the server reuses the same private DH exponent for the life of the server process and would be vulnerable to this attack. It is believed that many popular applications do set this option and would therefore not be at risk.

OpenSSL before 1. This is an undocumted feature and parameter files don't contain the key. The key is part of the certificate and so it will always reuse it.

This is only supported in 1. The callback is almost always used like this. This will write an X9. This is supported since the 1. Older versions can't read files generated in this way.

This has always been documented as requiring the single use. The fix for this issue adds an additional check where a "q" parameter is available as is the case in X9. This detects the only known attack, and is the only possible defense for static DH ciphersuites.

This could have some performance impact. Reported by Antonio Sanso Adobe. This can result in a race condition potentially leading to a double free of the identify hint data. Since these routines are used to verify certificate signature algorithms this can be used to crash any certificate verification operation and exploited in a DoS attack.

Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication. Reported by Guy Leaver Cisco. This can be used to perform denial of service against any system which verifies signedData messages using the CMS code.

Reported by Johannes Bauer. An attacker can craft malformed ASN. OpenSSL clients and servers are not affected. Reported by Michal Zalewski Google. An attacker can use this to craft malformed certificates and CRLs of various sizes and potentially cause a segmentation fault, resulting in a DoS on applications that verify certificates or CRLs.

TLS clients and servers with client authentication enabled may be affected if they use custom verification callbacks. This can be used to perform denial of service against any system which processes public keys, certificate requests or certificates. Reported by Joseph Birr-Pixton.

If a DTLS peer receives application data between the ChangeCipherSpec and Finished messages, buffering of such data may cause an invalid free, resulting in a segmentation fault or potentially, memory corruption. If client auth is used then a server can seg fault in the event of a DHE ciphersuite being selected and a zero length ClientKeyExchange message being sent by the client.

This could be exploited in a DoS attack. Any code path that reads base64 data from an untrusted source could be affected such as the PEM processing routines. Maliciously crafted base 64 data could trigger a segmenation fault or memory corruption. If a client connects to an OpenSSL 1.

This can be exploited in a DoS attack against the server. Reported by David Ramos Stanford University. Typically, when the user application is using a socket BIO for writing, this will only result in a failed connection.

However if some other BIO is used then it is likely that a segmentation fault will be triggered, thus enabling a potential DoS attack. Reported by Daniel Danner and Rainer Mueller. Reusing a structure in ASN. Such reuse is and has been strongly discouraged and is believed to be rare.

Errors processing the initial ClientHello can trigger this scenario. An example of such an error could be that a DTLS1. Reported by Per Allansson. If the handshake succeeds then the client random that has been used will have been generated from a PRNG with insufficient entropy and therefore the output may be predictable. This function is rarely used in practice.

In particular this could occur if an attacker sent repeated DTLS records with the same sequence number but for the next epoch. The memory leak could be exploited by an attacker in a Denial of Service attack through memory exhaustion. Reported by Chris Mueller. This effectively allows a client to authenticate without the use of a private key.

This only affects servers which trust a client certificate authority which issues certificates containing DH keys: these are extremely rare and hardly ever encountered. This bug occurs at random with a very low probability, and is not known to be exploitable in any way, though its exact impact is difficult to determine. For the remaining platforms e. OpenSSL built without assembly support , pre-existing countermeasures thwart bug attacks [1]. However, there is no known computationally feasible way to construct such points with low order, and so the security of static ECDH private keys is believed to be unaffected.

No exploits are known and straightforward bug attacks fail - either the attacker cannot control when the bug triggers, or no private key material is involved. Reported by Pieter Wuille Blockstream. A server could present a weak temporary key and downgrade the security of the session. OpenSSL also does not enforce a match between the signature algorithm between the signed and unsigned portions of the certificate.

By modifying the contents of the signature algorithm or the encoding of the signature, it is possible to change the certificate's fingerprint. It also does not affect common revocation mechanisms. Only custom applications that rely on the uniqueness of the fingerprint e. This effectively removes forward secrecy from the ciphersuite. This could lead to a Denial Of Service attack. Reported by Frank Schmirler. Reported by Akamai Technologies.

In the event of a session ticket integrity check failing, OpenSSL will fail to free memory causing a memory leak. By sending a large number of invalid session tickets an attacker could exploit this issue in a Denial Of Service attack. Reported by LibreSSL project.

Some client applications such as browsers will reconnect using a downgraded protocol to work around interoperability bugs in older servers.

This could be exploited by an active man-in-the-middle to downgrade connections to SSL 3. SSL 3. The issue affects OpenSSL clients and allows a malicious server to crash the client with a null pointer dereference read by specifying an SRP ciphersuite even though it was not properly negotiated with the client.

This could lead to a Denial of Service. A malicious client or server can send invalid SRP parameters and overrun an internal buffer. Only applications which are explicitly set up for SRP use are affected. This allows a man-in-the-middle attacker to force a downgrade to TLS 1. A malicious server can crash the client with a null pointer dereference read by specifying an anonymous EC DH ciphersuite and sending carefully crafted handshake messages.

If a multithreaded client connects to a malicious server using a resumed session and the server sends an ec point format extension, it could write up to bytes to freed memory. Applications may be affected if they echo pretty printing output to the attacker. Reported by Ivan Fratric Google. This could lead to a Denial of Service attack. Reported by Adam Langley Google.

An attacker can force openssl to consume large amounts of memory whilst processing DTLS handshake messages. An attacker can force an error condition which causes openssl to crash whilst processing DTLS packets due to memory being freed twice. This can be exploited by a Man-in-the-middle MITM attack where the attacker can decrypt and modify traffic from the attacked client and server. This is potentially exploitable to run arbitrary code on a vulnerable client or server.

This flaw only affects OpenSSL 1. This flaw only affects multithreaded applications using OpenSSL 1. This issue did not affect versions of OpenSSL prior to 1. Reported by Neel Mehta. A malicious server could use this flaw to crash a connecting client. This issue only affected OpenSSL 1. Reported by Anton Johansson. Reported by Ron Barber. It also does not affect common revocation mechanisms. Only custom applications that rely on the uniqueness of the fingerprint e.

This effectively removes forward secrecy from the ciphersuite. This could lead to a Denial Of Service attack. Reported by Frank Schmirler. Reported by Akamai Technologies. In the event of a session ticket integrity check failing, OpenSSL will fail to free memory causing a memory leak.

By sending a large number of invalid session tickets an attacker could exploit this issue in a Denial Of Service attack. Some client applications such as browsers will reconnect using a downgraded protocol to work around interoperability bugs in older servers. This could be exploited by an active man-in-the-middle to downgrade connections to SSL 3.

SSL 3. A malicious server can crash the client with a null pointer dereference read by specifying an anonymous EC DH ciphersuite and sending carefully crafted handshake messages. Applications may be affected if they echo pretty printing output to the attacker. Reported by Ivan Fratric Google. This could lead to a Denial of Service attack. Reported by Adam Langley Google. An attacker can force openssl to consume large amounts of memory whilst processing DTLS handshake messages.

An attacker can force an error condition which causes openssl to crash whilst processing DTLS packets due to memory being freed twice. This can be exploited by a Man-in-the-middle MITM attack where the attacker can decrypt and modify traffic from the attacked client and server. This is potentially exploitable to run arbitrary code on a vulnerable client or server. Reported by Stephen Henson. Reported by Nadhem J. AlFardan and Kenneth G. A malicious TLS 1. Reported by Codenomicon. This issue only affects OpenSSL 0.

OpenSSL 1. Reported by Red Hat. Reported by Tavis Ormandy. Reported by Ivan Nestlerode. Only DTLS applications are affected. Reported by Antonio Martin. Reported by George Kadianakis.

This could be used in a denial-of-service attack. Added a new concept for OpenSSL plugability: providers. With this concept comes a new core API for interaction between libcrypto and provider implementations. Public libcrypto functions that want to use providers do so through this core API. Typically an application will call this function twice. The first time, on entry, the "out" parameter can be NULL and, on exit, the "outlen" parameter is populated with the buffer size required to hold the decrypted plaintext.

A malicious attacker who is able present SM2 content for decryption to an application could cause attacker chosen data to overflow the buffer by up to a maximum of 62 bytes altering the contents of other data held after the buffer, possibly changing application behaviour or causing the application to crash. The location of the buffer is application dependent but is typically heap allocated. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL 0 byte.

Although not a strict requirement, ASN. Where an application requests an ASN. This might result in a crash causing a Denial of Service attack. It could also result in the disclosure of private memory contents such as private keys, or sensitive plaintext. This flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.

An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten.

This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA.

All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. If a TLSv1. A server is only vulnerable if it has TLSv1.

It attempts to create a unique hash value based on the issuer and serial number data contained within an X certificate. However it was failing to correctly handle any errors that may occur while parsing the issuer field which might occur if the issuer field is maliciously constructed. This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack.

This is considered a bug in OpenSSL 1. Previously they could overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call would be 1 indicating success , but the output length value would be negative.

This could cause applications to behave incorrectly or crash. This could be exploited in a side channel attack to recover the password. If an attacker can control both items being compared then this could lead to a possible denial of service attack. The crash occurs if an invalid or unrecognised signature algorithm is received from the peer.

This could be exploited by a malicious peer in a Denial of Service attack. Added AES consttime code for no-asm configurations an optional constant time support for AES was added when building openssl for no-asm.

Enable with:. It will be enabled by default in 3. Revert the change of EOF detection while reading in libssl to avoid regressions in applications depending on the current way of reporting the EOF.

Properly detect EOF while reading in libssl. Check that ed and ed are allowed by the security level. Previously signature algorithms not using an MD were not being checked that they were allowed by the security level. The behaviour was not consistent between resumption and normal handshakes, and also not quite consistent with historical behaviour. The behaviour in various scenarios has been clarified and it has been updated to make it match historical behaviour as closely as possible.

Otherwise, only functions with symbols of less than 31 characters can be used, as the linker will not be able to successfully resolve symbols with longer names. Fixed a fork protection issue. OpenSSL 1. This was intended to include protection in the event of a fork system call in order to ensure that the parent and child processes did not share the same RNG state. However this protection was not being used in the default case.

A partial mitigation for this issue is that the output from a high precision timer is mixed into the RNG state so the likelihood of a parent and child process sharing state is significantly reduced.

It turned out that this change had negative side effects on performance which were not acceptable. After some discussion it was decided to revert this feature and leave it up to the OS resp. This changes the size when using the genpkey command when no size is given. RFC specifies that the nonce value IV should be 96 bits 12 bytes.

OpenSSL allows a variable nonce length and front pads the nonce with 0 bytes if it is less than 12 bytes. However it also incorrectly allows a nonce to be set of up to 16 bytes. In this case only the last 12 bytes are significant and any additional leading bytes are ignored. It is a requirement of using this cipher that nonce values are unique. Messages encrypted using a reused nonce value are susceptible to serious confidentiality and integrity attacks. If an application changes the default nonce length to be longer than 12 bytes and then makes a change to the leading bytes of the nonce expecting the new value to be a new unique nonce then such an application could inadvertently encrypt messages with a reused nonce.

Additionally the ignored bytes in a long nonce are not covered by the integrity guarantee of this cipher. Any application that relies on the integrity of these ignored leading bytes of a long nonce may be further affected. However user applications that use this cipher directly and set a non-default nonce length to be longer than 12 bytes may be vulnerable. Change the info callback signals for the start and end of a post-handshake message exchange in TLSv1.

Experience has shown that many applications get confused by this and assume that a TLSv1. This can break KeyUpdate handling. Instead we no longer signal the start and end of a post handshake message exchange although the messages themselves are still signalled. This could break some applications that were expecting the old signals.

However without this KeyUpdate is not usable for many applications. An attacker could use variations in the signing algorithm to recover the private key. The limit has been raised to a buffer size of two gigabytes and the error handling improved. Falko Strenzke. It has been categorized as a normal bug, not a security issue, because the DRBG reseeds automatically and is fully functional even without additional randomness provided by the application.

Add a new ClientHello callback. Provides a callback interface that gives the application the ability to adjust the nascent SSL object at the earliest stage of ClientHello processing, immediately after extensions have been collected but before they have been processed. In particular, this callback can adjust the supported TLS versions in response to the contents of the ClientHello. The new implementation is based on formulae from differential addition-and-doubling in homogeneous projective coordinates from Izu-Takagi "A fast parallel elliptic curve multiplication resistant against side channel attacks" and Brier-Joye "Weierstrass Elliptic Curves and Side-Channel Attacks" Eq.

Change generating and checking of primes so that the error rate of not being prime depends on the intended use based on the size of the input. For larger primes this will result in more rounds of Miller-Rabin. The 'tsget' script is renamed to 'tsget. Switch even to fixed-length Montgomery multiplication.

The new implementation is based on formulae from differential addition-and-doubling in mixed Lopez-Dahab projective coordinates, modified to independently blind the operands. Modified the random device based seed sources to keep the relevant file descriptors open rather than reopening them on each access. This allows such sources to operate in a chroot jail without the associated device nodes being available.

Numerous side-channel attack mitigations have been applied. This may have performance impacts for some algorithms for the benefit of improved security. Specific changes are noted in this change log by their respective authors.

AIX shared library support overhaul. Switch to AIX "natural" way of handling shared libraries, which means collecting shared objects of different versions and bitnesses in one common archive. This allows to mitigate conflict between 1.

It doesn't affect the way 3rd party applications are linked, only how multi-version installation is managed. Enforce checking in the pkeyutl command to ensure that the input length does not exceed the maximum supported digest length when performing a sign, verify or verifyrecover operation. Many applications do not properly handle non-application data records, and TLS 1. Separated TLSv1. Similarly TLSv1. In order to avoid issues where legacy TLSv1.

The "-timeout" option now also limits the OCSP responder's patience to wait to receive the full client request on a newly accepted connection. Child processes are respawned as needed, and the CA index file is automatically reloaded when changed. This makes it possible to run the "ocsp" responder as a long-running service, making the OpenSSL CA somewhat more feature-complete. In this mode, most diagnostic messages logged after entering the event loop are logged via syslog 3 rather than written to stderr.

Support for TLSv1. Note that users upgrading from an earlier version of OpenSSL should review their configuration settings to ensure that they are still appropriate for TLSv1. It is a hybrid deterministic random bit generator using an AES-CTR bit stream and which seeds and reseeds itself automatically using trusted system entropy sources. Changed Configure so it only says what it does and doesn't dump so much data. Get rid of Makefile.

Jack Lloyd jack. Some macro definitions to support VS6 have been removed. Visual Studio 6 has not worked since 1. Add "atfork" functions. To disable, configure with 'no-ui-console'. The implementation uses backends called "loaders" to implement arbitrary URI schemes.

There is one built in "loader" for the 'file' scheme. Add devcrypto engine. This has been implemented against cryptodev-linux, then adjusted to work on FreeBSD 8. Enable by configuring with 'enable-devcryptoeng'. This is done by default on BSD implementations, as cryptodev.

For the foreseeable future, this will only affect new modules. This can be used to prepare everything that requires things like perl for a system that lacks perl and then move everything to that system and do the rest of the build there. In the UI interface, make it possible to duplicate the user data. This can be used by engines that need to retain the data for a longer time than just the call where this user data is passed. An alert message is 2 bytes long. In practice it make no sense to send an empty alert record, or to fragment one.

Supporting it adds significant complexity to the record layer, and its removal is unlikely to cause interoperability issues.

Add the ASN. Have 'config' recognise bit mingw and choose 'mingw64' as the target platform rather than 'mingw'. This change cascades to other functions which load certificates and CRLs. Fractional seconds and timezone offsets are no longer allowed. The server name is based on the host provided to the "-connect" option unless overridden by using "-servername".

This is to prevent issues where no progress is being made and the peer continually sends unrecognised record types, using up resources processing them. During key agreement in a TLS handshake using a DH E based ciphersuite a malicious server can send a very large prime value to the client.

This will cause the client to spend an unreasonably long period of time generating a key for this prime resulting in a hang until the client has finished. This could be exploited in a Denial Of Service attack.

An attacker with sufficient access to mount cache timing attacks during the RSA key generation process could recover the private key. Where a CMS detached signature is used with text content the text goes through a canonicalisation process first prior to signing or verifying a signature. This process strips trailing space at the end of lines, converts line terminators to CRLF and removes additional trailing line terminators at the end of a file.

A bug in the canonicalisation process meant that some characters, such as form-feed, were incorrectly treated as whitespace and removed. This is contrary to the specification RFC This fix could mean that detached text data signed with an earlier version of OpenSSL 1. Constructed ASN. This could result in a Denial Of Service attack.

This allows an attacker to forge messages that would be considered as authenticated in an amount of tries lower than that guaranteed by the security claims of the scheme. Due to the opacity changes this is no longer possible in 1. Note that if an application built against 1. There is an overflow bug in the AVX2 Montgomery multiplication procedure used in exponentiation with bit moduli.

Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible, because most of the work necessary to deduce information about a private key may be performed offline.

The amount of resources required for such an attack would be significant. However, for an attack on TLS to be meaningful, the server would have to share the DH private key among multiple clients, which is no longer an option since CVE The issue was originally found via the OSS-Fuzz project.

Attacks against DH are considered just feasible although very difficult because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients.

If an X. The most likely result would be an erroneous display of the certificate in text format. During a renegotiation handshake if the Encrypt-Then-Mac extension is negotiated where it was not in the original handshake or vice-versa then this can cause OpenSSL to crash dependant on ciphersuite.

Both clients and servers are affected. This could be exploited in a Denial of Service attack. Note: This issue is very similar to CVE but must be treated as a separate problem.

This can result in an OpenSSL crash. This issue is not considered to be exploitable beyond a DoS. This is caused by a bug in the handling of the ASN. There is a carry propagating bug in the Broadwell-specific Montgomery multiplication procedure that handles input lengths divisible by, but longer than bits.

This is because the subroutine in question is not used in operations with the private key itself and an input of the attacker's direct choice. Otherwise the bug can manifest itself as transient authentication and key negotiation failures or reproducible erroneous outcome of public-key operations with specially crafted input.

Impact was not analyzed in detail, because pre-requisites for attack are considered unlikely. Namely multiple clients have to choose the curve in question and the server has to share the private key among them, neither of which is default behaviour. Even then only clients that chose the curve will be affected. This issue was publicly reported as transient failures and was not initially recognized as a security issue. Thanks to Richard Morgan for providing reproducible case.

The patch applied to address CVE resulted in an issue where if a message larger than approx 16k is received then the underlying buffer to store the incoming message is reallocated and moved. Unfortunately a dangling pointer to the old location is left which results in an attempt to write to the previously freed location.

This is likely to result in a crash, however it could potentially lead to execution of arbitrary code. If that client continually requests renegotiation, sending a large OCSP Status Request extension each time, then there will be unbounded memory growth on the server. This will eventually lead to a Denial Of Service attack through memory exhaustion. Servers with a default configuration are vulnerable even if they do not support OCSP. Builds using the "no-ocsp" build time option are not affected.

This could be exploited by a malicious peer in a Denial Of Service attack. A D TLS message includes 3 bytes for its length in the header for the message. This would allow for messages up to 16Mb in length. Messages of this length are excessive and OpenSSL includes a check to ensure that a peer is sending reasonably sized messages in order to avoid too much memory being consumed to service a connection.

A flaw in the logic of version 1. Due to way memory is allocated in OpenSSL this could mean an attacker could force up to 21Mb to be allocated to service a connection. This could lead to a Denial of Service through memory exhaustion. However, the excessive message length check still takes place, and this would cause the connection to immediately fail.

Therefore the excessive memory allocation will be transitory in nature. This then means that there is only a security impact if:. However there is an increased risk during this period of application crashes due to the lack of memory - which would then mean a more serious Denial of Service. Primary reason is that vendor assembler can't assemble our modules with -KPIC flag. As result it, assembly support, was not even available as option. But its lack means lack of side-channel resistant code, which is incompatible with security by todays standards.

Fortunately gcc is readily available prepackaged option, which we firmly point at Windows command-line tool supports UTF-8 opt-in option for arguments and console input. See the RC4 item below to re-enable both. If all else fails we fall back to C:. A return of 0 indicates and error while a return of 1 indicates success.

Various other RAND-related tickets were also closed. The old names are available with API compatibility. They new names are now completely documented. With Windows Visual Studio builds, the. To create only static libraries use the "no-shared" Configure option. Remove the no-aes, no-hmac, no-rsa, no-sha and no-md5 Configure options. All of these option have not worked for some while and are fundamental algorithms. Make various cleanup routines no-ops and mark them as deprecated. Explicitly de-initing can cause problems e.

Instead, debug options are automatically enabled with '--debug' builds. The structures for managing DH objects have been moved out of the public header files. New functions for managing these have been added. The structures for managing RSA objects have been moved out of the public header files.

The structures for managing DSA objects have been moved out of the public header files. The structures for managing BIOs have been moved out of the public header files.

Added support for "pipelining". There are currently no built-in ciphers with this property but the expectation is that engines will be able to offer it to significantly improve throughput. This is an async capable engine which is able to offload work to the Linux kernel. The kernel must be version 4. It is no longer necessary to set locking callbacks to use OpenSSL in a multi-threaded environment. There are two supported threading models: pthreads and windows threads.

It is also possible to configure OpenSSL at compile time for "no-threads". The old threading API should no longer be used. The functions have been replaced with "no-op" compatibility macros. RC4 based libssl ciphersuites are now classed as "weak" ciphers and are disabled by default. They can be re-enabled using the enable-weak-ssl-ciphers option to Configure. Add X support. Add ASN. This includes support for public and private key encoding using the format documented in draft-ietf-curdle-pkix Note also that even though configuring the SRP seed attempts to hide invalid usernames by continuing the handshake with fake credentials, this behaviour is not constant time and no strong guarantees are made that the handshake is indistinguishable from that of a valid user.

Configuration change; it's now possible to build dynamic engines without having to build shared libraries and vice versa. Building dynamic engines is enabled by default; to disable, use the configuration option "disable-dynamic-engine". The only requirements for building dynamic engines are the presence of the DSO module and building with position independent code, so they will also automatically be disabled if configuring with "disable-dso" or "disable-pic".

Configuration change; if there is a known flag to compile position independent code, it will always be applied on the libcrypto and libssl object files, and never on the application object files. If this isn't desirable, the configuration options "disable-pic" or "no-pic" can be used to disable the use of PIC.

This will also disable building shared libraries and dynamic engines. That makes for less confusion on what this variable is for. Code that uses the old define's might need to be updated.

The "unified" build system is aimed to be a common system for all platforms we support. With it comes new support for VMS. This system builds supports building in a different directory tree than the source tree.

It produces one Makefile for unix family or lookalikes , or one descrip. With this change, the library names were also renamed on Windows and on VMS. They now have names that are closer to the standard on Unix, and include the major version number, and in certain cases, the architecture they are built for. Added support for auto-initialisation and de-initialisation of the library. OpenSSL no longer requires explicit init or deinit routines to be called, except in certain circumstances.

Rewrite of BIO networking library. The BIO library lacked consistent support of IPv6, and adding it required some more extensive modifications. Configuration and writing out the results from it has changed. Also, the center of configuration information is no longer Makefile.

Instead, Configure produces a perl module in configdata. To clarify their intended purposes, the Configure options --prefix and --openssldir change their semantics, and become more straightforward and less interdependent.

This is also where the default openssl. The GOST engine was out of date and therefore it has been removed. An up to date GOST engine is now being maintained in an external repository. The distribution now has Makefile. Configure must be run before trying to build now. They can, for example, be used to implement local end-entity certificate or trust-anchor "pinning", where the "pin" data takes the form of TLSA records, which can augment or replace verification based on the usual WebPKI public certification authorities.

Instead OpenSSL continues to support deprecated interfaces in default builds. Essentially the same effect can be achieved with the "no-deprecated" argument to Configure, except that this will always restrict the build to just the latest API, rather than a fixed API version.

Add support for setting the minimum and maximum supported protocol. This change also removes support for disabling TLS 1. Note: the ecdsa. Remove support for all 40 and 56 bit ciphers. This includes all the export ciphers who are no longer supported and drops support the ephemeral RSA key exchange. The LOW ciphers currently doesn't have any ciphers in it.

Libcrypto now includes the async sub-library to enable cryptographic operations to be performed asynchronously as long as an asynchronous capable engine is used. This work was developed in partnership with Intel Corp. If you want to disable the support you should exclude it using the list of supported ciphers.

State machine rewrite. This change does have some associated API changes. The previous handshake states defined in ssl. New ASN. That is instead of. This reduces memory fragmentation and make it impossible to accidentally set a mandatory field to NULL. Also removed RC2 although in 1. This changes the decoding behaviour for some invalid messages, though the change is mostly in the more lenient direction, and legacy behaviour is preserved as much as possible.

Fix no-stdio build. David Woodhouse David. Woodhouse intel. New testing framework The testing framework has been largely rewritten and is now using perl and the perl modules Test::Harness and an extended variant of Test::More called OpenSSL::Test to do its work.

Some undocumented "set malloc, etc. All are now documented. Rich Salz and Ismo Puustinen ismo. This SSLeay era flag was never set throughout the codebase only read. Changed the default name options in the "ca", "crl", "req" and "x" to be "oneline" instead of "compat". This is SSLeay legacy, we're not aware of clients that still exhibit this bug, and the workaround hasn't been working properly for a while. On platforms where an unsigned long is 32 bits e. These two ciphersuites were newly added along with a number of other static DH ciphersuites to 1.

However the two export ones have never worked since they were introduced. It seems strange in any case to be adding new export ciphersuites, and given "logjam" it also does not seem correct to fix them. Version negotiation has been rewritten.

All new code should use the new names instead. Also as part of this change the ssl This code and the associated standard is no longer considered fit-for-purpose. RT was closed. When generating a private key, try to make the output file readable only by the owner.

This behavior change might be noticeable when interacting with other software. Added support for TLS extended master secret from draft-ietf-tls-session-hash Thanks for Alfredo Pironti for an initial patch which was a great help during development.

Users should not attempt to access internal structures directly. Instead they should use the provided API functions. Access to deprecated functions can be re-enabled by running config with "enable-deprecated". Note that this new behaviour will, by default, disable some transitive includes that previously existed in the header files e.

Added support for OCB mode. Support for OCB can be removed by calling config with no-ocb. Increased the minimal RSA keysize from to bits [Rich Salz], done while fixing the error code for the key-too-small case. Annie Yousar a. Remove the non-null checks from callers. Save much code.

Add secure heap for storage of private keys when possible. Not currently used by any prime generator. Felix Laurie von Massenbach felix erbridge. This allows exporting the session id and the master key in NSS keylog format.

Thanks to Ted Unangst for feedback on this issue. A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. To enable it set the appropriate extension number 0x42 for the test server using e.

New test to induce all self test errors in sequence and check expected failures. Includes functionality to parse the minimal script output of fipsalgest. Use separate DRBG fields for internal and external flags.

More extensive health check for DRBG checking many more failure modes. Minor change to DRBG entropy callback semantics. Interface is very similar to GCM case except we must supply all data in one chunk i. Add algorithm test support. Initial version of POST overhaul.

Always run all selftests even if one fails. Note: this does increase the maximum key length from 32 to 64 bytes but there should be no binary compatibility issues as existing applications will never use XTS mode. Rename old X9. This shouldn't present any incompatibility problems because applications shouldn't be using these directly and any that are will need to rethink anyway as the X9.

Not used by anything, incomplete, subject to change and largely untested at present. This will avoid conflicts with future versions of OpenSSL.

Add selftest checks and algorithm block of non-fips algorithms in FIPS mode. Remove DES2 from selftests. Add new tiny fips sign and verify functions. New build option "fipscanisteronly". This only builds fipscanister. Uses the file Makefile. Add internal IV generator. The tag can be set or retrieved with a ctrl.