- Add a GitHub Actions workflow to automate testing of Python integration
- Implement Blake2b and Blake2s hash functions into the EVP API.
- Improve OpenSSL compatibility by standardizing ASN.1 encoding for
serial numbers and registered IDs, streamlining cipher stack management, and optimizing stack node copying.
- Enforce maximum fragment size during data transmission to ensure proper TLS/DTLS record fragmentation.
When a server uses a HRR to negotiate the key exchange group to use, the
selected group is advertised in the HRR key share extension.
Furthermore, this group is also stored in the Cookie that is sent to the
client. When the server receives the second CH, the group used in the
key share extension MUST be the one of the HRR.
For stateless DTLS servers, the handling of this check had a bug. The
key share group of the HRR is stored in the ssl->hrr_keyshare_group
variable and is checked against the received key share of the second CH.
However, in the stateless server case, another CH message may be
received inbetween the two CH message of the desired client, potentially
overwriting the ssl->hrr_keyshare_group variable. This then causes
handshake failures when the ssl->hrr_keyshare_group variable contains
another group than the second CH message of the desired client.
To fix this, the following changes are conducted:
1. Disable the ssl->hrr_keyshare_group check for stateless DTLS 1.3
servers. As long as the server is stateless, CHs from multiple
clients may be received that individually cause HRRs with different
groups. For each of these clients, the HRR group is properly stored
in the cookie.
2. When a valid cookie is received from the client, the server becomes
stateful. In this case, we now parse the cookie for a stored HRR
group in the RestartHandshakeHashWithCookie() method. If present,
we restore the ssl->hrr_keyshare_group variable to this group to
ensure the error checks succeed.
3. Move the check of ssl->hrr_keyshare_group of the the KeyShare
extension parsing logic into the general TLS1.3 ClientHello parsing
after extension handling. This ensures that the order of the cookie
and key share extensions does not matter.
A new test is added to check for this behavior.
RSA-PSS signed certificates contain a valid RSA public key that can be
used for key transport, but wc_PKCS7_AddRecipient_KTRI and the
EnvelopedData/AuthEnvelopedData encode paths rejected them because they
only checked for RSAk. Allow RSAPSSk to fall through to the RSAk key
transport path, and always use RSAk as the KeyEncryptionAlgorithmIdentifier
since the operation is RSA encryption, not RSA-PSS signing.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
### `wolfssl/internal.h`
- **`InternalTicket` struct gains a flexible array member**: A new `peerCert[]` field (with a preceding `peerCertLen[2]`) is added to `InternalTicket`. This allows the peer's DER-encoded certificate to be stored directly inside the session ticket.
- **`ExternalTicket` struct becomes variable-length**: The `enc_ticket` field is changed from a fixed-size array to a flexible array member (`byte enc_ticket[]`). The `mac` field is removed from the struct — the MAC is now placed dynamically after the encrypted data in `enc_ticket`.
### `src/internal.c`
- The `GetRecordHeader` function now only adds `MAX_COMP_EXTRA` to the maximum allowed record size when `ssl->options.usingCompression` is true, tightening the length validation. The max fragment length extension check is now much stricter.
- **Peer certificate is serialized into the ticket**: During ticket creation, the code attempts to find the peer certificate from `ssl->peerCert` or from `ssl->session->chain` (fallback). If found and within `MAX_TICKET_PEER_CERT_SZ`, it's copied into `it->peerCert`. DTLS is explicitly excluded (peer cert length set to 0) to keep ticket size small for MTU constraints. If `HAVE_MAX_FRAGMENT` is defined and max fragment is not `MAX_RECORD_SIZE` for TLS 1.3, the cert is also skipped since `SendTls13NewSessionTicket` doesn't support fragmentation yet.
- **Peer certificate restoration from ticket**: On successful ticket decryption, if the ticket contains a peer certificate (`peerCertLen > 0`), it is decoded back into `ssl->peerCert` via `ParseCertRelative`/`CopyDecodedToX509`, and also added to `ssl->session->chain` via `AddSessionCertToChain`.
- The `CLEAR_ASN_NO_PEM_HEADER_ERROR` macro was rewritten to loop and remove all consecutive PEM no-start-line errors (not just the last one), wrapped in a `do { ... } while(0)` for safety.
- The `SendTicket` function is simplified to use `SendHandshakeMsg` to support fragmenting the larger ticket.
---
### `src/x509.c`
- `loadX509orX509REQFromPemBio` now accepts `TRUSTED_CERT_TYPE` in addition to `CERT_TYPE` and `CERTREQ_TYPE`.
- **Streaming BIO support**: When `wolfSSL_BIO_get_len()` returns ≤ 0 (e.g., pipes/FIFOs), the function no longer returns an error. Instead, it sets an initial buffer of `MAX_X509_SIZE` and dynamically grows (doubling) up to `MAX_BIO_READ_BUFFER` (`MAX_X509_SIZE * 16`) as data is read byte-by-byte.
- **Alternate footer detection**: For `TRUSTED_CERT_TYPE`, the PEM reader also checks for the regular `CERT_TYPE` footer (`-----END CERTIFICATE-----`) in addition to the trusted cert footer (`-----END TRUSTED CERTIFICATE-----`), so it can parse either format.
- Removed two lines that set `cert->srcIdx` to `SIGALGO_SEQ` offset. This makes `cert->srcIdx` reflect the end of parsed certificate data. This is used by `loadX509orX509REQFromBuffer` to detect where auxiliary trust data begins in trusted certificates.
---
### `src/ssl_sk.c`
- Added a `STACK_TYPE_X509_CRL` case to `wolfssl_sk_dup_data` that calls `wolfSSL_X509_CRL_dup` for deep-copying CRL stack elements. Previously, `STACK_TYPE_X509_CRL` fell through to the unsupported default case.
---
### `wolfssl/openssl/ssl.h`
- `sk_X509_dup` now maps to `wolfSSL_shallow_sk_dup` (was `wolfSSL_sk_dup`/deep copy). This matches OpenSSL's behavior where `sk_X509_dup` does a shallow copy.
- `sk_SSL_CIPHER_dup` similarly changed to `wolfSSL_shallow_sk_dup`.
---
### `src/ssl_api_cert.c`
- When `ssl->ourCert` is `NULL` and the SSL owns its cert, the function now checks if `ssl->ctx->ourCert` points to the same certificate (by comparing DER buffers). If so, it returns the ctx's `X509` pointer directly. This maintains pointer compatibility for applications (like nginx OCSP stapling) that use the `X509*` from `SSL_CTX_use_certificate` as a lookup key.
### `src/bio.c`
- When `wolfssl_file_len` returns `WOLFSSL_BAD_FILETYPE` (now returned for pipes/FIFOs), `wolfSSL_BIO_get_len` treats it as length 0 instead of propagating the error.
---
### `tests/test-maxfrag.conf` and `tests/test-maxfrag-dtls.conf`
- Removed `DHE-RSA-AES256-GCM-SHA384` test entries because the ClientKeyExchange doesn't fit in the selected max fragment length.
Add full RSA-PSS (RSASSA-PSS) support to PKCS#7 SignedData
encoding and verification.
This change enables SignerInfo.signatureAlgorithm to use
id-RSASSA-PSS with explicit RSASSA-PSS-params (hash, MGF1,
salt length), as required by RFC 4055 and CMS profiles.
Key changes:
- Add RSA-PSS encode and verify paths for PKCS7 SignedData
- Encode full RSASSA-PSS AlgorithmIdentifier parameters
- Decode RSA-PSS parameters from SignerInfo for verification
- Treat RSA-PSS like ECDSA (sign raw digest, not DigestInfo)
- Fix certificate signatureAlgorithm parameter length handling
- Add API test coverage for RSA-PSS SignedData
This resolves failures when using RSA-PSS signer certificates
(e.g. -173 invalid signature algorithm) and maintains backward
compatibility with RSA PKCS#1 v1.5 and ECDSA.
Signed-off-by: Sameeh Jubran <sameeh@wolfssl.com>
In ImportKeyState(), wordAdj was always zero because it was computed
after clamping wordCount, and the subtraction direction was reversed.
This caused misaligned parsing of all subsequent fields when importing
state from a peer compiled with a larger WOLFSSL_DTLS_WINDOW_WORDS.
Fix both window and prevWindow blocks to compute the adjustment before
clamping, with the correct subtraction direction.
Add test that imports a state buffer with wordCount > WOLFSSL_DTLS_WINDOW_WORDS
to verify the fix.
Add missing bounds validation in wolfSSL_select_next_proto. Three
issues fixed:
1. Outer loop: no check that length byte + position stays within inLen,
allowing XMEMCMP to read past the server protocol list buffer.
2. Inner loop: same missing check for clientNames/clientLen boundary.
3. No-overlap fallback unconditionally dereferences clientNames[0] even
when clientLen is 0, and returns an outLen that may exceed the buffer.
Also reject zero-length protocol entries (invalid per RFC 7301) to
prevent infinite loops.
Add unit test test_wolfSSL_select_next_proto with 8 cases covering NULL
params, normal match, no overlap, malformed length overruns, zero-length
entries, and empty client lists.
JacobBarthelmeh
Daniel Pouzzner
Tobias Frauenschläger
Juliusz Sosinowicz
Hideki Miyazaki
Eric Blankenhorn
Paul Adelsbach
Sameeh Jubran
Sean Parkinson
Marco Oliverio
Andrew Hutchings