On 24/11/2022 07:57, Neelabh Mam wrote:
Hi,
With my openssl based FTPS client (non-blocking bio) targeting TLS1.3, I
see that immediately after a successful data channel handshake (with
session reuse), a dummy change_cipher_spec record and a non-application
data record are sent as part of the directory listing data. Same holds
true for file downloads as well..(again with session reuse). This seems
to be in line with the last paragraph in Appendix D.4 of RFC8446 which
mandates a change_cipher_spec record to be sent from the server in case
of session reuse. I could manually filter out the non-application data
records from the actual data.. However, I was wondering if there's some
api/setting in openssl that would do that at an API level.. as this
looks like it should ideally be part of openssl workflow. But then what
I am also not sure about is why the receipt of new session ticket data
on the control channel does not bubble up as application data ? Openssl,
from what I can tell, seems to be "consuming" it (new session data)
internally. The earlier 2 messages however, do get exposed out of
ssl_read and eventually become part of application data.
The only data you should be getting out of an `SSL_read` call is
application data. If you're getting handshake or CCS messages as part of
app data then something has gone very surprisingly wrong. I cannot
imagine what would cause that.
You might want to open a github issue about that to dive into it in more
detail.
Matt
Is it like :
the message type warrants one to be exposed (change_cipher_spec) and the
other to be handled internally (new session data) ? Could we please
advise on openssl's standard operating workflow here ? Also, would I
have to add logic to manually separate these 2 non-application records
from the application data ? Is that how it is supposed to be ? Thank you.
Neelabh
