| Age | Commit message (Collapse) | Author |
|---|
|
Made decrypted output and empty-record MAC verification deterministic across TLS build profiles.
Assisted-by: Codex (gpt-5.6-sol) <[email protected]>
|
|
Authenticate zero-length application records through the normal MAC verification path and preserve record offsets when an empty record ends at a TCP packet boundary.
Added regression coverage for valid and modified MACs, coalesced records, and split TCP packets.
Assisted-by: Codex (gpt-5.6-sol) <[email protected]>
|
|
* Fixed renewed certificate test regressions
* Fixed OpenSSL server readiness detection
Assisted-by: Codex (gpt-5.6-sol) <[email protected]>
|
|
Advertise RSA-PSS for TLS 1.3 and the corresponding RSA PKCS#1 schemes for TLS 1.2 fallback. Precompute the exact extension length and cover the wire format and buffer boundaries with a focused regression test.
Assisted-by: Codex (gpt-5.6-sol) <[email protected]>
|
|
Replace expired TLS, DTLS, and MQTT credentials with test-only certificates valid through 2046. Keep PEM and embedded DER/CRL fixtures synchronized, retain the legacy curve and extension cases, and add a CTest validation that checks validity, keys, chains, CRLs, and embedded byte arrays.
Assisted-by: Codex (gpt-5.6-sol) <[email protected]>
|
|
* Fix TLS 1.3 CertificateVerify transcript hash length (use ciphersuite hash)
Per RFC 8446 §4.4.3 the CertificateVerify content embeds
Transcript-Hash(Handshake Context), whose length is fixed by the
negotiated ciphersuite's hash — not by the signature scheme's hash.
The dynamic length introduced during the #377 review keyed it to the
signature scheme's hash; the two differ whenever the peer signs with
a hash other than the suite's, e.g. an ECDSA P-384 certificate
(ecdsa_secp384r1_sha384) with TLS_AES_128_GCM_SHA256 — the only TLS 1.3
suite currently enabled. In that case 48 bytes were copied from a
32-byte transcript hash slot, corrupting the signed content on the send
side and rejecting valid peer signatures on the verify side.
Key the transcript length to the session ciphersuite hash (with the
same SHA-256 fallback as _nx_secure_tls_1_3_transcript_hash_save); the
signature scheme's hash still digests the assembled content and
parameterizes RSA-PSS.
* Add a regression test for the TLS 1.3 CertificateVerify transcript hash length
Calls _nx_secure_tls_send_certificate_verify and
_nx_secure_tls_process_certificate_verify directly with a signature-scheme
hash (SHA-384) that differs from the ciphersuite hash (SHA-256), and
captures via a spy hash method the exact byte count copied into the
CertificateVerify content. Asserts 32 bytes (the ciphersuite's SHA-256,
correct per RFC 8446 §4.4.3), not 48 (the signature scheme's SHA-384,
what the bug copied).
* Documented why the SHA-384 test case cannot run end to end
---------
Co-authored-by: Claude Fable 5 <[email protected]>
|
|
* Fix TLS 1.3 server: don't send NewSessionTicket (resumption is unsupported)
_nx_secure_tls_1_3_server_handshake.c sent a NewSessionTicket after every
Client Finished, advertising session resumption to the client. But
_nx_secure_tls_process_clienthello_psk_extension explicitly rejects any
PSK with age != 0 (i.e. every real resumption attempt) with
NX_SECURE_TLS_BAD_CLIENTHELLO_PSK_EXTENSION — the existing implementation
only supports external PSKs.
Net effect on clients that act on the advertised ticket (Java JSSE in
particular): every other handshake fails. Conn N succeeds + caches the
ticket; conn N+1 replays the ticket → server sends Alert(internal_error)
→ JSSE invalidates the cache; conn N+2 succeeds; loop.
Fix: skip the NewSessionTicket send. The PSK consumer code stays as-is
so any future external-PSK use case is unaffected.
* Trim the source comment left by the NewSessionTicket removal
The comment that replaced the removed block ended up carrying the
whole incident story: the JSSE trigger, the alert path, why the stub
was harmful. That belongs in the commit that made the change, not in
a comment future readers will hit out of context.
Keep only what the code is now. No ticket is sent because resumption
is not implemented. RFC 8446 §4.6.1 makes the message optional. The
PSK extension handler is the place resumption would also need to
change.
* Document why send_newsessionticket is now uncalled
After the previous fix, this function has no callers in the library.
That is deliberate: it stays as a starting point for real TLS 1.3
session resumption when someone gets to it. Without a note, the next
dead-code sweep will find an unreferenced global and reasonably
propose deleting it.
Add a NOTE in the header block spelling out three things. The
function is kept on purpose, not by accident. The ticket it builds
is a placeholder — no server state, fixed identity string — so it
cannot be used as is. And the reasoning for not calling it lives in
the server handshake, with the RFC 8446 pointer for the fact that
the message is optional.
CALLED BY is updated to match.
* Exclude send_newsessionticket from coverage reports
The previous fix left this file with no callers. Under any coverage
config that compiles TLS 1.3 — tls_1_3_enable_build_coverage and
sesip_build_coverage — it now reports 0% across the board. CI does
not enforce a threshold, so nothing fails, but the project aims for
100% and a file going to zero is not the shape we want.
Add a small common exclude list, applied to every coverage run,
containing just this file. The reason it is dead is documented in
its own header block, and referencing that keeps the two pieces of
information in sync. The default_build_coverage block is unchanged.
* Add regression test asserting no NewSessionTicket after handshake
Locks in the previous fix. The test completes a full TLS 1.3
handshake between a NetX client and a NetX server, gives the server
one periodic tick to flush anything queued after client Finished,
then peeks the client's raw TCP receive queue with NX_NO_WAIT. In
the fixed server nothing arrives. In the pre-fix server the stub
NewSessionTicket record lands there and the peek returns NX_SUCCESS
instead of NX_NO_PACKET.
The peek runs on the raw socket rather than through
nx_secure_tls_session_receive, because the TLS layer would consume a
post-handshake NewSessionTicket silently and we could not tell the
difference. A semaphore holds the server side open until the client
has done its check, so the server's close_notify does not pollute
the peek.
The half of the maintainer's ask that needs a crafted PSK-carrying
ClientHello is left for the PSK-handler follow-up, per the review.
|
|
§5.4) (#401)
* Fix TLS 1.3 record padding strip in _nx_secure_tls_process_record (RFC 8446 §5.4)
The inner content type was read as the literal last byte of the
decrypted plaintext. Per RFC 8446 §5.4 that byte is followed by an
arbitrary-length zero padding, so the receiver must scan back from
the end skipping zeros to find it.
Without this, any client that pads its TLS 1.3 records gets a fatal
`unexpected_message` alert on its first record. Java JDK HttpClient
pads by default since 11 (traffic-analysis resistance), so every Java
HTTPS client tripped on this. Reproducible with OpenSSL using
`-record_padding N`.
* Move scan_offset to top-of-function locals, drop scoped block
Follow the existing style of nx_secure_tls_process_record.c: all locals
declared alongside message_length and bytes_copied at the top of the
function, no nested scope just to introduce one variable. Trim the
TLS 1.3 de-padding comment to say what the code does now — the history
of why the previous version was wrong lives in the previous commit
message and PR description.
* Return unexpected_message when the plaintext has no inner content type
RFC 8446 §5.4 requires "unexpected_message" when a decrypted record
contains only padding. NX_SECURE_TLS_UNEXPECTED_MESSAGE already maps
to the correct alert (10, fatal) in nx_secure_tls_map_error_to_alert.c;
NX_SECURE_TLS_INVALID_PACKET fell through to internal_error, which
misidentified a peer protocol violation as our own bug.
The extract-failure path just above still returns INVALID_PACKET —
that one really is a local packet-handling error and internal_error
is the honest signal.
* Scan the plaintext directly instead of calling extract per byte
nx_packet_data_extract_offset() walks the packet chain from the head on
every call. Since the de-padding scan starts at the end of the record,
each call traversed the whole chain to reach the last fragment before
copying a single byte — one full walk per byte examined. On a maximally
padded 16 KB record that is on the order of 16 000 chain walks handed
to the peer, which the RFC lets it perform arbitrarily.
Walk the fragments once, remember the offset of the last non-zero byte.
The traversal always visits every plaintext byte so the cost no longer
depends on the amount of padding, which matches the stance the
neighbouring TLS 1.2 path already takes on padding-related timing
channels (see the MAC-check comment a few lines below).
The extract-failure branch disappears with the extract call, so the
remaining error path is exactly the peer protocol violation
(all-zero plaintext) reporting unexpected_message.
* Add regression tests for the TLS 1.3 record de-padding
Cover the four cases that matter for the §5.4 fix:
1. Padded record — inner type recovered, length excludes both the
type byte and the padding.
2. All-zero plaintext — rejected with unexpected_message.
3. Unpadded record — behaviour matches the pre-fix arithmetic
(length - 1). This is the regression-risk assertion for existing
traffic that never triggered the bug.
4. Chained-packet plaintext — the scan walks through NX_PACKET
fragments, not just the head. Forced by using a plaintext larger
than a single pool packet.
Requires exposing the de-padding scan as _nx_secure_tls_1_3_strip_padding
so the test can drive it directly without standing up a full TLS 1.3
AEAD session. _nx_secure_tls_process_record now delegates to the same
helper, so the behaviour under test is identical to the production path.
* Declared the TLS 1.3 de-padding helper in the header, as its siblings are
_nx_secure_tls_1_3_strip_padding had external linkage but no declaration in any
header: it was forward declared in nx_secure_tls_process_record.c and declared
again with extern in the test that calls it. That is the one shape this tree does
not use. nx_secure_tls.h already carries 135 internal _nx_secure_* prototypes,
including a run of _nx_secure_tls_1_3_* functions, while the other internal
function in this same source file, _nx_secure_tls_packet_trim, is static because
nothing outside needs it. So an internal function is either declared in the
header or static, and this one is used from outside its translation unit.
Declare it in nx_secure_tls.h beside _nx_secure_tls_1_3_crypto_init, and drop
both duplicate declarations. No behaviour change, and it removes a MISRA 8.7
deviation that would otherwise have to be documented rather than avoided.
Verified by rebuilding nx_secure_tls_process_record_test against the header
instead of the extern: it links, and all four de-padding cases pass.
---------
Co-authored-by: Frédéric Desbiens <[email protected]>
Assisted-by: Claude Code (Opus 5) <[email protected]>
|
|
Applied the standard MIT license header to all project-owned C, header,
assembly, shell, and Python files that were missing a copyright notice.
Third-party, toolchain startup, and auto-generated files were excluded.
Co-authored-by: Copilot <[email protected]>
|
|
* add support for parsing ASN.1 GeneralizedTime
* fix validity format field error
* changed CertMsg notBefore format to be in GeneralizedTime format
* changed notBefore time to be in GeneralizedTime format
* changed notAfter time to be in GeneralizedTime format
* expand tests for invalid date format
* update function comments
* update function comments
---------
Co-authored-by: Frédéric Desbiens <[email protected]>
|
|
* Fixed server PSK identity selection for ECDHE-PSK
* Fixed selected client PSK identity preservation
Implemented logic to cache the PSK store entry selected by the server identity hint so ClientKeyExchange emits the matching identity when clients use the PSK store path.
Cast the ECC supported-group test value to USHORT so the PSK identity regression builds cleanly with -Werror on Linux.
Assisted-By: Codex (OpenAI GPT-5.5) <[email protected]>
|
|
* key_size_in_bits should be shifted right to convert to bytes
* Add HKDF init length regression coverage
---------
Co-authored-by: Frédéric Desbiens <[email protected]>
|
|
|
|
Fix length checking in supported version extension, add test
|
|
|
|
The check is in the function
_nx_secure_tls_process_clienthello_psk_extension and was reported
as a vulnerability.
|
|
|
|
|
|
|
|
|
|
|
