Using the workaround with the EVP interface, which we use to derive shared
keys since 74e02ff5e6 ("openssl: Mainly use EVP interface for ECDH"),
would actually require us to register the OIDs of these curves as NID.
Otherwise, the two EC_GROUPs used by private and public key objects
are not considered the same and the key derivation fails.
Since the curves are supported by OpenSSL since 1.0.2 it's probably rare to
find a version without them nowadays. One exception is the old BoringSSL
version we still use on Android, which defines the NIDs but not the curve
data. However, that version also lacks support to register OIDs as NIDs,
so the only option to support these groups there would be to got back to not
using the EVP interface, which isn't in anyone's interest. If there really
is a need for them there, we could probably patch BoringSSL or use OpenSSL.
OpenSSL enforces a minimum of 14 bytes (112 bits) on the key size when
used in FIPS-mode (as required by SP 800-131A). So by using an empty
string, instantiation always failed. 32 bytes (256 bits) should be safe
for now.
Closesstrongswan/strongswan#557
If a PKCS#11 library/token doesn't provide one or more attributes via
C_GetAttributeValue(), we get back CKR_ATTRIBUTE_TYPE_INVALID (similar
for protected attributes where CKR_ATTRIBUTE_SENSITIVE is returned).
This is not an error as the spec demands that all attributes have been
processed with the unavailable attributes having set their length
field to CK_UNAVAILABLE_INFORMATION.
We use this to handle the CKA_TRUSTED attribute, which some tokens
apparently don't support. We previously used a version check to remove
the attribute from the call but even the latest spec doesn't make the
attribute mandatory (it's just in a list of "common" attributes for
CKO_CERTIFICATE objects, without a default value), so there are current
tokens that don't support it and prevent us from enumerating certificates.
While CCM is available in earlier versions, we only use it with
OpenSSL 1.1.0 and newer because the generic control variables are not
available before and we default to GCM for them.
Closesstrongswan/strongswan#353.
If we pass a pointer to NULL, the memory allocated by OpenSSL has to be
freed with OPENSSL_free(). Otherwise, this can lead to random
crashes/freezes for Windows builds as seen on AppVeyor. To not
complicate things for callers of this macro, we allocate our own memory,
which we already do for other i2d_* calls.
If no valid key is configured (e.g. because it's inadvertently uninitialized),
we should not just reuse the previous key.
The `key_set` flag is not necessary anymore because a non-NULL key is set
during initialization since 6b347d5232 ("openssl: Ensure underlying hash
algorithm is available during HMAC init").
In some cases, the algorithms that have been compiled into a plugin have
to be disabled at runtime. Based on the array returned by the get_features()
function the optionally provided function can strip algorithms or even
callbacks or registrations from a plugin, giving us a handy and powerful way
for runtime feature configuration aside from the plugin list.
Signed-off-by: Thomas Egerer <[email protected]>
Apparently, we should use OPENSSL_free() to release memory allocated by
OpenSSL. While it generally maps to free() that's apparently not the
case on Windows, where the ECP test vectors caused `ACCESS_VIOLATION
exception` crashes (not always the same vector).
Fixes: 74e02ff5e6 ("openssl: Mainly use EVP interface for ECDH")
Functions like ECDH_compute_key() will be removed with OpenSSL 3 (which
will require additional changes as other functions will be deprecated or
removed too).
ECDH_compute_key() was not used because it only gives x-coordinate of
the result. However, the default setting, as per the errata mentioned,
is to use x-coordinate only.
Use ECDH_compute_key() for this setting as it additionally allows HW
offload of the computation using dynamic engine feature in OpenSSL.
EC_POINT_mul() doesn't allow HW offload.
Signed-off-by: Mahantesh Salimath <[email protected]>
In FIPS mode, libgcrypt uses a DRBG, which behaves differently when the
length passed to gcry_create_nonce() or gcry_randomize() is <= 0. It
expects a struct and explicitly checks that the passed pointer is not
NULL.
Commit 27756b081c (revocation: Check that nonce in OCSP response matches)
introduced strict nonce validation to prevent replay attacks with OCSP
responses having a longer lifetime. However, many commercial CAs (such as
Digicert) do not support nonces in responses, as they reuse once-issued OCSP
responses for the OCSP lifetime. This can be problematic for replay attack
scenarios, but is nothing we can fix at our end.
With the mentioned commit, such OCSP responses get completely unusable,
requiring the fallback to CRL based revocation. CRLs don't provide any
replay protection either, so there is nothing gained security-wise, but may
require a download of several megabytes CRL data.
To make use of replay protection where available, but fix OCSP verification
where it is not, do nonce verification only if the response actually contains
a nonce. To be safe against replay attacks, one has to fix the OCSP responder
or use a different CA, but this is not something we can enforce.
Fixes#3557.
The x509 plugin accepted CRL signers since forever, to be precise, since
dffb176f2b ("CRLSign keyUsage or CA basicConstraint are sufficient
for CRL validation")).
References #3529.
The main intention here is that we can change the hashtable_t
implementation without being impeded by the special requirements imposed
by get_match() and sorting the keys/items in buckets.
Tobias Brunner