To be standard compliant (see reference below), and because we (to quote s2n's DEVELOPMENT-GUIDE) also shouldn't "pass the buck" and place the burden of subtle or complicated TLS-specific decision making upon application authors and system administrators; I think reading unexpected messages should cause a fatal alert to be written to conn->reader_alert_out and s2n_flush() to be called on the connection.

However, almost immediately after starting to read s2n code carefully, I noticed a case where this doesn't happen:

tls/s2n_handshake_io.c: line 249 onward (in handshake_read_io()):

if (record_type == TLS_APPLICATION_DATA) {
    S2N_ERROR(S2N_ERR_BAD_MESSAGE);
} else if (record_type == TLS_CHANGE_CIPHER_SPEC) {
        if (s2n_stuffer_data_available(&conn->in) != 1) {
            S2N_ERROR(S2N_ERR_BAD_MESSAGE);
        }
        [...]
}

-1 and an errno are immediately returned to the application (through parent function s2n_negotiate()), but no cleaning up is performed at all - not even the record containing the bogus data is wiped, even though all the other conditional branches in s2n_handshake_io all call GUARD(s2n_stuffer_wipe(&conn->header_in)); GUARD(s2n_stuffer_wipe(&conn->in)); conn->in_status = ENCRYPTED; when done.

Just wondering if that's intentional; and if so, why? Wouldn't it be wiser to shut down and wipe the connection ASAP?

*) reference ---------------------------------------------------------------------------------------------

https://tools.ietf.org/html/rfc5246#section-7.2.2

Error handling in the TLS Handshake protocol is very simple. When an
error is detected, the detecting party sends a message to the other
party. Upon transmission or receipt of a fatal alert message, both
parties immediately close the connection. Servers and clients MUST
forget any session-identifiers, keys, and secrets associated with a
failed connection. Thus, any connection terminated with a fatal
alert MUST NOT be resumed.

unexpected_message
An inappropriate message was received. This alert is always fatal
and should never be observed in communication between proper
implementations.

https://tools.ietf.org/html/rfc5246#section-6

Implementations MUST NOT send record types not defined in this
document unless negotiated by some extension. If a TLS
implementation receives an unexpected record type, it MUST send an
unexpected_message alert.