Allow 0 byte read/write in SSL_{read,write}_ex

[WillChilds-Klein]

Issues:

Addresses CryptoAlg-2136

Description of changes:

The primary motivation of this change is to match OpenSSL's behavior for these functions. Relevant links:

• SSL_read_ex docs
• SSL_write_ex docs
• CPython update accounting for this behavior

Call-outs:

• n/a

Testing:

• CI checks

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (a9f7a06) 76.43% compared to head (cec39a7) 76.38%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1316      +/-   ##
==========================================
- Coverage   76.43%   76.38%   -0.06%     
==========================================
  Files         421      421              
  Lines       70974    70980       +6     
==========================================
- Hits        54250    54218      -32     
- Misses      16724    16762      +38     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[darylmartin100]

is the null pointer needed here? Should we always set read_bytes to 0 and return 1 when num == 0?

[WillChilds-Klein]

My goal here was to balance safety with compatibility. from my reading, OpenSSL won't return 1 in that case; it'll segfault. Admittedly, because of the amount of indirection via function pointers in OpenSSL's libssl, I'm not 100% confident in this reading of that code (see below).

So, if indeed my reading is correct and they segfault, I guess the expected behavior of passing null pointer here is "undefined" for OpenSSL. I thought it would be good for us to return an error in that case (as opposed to returning success) because the API's contract is for *read_bytes to be set to the number of bytes read on success. Since we can't do that with a null pointer, per the contract, returning success doesn't make sense in my opinion.

---

My reading of OpenSSL's relevant code:

• SSL_read_ex calls ssl_read_internal, which in turn calls the ssl_read implementation on s->method.
• I believe the implementation for our purposes here (i.e. not DTLS) is ssl3_write, which in turn calls an ssl_write_bytes implementation attached to s->method.
• Presumably, that implementation is ssl3_write_bytes, which never checks the written pointer before dereferencing in the case when 0 bytes have been requested to be written (and 0 bytes have been written, i.e. len == tot == 0 in the code).

Side note -- somebody summed up the whole situation pretty well in an internal comment:

/*
 * This is for the SSLv3/TLSv1.0 differences in crypto/hash stuff It is a bit
 * of a mess of functions, but hell, think of it as an opaque structure :-)
 */