Add a new option to require that an external Pre-Shared Key is negotiated
for a handshake to succeed, configured via the new APIs
wolfSSL_CTX_require_psk()/wolfSSL_require_psk(). When set, a handshake
that completes without negotiating an external PSK is aborted with
PSK_MISSING_ERROR instead of falling back to a certificate handshake, so
the PSK acts as an additional security factor.
This is a TLS 1.3 / DTLS 1.3 feature. In (D)TLS 1.2 the use of a PSK is
determined by the negotiated cipher suite, so a mandatory PSK is instead
configured there by restricting the cipher suite list to PSK suites; the
new APIs therefore reject non-TLS-1.3 contexts with BAD_FUNC_ARG.
To keep the requirement fail-closed, the APIs also disable version
downgrade on the object so a downgrade-capable context (e.g. one created
from a v23 method) cannot silently fall back to (D)TLS 1.2 and complete
without a PSK; a peer that does not support (D)TLS 1.3 fails to connect.
The requirement applies to external PSKs only (not session tickets):
session-ticket resumption is exempt. To preserve forward secrecy a
mandatory external PSK must also use an (EC)DHE key exchange; a pure
psk_ke handshake is rejected with PSK_KEY_ERROR. When used with
WOLFSSL_CERT_WITH_EXTERN_PSK, it also ensures that peers are properly
authenticated with both the PSK and via certificates.
The new APIs live alongside the existing wolfSSL_[CTX_]no_dhe_psk()/
only_dhe_psk() PSK options and do not depend on certificate support, so
the feature is usable in NO_CERTS (PSK-only) builds.
Added unit tests for the new APIs and enforcement.
Allow encoding and verifying a CMS SignedData whose encapContentInfo
carries no eContent, that is, a signed-attributes-only signature over
empty content (RFC 5652 makes eContent OPTIONAL). This is required for
SCEP CertRep PENDING and FAILURE messages (RFC 8894 section 3.2.2),
which must omit the pkcsPKIEnvelope entirely.
Encode: wc_PKCS7_EncodeSignedData computes the messageDigest over the
empty content when detached is set and contentSz is 0, since there is no
eContent to drive the normal content-hashing pass.
Verify: PKCS7_VerifySignedData no longer rejects an absent eContent when
no external content or hash was supplied. It is processed as a detached
signature over empty content, and wc_PKCS7_VerifyContentMessageDigest
computes the digest of zero-length content using the parsed digest
algorithm. The messageDigest comparison still rejects a stripped
non-empty eContent.
Add pkcs7_signed_no_content_test, a round-trip over a CMS SignedData
whose encapContentInfo carries no eContent (a detached signature over
empty content, signed-attributes-only), as produced by SCEP CertRep
PENDING/FAILURE messages. The encode omits the eContent and the verify
accepts it without any caller-supplied content or hash, checking the
messageDigest against the hash of empty content. Run for RSA/SHA-256.
QUIC performs key updates at the packet-protection layer via the Key
Phase bit, so RFC 9001 section 6 requires a QUIC endpoint to reject any
received TLS KeyUpdate handshake message as a fatal unexpected_message
connection error and to never send one. The TLS 1.3 receive path
processed the message normally, rotating traffic secrets and possibly
emitting a prohibited KeyUpdate response, and the send path allowed a
QUIC connection to originate a KeyUpdate.
Guard the key_update case in SanityCheckTls13MsgReceived so a QUIC
connection aborts with a fatal unexpected_message alert, and guard
Tls13UpdateKeys so a QUIC connection cannot send a KeyUpdate. Add a
QUIC unit test that feeds a post-handshake KeyUpdate and confirms the
connection is refused.
When the caller passes the object's own data pointer as the source,
wolfSSL_ASN1_STRING_set freed the existing buffer before copying from
it, reading freed memory in the dynamic case and copying cleared bytes
in the fixed-buffer case. Duplicate the source into a temporary buffer
when it aliases the object before disposing of the old buffer, then
free the temporary once the copy completes.
An oversized length argument was passed straight to GetASNHeader as the
buffer bound. A caller supplying a length larger than the real buffer let
the OBJECT_ID header claim more content than was present, driving the OID
validation read past the end of the allocation. Since an ASN1_OBJECT is an
OID, clamp the parse window to the maximum OID encoding so the header
decode cannot read beyond a sane bound.
wolfSSL_EVP_EncodeUpdate did not validate the input length. A large
inl caused the block loop and the residual copy to read far past the
caller's input buffer, and a negative inl was silently treated as
success. Reject negative lengths and lengths whose base64 output would
overflow a positive int before processing any data.
wolfSSL_EVP_EncodeBlock rejected negative input lengths but passed any
large positive length straight to Base64_Encode_NoNl, which read that
many bytes from the caller input buffer and ran past its allocation.
Reject input lengths whose base64 output would overflow a positive int,
which also bounds the read against the caller allocation. The encoded
length is the int return value, so the safe maximum input is
(INT_MAX / 4) * 3.
wolfSSL_BIO_write rejected negative lengths but allowed a large positive
length through to wolfSSL_BIO_MEMORY_write. On a fresh buffer an INT_MAX
length overflowed the 4/3 buffer growth calculation, so the grow reported
success with a short allocation and the following copy read far past the
small source buffer.
Add an upper bound check that rejects lengths large enough to overflow the
growth math before any allocation or copy, and add a regression test that
drives a huge length through the public BIO_write entry point.
The RC2 encrypt and decrypt operations used the expanded key schedule
without checking that a key had ever been configured. On a zeroed or
otherwise unkeyed context the ECB ops ran over an all-zero schedule and
returned success, and the CBC wrappers inherited the same behavior, so
a caller who skipped wc_Rc2SetKey received ciphertext under an
unintended key with no error signalled.
Guard wc_Rc2EcbEncrypt and wc_Rc2EcbDecrypt on a zero keylen and return
MISSING_KEY when no key has been set. The CBC wrappers call these and
propagate the error. Mirrors the existing 3DES keySet guard.
Add a regression test covering the unkeyed path for all four ops.
The Camellia encrypt and decrypt operations used the key schedule
without checking that a key had ever been configured. A zeroed or
otherwise unkeyed context has a keySz that does not match 128, 192,
or 256, so the underlying block transform hit the default no-op case
and CBC emitted an easily reversible XOR chain while still returning
success. A caller who forgot wc_CamelliaSetKey received a success
code with effectively unencrypted output.
Add a key-state check that accepts only valid Camellia key sizes and
have wc_CamelliaEncryptDirect, wc_CamelliaDecryptDirect,
wc_CamelliaCbcEncrypt, and wc_CamelliaCbcDecrypt return MISSING_KEY
when no key has been set. Mirrors the existing 3DES keySet guard.
Add a regression test covering the unkeyed and garbage key-size paths.
Daniel Pouzzner
Tobias Frauenschläger
David Garske
Mattia Moffa
Yosuke Shimizu