1
$\begingroup$

It seems that a tls endpoint can pump more data records even when it has received a re-handshake request from peer.

Also in dtls, new data records would get accepted even while rehandshake is in progress since any of the endpoint does not have way to tell whether those records originated after a handshake message. This is because re-transmission of handshake message gets a new record protocol header sequence number. So looking at record protocol header sequence number is not a good way to tell the ordering of events.

Do the endpoints have any way to tell which data they received before re-handshake completed and which one they received after rehandshake?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
1
$\begingroup$

Section II-B talks about this. The answer to this is implementation-dependent. For example, if you're using GnuTLS, you can get some non-fatal error codes if you try to read after parameters change. Then you can look in your logs and distinguish data from before you got the error code from data that's timestamped afterwards. But you may have to be actively looking or polling for it.

You may have better luck on Stack Overflow with this one for particular implementations.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.