wolfSSL/wolfssl
1
0
Fork 1
mirror of https://github.com/wolfSSL/wolfssl.git synced 2026-07-05 22:20:49 +02:00
Code Issues Packages Projects Releases Wiki Activity
Files
2c030ddb0dd7b40904bd571a052d64a18d32df4e
wolfssl/tests/test-maxfrag.conf
T
Juliusz Sosinowicz 38b52d8079 nginx 1.28.1 
### `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.
2026-02-25 15:19:13 +01:00

181 lines
3.4 KiB
Plaintext
Raw Blame History

# server TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
-v 3
-l ECDHE-ECDSA-AES256-GCM-SHA384
-c ./certs/server-ecc.pem
-k ./certs/ecc-key.pem
# client TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
-v 3
-l ECDHE-ECDSA-AES256-GCM-SHA384
-A ./certs/ca-ecc-cert.pem
-F 1
# server TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
-v 3
-l ECDHE-RSA-AES256-GCM-SHA384
# client TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
-v 3
-l ECDHE-RSA-AES256-GCM-SHA384
-F 1
# server TLSv1.2 DHE-RSA-AES256-GCM-SHA384
-v 3
-l DHE-RSA-AES256-GCM-SHA384
# client TLSv1.2 DHE-RSA-AES256-GCM-SHA384
-v 3
-l DHE-RSA-AES256-GCM-SHA384
-F 1
# server TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
-v 3
-l ECDHE-ECDSA-AES256-GCM-SHA384
-c ./certs/server-ecc.pem
-k ./certs/ecc-key.pem
# client TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
-v 3
-l ECDHE-ECDSA-AES256-GCM-SHA384
-A ./certs/ca-ecc-cert.pem
-F 2
# server TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
-v 3
-l ECDHE-RSA-AES256-GCM-SHA384
# client TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
-v 3
-l ECDHE-RSA-AES256-GCM-SHA384
-F 2
# server TLSv1.2 DHE-RSA-AES256-GCM-SHA384
-v 3
-l DHE-RSA-AES256-GCM-SHA384
# client TLSv1.2 DHE-RSA-AES256-GCM-SHA384
-v 3
-l DHE-RSA-AES256-GCM-SHA384
-F 2
# server TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
-v 3
-l ECDHE-ECDSA-AES256-GCM-SHA384
-c ./certs/server-ecc.pem
-k ./certs/ecc-key.pem
# client TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
-v 3
-l ECDHE-ECDSA-AES256-GCM-SHA384
-A ./certs/ca-ecc-cert.pem
-F 3
# server TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
-v 3
-l ECDHE-RSA-AES256-GCM-SHA384
# client TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
-v 3
-l ECDHE-RSA-AES256-GCM-SHA384
-F 3
# server TLSv1.2 DHE-RSA-AES256-GCM-SHA384
-v 3
-l DHE-RSA-AES256-GCM-SHA384
# client TLSv1.2 DHE-RSA-AES256-GCM-SHA384
-v 3
-l DHE-RSA-AES256-GCM-SHA384
-F 3
# server TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
-v 3
-l ECDHE-ECDSA-AES256-GCM-SHA384
-c ./certs/server-ecc.pem
-k ./certs/ecc-key.pem
# client TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
-v 3
-l ECDHE-ECDSA-AES256-GCM-SHA384
-A ./certs/ca-ecc-cert.pem
-F 4
# server TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
-v 3
-l ECDHE-RSA-AES256-GCM-SHA384
# client TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
-v 3
-l ECDHE-RSA-AES256-GCM-SHA384
-F 4
# server TLSv1.2 DHE-RSA-AES256-GCM-SHA384
-v 3
-l DHE-RSA-AES256-GCM-SHA384
# client TLSv1.2 DHE-RSA-AES256-GCM-SHA384
-v 3
-l DHE-RSA-AES256-GCM-SHA384
-F 4
# server TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
-v 3
-l ECDHE-ECDSA-AES256-GCM-SHA384
-c ./certs/server-ecc.pem
-k ./certs/ecc-key.pem
# client TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
-v 3
-l ECDHE-ECDSA-AES256-GCM-SHA384
-A ./certs/ca-ecc-cert.pem
-F 5
# server TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
-v 3
-l ECDHE-RSA-AES256-GCM-SHA384
# client TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
-v 3
-l ECDHE-RSA-AES256-GCM-SHA384
-F 5
# server TLSv1.2 DHE-RSA-AES256-GCM-SHA384
-v 3
-l DHE-RSA-AES256-GCM-SHA384
# client TLSv1.2 DHE-RSA-AES256-GCM-SHA384
-v 3
-l DHE-RSA-AES256-GCM-SHA384
-F 5
# server TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
-v 3
-l ECDHE-ECDSA-AES256-GCM-SHA384
-c ./certs/server-ecc.pem
-k ./certs/ecc-key.pem
# client TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384
-v 3
-l ECDHE-ECDSA-AES256-GCM-SHA384
-A ./certs/ca-ecc-cert.pem
-F 6
# server TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
-v 3
-l ECDHE-RSA-AES256-GCM-SHA384
# client TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
-v 3
-l ECDHE-RSA-AES256-GCM-SHA384
-F 6
# server TLSv1.2 DHE-RSA-AES256-GCM-SHA384
-v 3
-l DHE-RSA-AES256-GCM-SHA384
-6
# client TLSv1.2 DHE-RSA-AES256-GCM-SHA384
-v 3
-l DHE-RSA-AES256-GCM-SHA384
-F 1
-6
Reference in New Issue View Git Blame Copy Permalink