The "NOTES" section of the documentation for ERR_GET_REASON() say that "Applications should not make control flow decisions based on specific error codes... [unless] it is explicitly documented as such." https://www.openssl.org/docs/man3.0/man3/ERR_GET_REASON.html SSL_R_UNEXPECTED_EOF_WHILE_READING does not appear to be documented in version >= 3.0. However, it is documented as a future change in the BUGS section of version 1.1.1 documentation for SSL_get_error(). https://www.openssl.org/docs/man1.1.1/man3/SSL_get_error.html So is SSL_R_UNEXPECTED_EOF_WHILE_READING something that can be relied on going forward? I'm hoping the missing documentation is just an oversight, and it was intended to be documented (and presumably will be soon) so that the ERR_GET_REASON() "NOTE" doesn't apply. ---- I'm also aware of the related mailing list discussion that ultimately resulted in the creation of the SSL_OP_IGNORE_UNEXPECTED_EOF option, which is documented. But making the decision to use this option up front early in a connection seems imperfect, since a higher-level protocol's ability to detect a truncation attack may depend on various details of that protocol, such as which protocol variation(s) are in use, or precisely where in the conversation it is truncated. This is certainly true of HTTP's various content-length/transfer-encoding:chunked/untilEOF variations for the end of a body... https://www.openssl.org/docs/man3.0/man3/SSL_CTX_set_options.html https://mta.openssl.org/pipermail/openssl-project/2020-May/001975.html https://mta.openssl.org/pipermail/openssl-project/2020-May/001976.html I have long had a connection abstraction that can cleanly represent this ambigous maybe-attack state, and can let higher-level protocols decide what to do on a case-by-case basis. I would just like to know if I can rely on SSL_R_UNEXPECTED_EOF_WHILE_READING indicating I should set my version of the state, or if is likely to change yet again... - Matthew Ogilvie
