Ticket Change Details
EuroTcl/OpenACS 11 - 12 JULY 2024, VIENNA

Artifact ID: 515aa59d81d5f5c1a9c81677f6d92e7aeb8fce674a2cff86531ce1589cf709bf
Ticket: 88c0c8496999c48f513eb4f97aaa0ac9829b35d3
EOF handling potentially broken with OpenSSL 1.1.1e or newer
User & Date: azazel on 2023-11-10 21:15:10

  1. icomment:
    There is an SSL option governing this behaviour: `SSL_OP_IGNORE_UNEXPECTED_EOF`.  There are reasons why OpenSSL made this change.  See:
    * https://github.com/openssl/openssl/issues/10880
    * https://github.com/openssl/openssl/pull/10882
    My initial thought was unconditionally to set the option:
    	--- tls.c
    	+++ tls.c
    	@@ -1212,10 +1212,13 @@
    	     SSL_CTX_set_app_data( ctx, (VOID*)interp); /* remember the interpreter */
    	     SSL_CTX_set_options( ctx, SSL_OP_ALL);     /* all SSL bug workarounds */
    	     SSL_CTX_set_options( ctx, off);    /* all SSL bug workarounds */
    	+    SSL_CTX_set_options( ctx, SSL_OP_IGNORE_UNEXPECTED_EOF);
    	     SSL_CTX_sess_set_cache_size( ctx, 128);
    	     if (ciphers != NULL)
    	        SSL_CTX_set_cipher_list(ctx, ciphers);
    However, given that this change in behaviour was intended to reveal errors that were previously unreported, I think it may make sense to add an option (this is what openssl did for s_client): _e.g._, `-ignoreunexpectedeof bool`.  The next question is whether to default it to true or false.  To preserve backwards compatibility and be liberal in what we accept, my inclination would be to default to true.
  2. login: "azazel"
  3. mimetype: "text/x-markdown"
  4. priority changed to: "Immediate"
  5. resolution changed to: "Open"