TLS1.3 change_cipher_spec as part of application data

[Neelabh Mam]

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. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20221124/17bb7507/attachment.htm>