Hello

For now I am using wolfSSL interfaces to send (encrypt) and receive (decrypt) applicative messages in a socket like way. I mean by that :
- I provided callbacks to wolfSSL for those actions via the wolfSSL_CTX_SetIORecv() and wolfSSL_CTX_SetIOSend() to get/set  data from/to communication media side
- And I am calling wolfSSL_read() and wolfSSL_write() from application side of wolfSSL lib

So my application calls wolfSSL_write() to encrypt data that will cause a callback call that will post the encrypted applicative message to the sending media ...
And my application calls wolfSSL_read() for wolfssL to check via the receiving callback if something has been received and if so, decrypts it and return it back to my application ...

But this works in a socket like way, with buffer where the sending callback posts to and the receiving callback reads from (i.e. the socket like  mechanism)....


Is there a way to invert the mechanism for the receving side ...


I mean my SW receives message from the peer ...
Instead of putting it in a buffer .. and calling wolfSSL_read() that will call my receving callback that will return the decrypted messages ... (this means I need a buffer where I put received encrypted messages ... difficult to dimension it ...)
So instead of this, is there a way to configure wolfSSL the other way for reception ...
I mean I call a wolfSSL service to directly send recevied encrypted data to wolfSSL  ... and once decrypted, colffSSL calls a callback to send it ot the appli ... This way, I wouldn't need an intermediary  buffer in reception ...

I agree that 95 % of applicatiosn should work like my code is currently implemented as it is a socket like way ... but my comm media environment is not socket like at all ... I do not have socket acting as buffers for the callbacks called by wolfSSL_read() and wolfSSL_write(), so I am impelmenting myself buffers in front of the callbacks to artificially simlulate a socket like env ...

So I am wondering if the reception side could work the other way ... A service to directly send the encrypted received message to wolfSSL and wolfSSL calling a callback to provide it to my application.

Thanks in advance.

Philippe Monnie

2

(5 replies, posted in wolfSSL)

Hello Anthony

I just posted the question to support@wolfssl.com as requested.

Regards.

Hello

RFC 8449 from august 2018 describes the Record Size Limit Extension for TLS.
In its section 5, this RFC is indicating the MAX_FRAGMENT_LENGTH extension is deprecated and now, the new RECORD_SIZE_LIMIT extension should be used instead.

I am not sure but as far as I have been able to check in DTLS1.3 wolfSSL product  ... I found the MAX_FRAGMENT_LENGTH extension in wolfSSL product, but not the RECORD_SIZE_LIMIT one. At least I found something with SIZE_LIMIT in its name but it is a internal data and not something activable via specific flag like other extensions. So I suppose it is not corresponding to the  RECORD_SIZE_LIMIT extension.

So my questions :

Do I missed something and is the RECORD_SIZE_LIMIT extension already present in wolfSSL code ? If so, from which version ? And with which flag can I activate it ?

If not, is it planned to have this extension implemented in a future product version ? When would it be available ?

Thanks in advance for your answers.


philipm