TLS1.3 change_cipher_spec as part of application data

[Matt Caswell]

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