Hi all,
A follow-up to the below question. Since I did not receive any helpful replies on this, I did some experiments and came up with a solution that seems to work for me:
1. When new data arrives on TCP layer and the TLS handshake is finished, I call mbedtls_ssl_read() with len = 0. This calls mbedtls_ssl_read_record() internally and causes the record layer to process the next record (unless there is still previously processed application data waiting to be read by the application). 2. If this succeeds, I take mbedtls_ssl_context->private_in_msglen to notify my application about how much data it may read. As a sanity check I verify that mbedtls_ssl_context->private_in_msgtype == MBEDTLS_SSL_MSG_APPLICATION_DATA. 3. The application reads the amount of data it requires. This results in one or multiple calls to mbedtls_ssl_read() with len > 0 until the entire application data contained in the current record is read. 4. Back to 1.
This will only consider one single application data record at a time. If there are multiple records waiting to be processed by the record layer, the application is notified for each application data record individually AND only after the "current" one has been completely read by the application.
This approach seems to work in that it allows me to notify the application about new data and (a lower bound of) its size without having to buffer that data in my "TLS socket". However, I have the following concerns with it and would be grateful for any feedback on these:
1. I'm calling mbedtls_ssl_read(<context>, buf = nullptr, len = 0). This results in a call to memcpy(nullptr, <internal_buffer>, 0). While this will work in most implementations of memcpy, it is undefined behavior. Passing a valid dummy pointer would help, but I think a check (n == 0?) before the memcpy would be the better solution. 2. Related to 1: Is it legitimate to call mbedtls_ssl_read with len = 0? I think the documentation is somewhat ambiguous here: It does not prohibit len = 0, but the expected return value of 0 is used to indicate an error. There is no way to distinguish between a "successful" read of 0 bytes and an error condition.
Thanks for any feedback on this. Jan
________________________________________ Von: Bruckner, Jan via mbed-tls mbed-tls@lists.trustedfirmware.org Gesendet: Freitag, 26. August 2022 11:12 An: mbed-tls@lists.trustedfirmware.org Betreff: [External] [mbed-tls] Get size of available application data without calling mbedtls_ssl_read()
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.
Hi all,
I'd like to know if there is some way to retrieve the currently available number of bytes of application data without calling mbedtls_ssl_read()?
I'm writing a "TLS socket" for higher layers to use and would like to notify them when new application data is available, tell them how much it is, but leave it up to them when and how much to retrieve. I'd like to prevent having to buffer all application data inside my TLS socket, because that would mean copying it once from mbedtls' buffer to my socket and then again from there to the application whenever it actually requests the data.
After a quick look into the sources, it seems like, if at all, this might be possible for single records. But all related fields are private and I could not find any API for this.
Issue #551 [1] seems related, but is more about peeking into the application data, while I would be fine with knowing just the size of available application data.
Thanks for any hints on how I could achieve this.
Best regards, Jan
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Mbed-2DTLS_m...
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -- mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org