Major changes between OpenSSL 1.1.1g and OpenSSL 1.1.1h [22 Sep 2020]
o Disallow explicit curve parameters in verifications chains when
X509_V_FLAG_X509_STRICT is used
o Enable 'MinProtocol' and 'MaxProtocol' to configure both TLS and DTLS
contexts
o Oracle Developer Studio will start reporting deprecation warnings
(1) There is no {get,make,set}context support before Darwin 9
(2) Instead of failing the build on makedepend(8) malfunction, have
make(1) ignore its return value - which used to be the default for
previous OpenSSL versions.
Adding --libdir seems innocuous enough, but due to OpenSSL's crazy complicated
build system actually results in LIBDIR becoming unset, which trickles down to
the Darwin -install_name being wrong. This broke the 'openssl' command and
thus many many dependencies.
Switch to $(libdir) instead which appears to still be set correctly.
Major changes between OpenSSL 1.1.1d and OpenSSL 1.1.1e [17 Mar 2020]
o Fixed an overflow bug in the x64_64 Montgomery squaring procedure
used in exponentiation with 512-bit moduli (CVE-2019-1551)
This is a major upgrade to the current LTS release. 1.0.2 and 1.1.0 are now
out of support and should not be used.
pkgsrc changes include a large cleanup of patches and targets, many of which
were clearly bogus, for example a CONFLICTS entry against a package that has
never existed, and one that was removed in 1999.
Tested on SmartOS, macOS, and NetBSD. Used for the SmartOS pkgsrc-2019Q4 LTS
release.
There are far too many individual changes to list, so the following text is
instead taken from the 1.1.1 blog announcement:
--------------------------------------------------------------------------
After two years of work we are excited to be releasing our latest version today
- OpenSSL 1.1.1. This is also our new Long Term Support (LTS) version and so we
are committing to support it for at least five years.
OpenSSL 1.1.1 has been a huge team effort with nearly 5000 commits having been
made from over 200 individual contributors since the release of OpenSSL 1.1.0.
These statistics just illustrate the amazing vitality and diversity of the
OpenSSL community. The contributions didn't just come in the form of commits
though. There has been a great deal of interest in this new version so thanks
needs to be extended to the large number of users who have downloaded the beta
releases to test them out and report bugs.
The headline new feature is TLSv1.3. This new version of the Transport Layer
Security (formerly known as SSL) protocol was published by the IETF just one
month ago as RFC8446. This is a major rewrite of the standard and introduces
significant changes, features and improvements which have been reflected in the
new OpenSSL version.
What's more is that OpenSSL 1.1.1 is API and ABI compliant with OpenSSL 1.1.0
so most applications that work with 1.1.0 can gain many of the benefits of
TLSv1.3 simply by dropping in the new OpenSSL version. Since TLSv1.3 works very
differently to TLSv1.2 though there are a few caveats that may impact a
minority of applications. See the TLSv1.3 page on the OpenSSL wiki for more
details.
Some of the benefits of TLSv1.3 include:
* Improved connection times due to a reduction in the number of round trips
required between the client and server
* The ability, in certain circumstances, for clients to start sending
encrypted data to the server straight away without any round trips with the
server required (a feature known as 0-RTT or “early data”).
* Improved security due to the removal of various obsolete and insecure
cryptographic algorithms and encryption of more of the connection handshake
Other features in the 1.1.1 release include:
* Complete rewrite of the OpenSSL random number generator to introduce the
following capabilities:
* The default RAND method now utilizes an AES-CTR DRBG according to NIST
standard SP 800-90Ar1.
* Support for multiple DRBG instances with seed chaining.
* There is a public and private DRBG instance.
* The DRBG instances are fork-safe.
* Keep all global DRBG instances on the secure heap if it is enabled.
* The public and private DRBG instance are per thread for lock free
operation
* Support for various new cryptographic algorithms including:
* SHA3
* SHA512/224 and SHA512/256
* EdDSA (including Ed25519 and Ed448)
* X448 (adding to the existing X25519 support in 1.1.0)
* Multi-prime RSA
* SM2
* SM3
* SM4
* SipHash
* ARIA (including TLS support)
* Signficant Side-Channel attack security improvements
* Maximum Fragment Length TLS extension support
* A new STORE module, which implements a uniform and URI based reader of
stores that can contain keys, certificates, CRLs and numerous other objects.
Since 1.1.1 is our new LTS release we are strongly advising all users to
upgrade as soon as possible. For most applications this should be straight
forward if they are written to work with OpenSSL 1.1.0. Since OpenSSL 1.1.0 is
not an LTS release it will start receiving security fixes only with immediate
affect as per our previous announcement and as published in our release
strategy. It will cease receiving all support in one years time.
Our previous LTS release (OpenSSL 1.0.2) will continue to receive full support
until the end of this year. After that it will receive security fixes only. It
will stop receiving all support at the end of 2019. Users of that release are
strongly advised to upgrade to OpenSSL 1.1.1.
Major changes between OpenSSL 1.0.2t and OpenSSL 1.0.2u [20 Dec 2019]
Fixed an an overflow bug in the x64_64 Montgomery squaring procedure used
in exponentiation with 512-bit moduli (CVE-2019-1551)
Changes between 1.0.2s and 1.0.2t [10 Sep 2019]
*) For built-in EC curves, ensure an EC_GROUP built from the curve name is
used even when parsing explicit parameters, when loading a serialized key
or calling `EC_GROUP_new_from_ecpkparameters()`/
`EC_GROUP_new_from_ecparameters()`.
This prevents bypass of security hardening and performance gains,
especially for curves with specialized EC_METHODs.
By default, if a key encoded with explicit parameters is loaded and later
serialized, the output is still encoded with explicit parameters, even if
internally a "named" EC_GROUP is used for computation.
[Nicola Tuveri]
*) Compute ECC cofactors if not provided during EC_GROUP construction. Before
this change, EC_GROUP_set_generator would accept order and/or cofactor as
NULL. After this change, only the cofactor parameter can be NULL. It also
does some minimal sanity checks on the passed order.
(CVE-2019-1547)
[Billy Bob Brumley]
*) Fixed a padding oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey.
An attack is simple, if the first CMS_recipientInfo is valid but the
second CMS_recipientInfo is chosen ciphertext. If the second
recipientInfo decodes to PKCS #1 v1.5 form plaintext, the correct
encryption key will be replaced by garbage, and the message cannot be
decoded, but if the RSA decryption fails, the correct encryption key is
used and the recipient will not notice the attack.
As a work around for this potential attack the length of the decrypted
key must be equal to the cipher default key length, in case the
certifiate is not given and all recipientInfo are tried out.
The old behaviour can be re-enabled in the CMS code by setting the
CMS_DEBUG_DECRYPT flag.
(CVE-2019-1563)
[Bernd Edlinger]
*) Document issue with installation paths in diverse Windows builds
'/usr/local/ssl' is an unsafe prefix for location to install OpenSSL
binaries and run-time config file.
(CVE-2019-1552)
[Richard Levitte]
Tested on OS X Tiger PowerPC and NetBSD-HEAD amd64
Changes between 1.0.2r and 1.0.2s [28 May 2019]
*) Change the default RSA, DSA and DH size to 2048 bit instead of 1024.
This changes the size when using the genpkey app when no size is given. It
fixes an omission in earlier changes that changed all RSA, DSA and DH
generation apps to use 2048 bits by default.
[Kurt Roeckx]
*) Add FIPS support for Android Arm 64-bit
Support for Android Arm 64-bit was added to the OpenSSL FIPS Object
Module in Version 2.0.10. For some reason, the corresponding target
'android64-aarch64' was missing OpenSSL 1.0.2, whence it could not be
built with FIPS support on Android Arm 64-bit. This omission has been
fixed.
[Matthias St. Pierre]
Changes between 1.0.2q and 1.0.2r [26 Feb 2019]
*) 0-byte record padding oracle
If an application encounters a fatal protocol error and then calls
SSL_shutdown() twice (once to send a close_notify, and once to receive one)
then OpenSSL can respond differently to the calling application if a 0 byte
record is received with invalid padding compared to if a 0 byte record is
received with an invalid MAC. If the application then behaves differently
based on that in a way that is detectable to the remote peer, then this
amounts to a padding oracle that could be used to decrypt data.
In order for this to be exploitable "non-stitched" ciphersuites must be in
use. Stitched ciphersuites are optimised implementations of certain
commonly used ciphersuites. Also the application must call SSL_shutdown()
twice even if a protocol error has occurred (applications should not do
this but some do anyway).
This issue was discovered by Juraj Somorovsky, Robert Merget and Nimrod
Aviram, with additional investigation by Steven Collison and Andrew
Hourselt. It was reported to OpenSSL on 10th December 2018.
(CVE-2019-1559)
[Matt Caswell]
*) Move strictness check from EVP_PKEY_asn1_new() to EVP_PKEY_asn1_add0().
[Richard Levitte]
Changes between 1.0.2p and 1.0.2q [20 Nov 2018]
*) Microarchitecture timing vulnerability in ECC scalar multiplication
OpenSSL ECC scalar multiplication, used in e.g. ECDSA and ECDH, has been
shown to be vulnerable to a microarchitecture timing side channel attack.
An attacker with sufficient access to mount local timing attacks during
ECDSA signature generation could recover the private key.
This issue was reported to OpenSSL on 26th October 2018 by Alejandro
Cabrera Aldaya, Billy Brumley, Sohaib ul Hassan, Cesar Pereida Garcia and
Nicola Tuveri.
(CVE-2018-5407)
[Billy Brumley]
*) Timing vulnerability in DSA signature generation
The OpenSSL DSA signature algorithm has been shown to be vulnerable to a
timing side channel attack. An attacker could use variations in the signing
algorithm to recover the private key.
This issue was reported to OpenSSL on 16th October 2018 by Samuel Weiser.
(CVE-2018-0734)
[Paul Dale]
*) Resolve a compatibility issue in EC_GROUP handling with the FIPS Object
Module, accidentally introduced while backporting security fixes from the
development branch and hindering the use of ECC in FIPS mode.
[Nicola Tuveri]
- Client DoS due to large DH parameter
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.
This issue was reported to OpenSSL on 5th June 2018 by Guido Vranken
(CVE-2018-0732)
[Guido Vranken]
- Cache timing vulnerability in RSA Key Generation
The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to
a cache timing side channel attack. An attacker with sufficient access to
mount cache timing attacks during the RSA key generation process could
recover the private key.
This issue was reported to OpenSSL on 4th April 2018 by Alejandro Cabrera
Aldaya, Billy Brumley, Cesar Pereida Garcia and Luis Manuel Alvarez Tapia.
(CVE-2018-0737)
[Billy Brumley]
- Make EVP_PKEY_asn1_new() a bit stricter about its input. A NULL pem_str
parameter is no longer accepted, as it leads to a corrupt table. NULL
pem_str is reserved for alias entries only.
[Richard Levitte]
- Revert blinding in ECDSA sign and instead make problematic addition
length-invariant. Switch even to fixed-length Montgomery multiplication.
[Andy Polyakov]
- 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 maximal error rate for primes with more than 1080 bits is lowered
to 2^-128.
[Kurt Roeckx, Annie Yousar]
- Increase the number of Miller-Rabin rounds for DSA key generating to 64.
[Kurt Roeckx]
- Add blinding to ECDSA and DSA signatures to protect against side channel
attacks discovered by Keegan Ryan (NCC Group).
[Matt Caswell]
- When unlocking a pass phrase protected PEM file or PKCS#8 container, we
now allow empty (zero character) pass phrases.
[Richard Levitte]
- Certificate time validation (X509_cmp_time) enforces stricter
compliance with RFC 5280. Fractional seconds and timezone offsets
are no longer allowed.
[Emilia Käsper]
Changes between 1.0.2n and 1.0.2o [27 Mar 2018]
*) Constructed ASN.1 types with a recursive definition could exceed the stack
Constructed ASN.1 types with a recursive definition (such as can be found
in PKCS7) could eventually exceed the stack given malicious input with
excessive recursion. This could result in a Denial Of Service attack. There
are no such structures used within SSL/TLS that come from untrusted sources
so this is considered safe.
This issue was reported to OpenSSL on 4th January 2018 by the OSS-fuzz
project.
(CVE-2018-0739)
[Matt Caswell]
The actual fix as been done by "pkglint -F */*/buildlink3.mk", and was
reviewed manually.
There are some .include lines that still are indented with zero spaces
although the surrounding .if is indented. This is existing practice.
Read/write after SSL object in error state (CVE-2017-3737)
==========================================================
Severity: Moderate
OpenSSL 1.0.2 (starting from version 1.0.2b) introduced an "error state"
mechanism. The intent was that if a fatal error occurred during a handshake then
OpenSSL would move into the error state and would immediately fail if you
attempted to continue the handshake. This works as designed for the explicit
handshake functions (SSL_do_handshake(), SSL_accept() and SSL_connect()),
however due to a bug it does not work correctly if SSL_read() or SSL_write() is
called directly. In that scenario, if the handshake fails then a fatal error
will be returned in the initial function call. If SSL_read()/SSL_write() is
subsequently called by the application for the same SSL object then it will
succeed and the data is passed without being decrypted/encrypted directly from
the SSL/TLS record layer.
In order to exploit this issue an application bug would have to be present that
resulted in a call to SSL_read()/SSL_write() being issued after having already
received a fatal error.
rsaz_1024_mul_avx2 overflow bug on x86_64 (CVE-2017-3738)
=========================================================
Severity: Low
There is an overflow bug in the AVX2 Montgomery multiplication procedure
used in exponentiation with 1024-bit moduli. No EC algorithms are affected.
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 DH1024 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 DH1024 private key among multiple clients, which is no longer an option
since CVE-2016-0701.
This only affects processors that support the AVX2 but not ADX extensions
like Intel Haswell (4th generation).
This is a recommended security update.
Changes between 1.0.2l and 1.0.2m [2 Nov 2017]
*) bn_sqrx8x_internal carry bug on x86_64
There is a carry propagating bug in the x86_64 Montgomery squaring
procedure. No EC algorithms are affected. 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 (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.
This only affects processors that support the BMI1, BMI2 and ADX extensions
like Intel Broadwell (5th generation) and later or AMD Ryzen.
This issue was reported to OpenSSL by the OSS-Fuzz project.
(CVE-2017-3736)
[Andy Polyakov]
*) Malformed X.509 IPAddressFamily could cause OOB read
If an X.509 certificate has a malformed IPAddressFamily extension,
OpenSSL could do a one-byte buffer overread. The most likely result
would be an erroneous display of the certificate in text format.
This issue was reported to OpenSSL by the OSS-Fuzz project.
(CVE-2017-3735)
[Rich Salz]
Changes between 1.0.2k and 1.0.2l [25 May 2017]
*) Have 'config' recognise 64-bit mingw and choose 'mingw64' as the target
platform rather than 'mingw'.
[Richard Levitte]
Changes between 1.0.2j and 1.0.2k [26 Jan 2017]
*) Truncated packet could crash via OOB read
If one side of an SSL/TLS path is running on a 32-bit host and a specific
cipher is being used, then a truncated packet can cause that host to
perform an out-of-bounds read, usually resulting in a crash.
This issue was reported to OpenSSL by Robert Święcki of Google.
(CVE-2017-3731)
[Andy Polyakov]
*) BN_mod_exp may produce incorrect results on x86_64
There is a carry propagating bug in the x86_64 Montgomery squaring
procedure. No EC algorithms are affected. 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 (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. For example this can occur by
default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very
similar to CVE-2015-3193 but must be treated as a separate problem.
This issue was reported to OpenSSL by the OSS-Fuzz project.
(CVE-2017-3732)
[Andy Polyakov]
*) Montgomery multiplication may produce incorrect results
There is a carry propagating bug in the Broadwell-specific Montgomery
multiplication procedure that handles input lengths divisible by, but
longer than 256 bits. Analysis suggests that attacks against RSA, DSA
and DH private keys are impossible. 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.
Among EC algorithms only Brainpool P-512 curves are affected and one
presumably can attack ECDH key negotiation. 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.
(CVE-2016-7055)
[Andy Polyakov]
*) OpenSSL now fails if it receives an unrecognised record type in TLS1.0
or TLS1.1. Previously this only happened in SSLv3 and TLS1.2. This is to
prevent issues where no progress is being made and the peer continually
sends unrecognised record types, using up resources processing them.
[Matt Caswell]
solves:
=> Bootstrap dependency digest>=20010302: found digest-20160304
===> Building for openssl-1.0.2jnb1
making depend in crypto...
gmake[1]: Entering directory '/construction/security/openssl/work/openssl-1.0.2j/crypto'
../util/domd: makedepend: not found
idea and mdc2 patents expired, so enable them by default.
rc5 looks like it might be expired as well, but I didn't find
anything relevant on that topic, so I left it alone.
Bump PKGREVISION.