Found two RFC compliance gaps while doing differential testing of TLS record layer handling. Both are informational / compliance — no direct security impact.
1. Record ProtocolVersion not validated before handshake negotiation
s2n_record_header_parse() in tls/s2n_record_read.c defers version validation until conn->actual_protocol_version_established is set. This means pre-negotiation records with clearly invalid version bytes (like 0x0000 or 0x0403, which aren't even in the {03,XX} range allowed by RFC 5246 Appendix E.1) pass through unchecked.
The comment in the code references RFC 5246 Appendix E.1 for leniency with {03,XX} values, but the implementation doesn't actually enforce the {03,XX} constraint — it skips validation entirely until after the ServerHello.
wolfSSL rejects non-{03,XX} versions at the record layer before handshake processing. mbedTLS rejects version mismatches after ClientHello parse.
2. Unknown ContentType silently discarded
When s2n_handshake_read_io encounters a ContentType that isn't change_cipher_spec(20), alert(21), handshake(22), or application_data(23), it silently consumes and discards the record.
The code has the comment "Ignore record types that we don't support" in tls/s2n_handshake_io.c.
Both RFC 8446 §5 and RFC 5246 §6.2.1 say the receiver MUST terminate the connection with unexpected_message(10) alert for unrecognized content types. Silently discarding is not compliant.
Comparison: wolfSSL and mbedTLS both send fatal alerts on unknown content types.
Found through differential fuzzing of TLS implementations (PathDiff project).
Found two RFC compliance gaps while doing differential testing of TLS record layer handling. Both are informational / compliance — no direct security impact.
1. Record ProtocolVersion not validated before handshake negotiation
s2n_record_header_parse()intls/s2n_record_read.cdefers version validation untilconn->actual_protocol_version_establishedis set. This means pre-negotiation records with clearly invalid version bytes (like 0x0000 or 0x0403, which aren't even in the {03,XX} range allowed by RFC 5246 Appendix E.1) pass through unchecked.The comment in the code references RFC 5246 Appendix E.1 for leniency with {03,XX} values, but the implementation doesn't actually enforce the {03,XX} constraint — it skips validation entirely until after the ServerHello.
wolfSSL rejects non-{03,XX} versions at the record layer before handshake processing. mbedTLS rejects version mismatches after ClientHello parse.
2. Unknown ContentType silently discarded
When
s2n_handshake_read_ioencounters a ContentType that isn'tchange_cipher_spec(20),alert(21),handshake(22), orapplication_data(23), it silently consumes and discards the record.The code has the comment "Ignore record types that we don't support" in
tls/s2n_handshake_io.c.Both RFC 8446 §5 and RFC 5246 §6.2.1 say the receiver MUST terminate the connection with
unexpected_message(10)alert for unrecognized content types. Silently discarding is not compliant.Comparison: wolfSSL and mbedTLS both send fatal alerts on unknown content types.
Found through differential fuzzing of TLS implementations (PathDiff project).