Closed derhex3r closed 1 year ago
Thank you for your feedback.
The "record from another epoch" message indeed comes from https://github.com/Mbed-TLS/mbedtls/blob/development/library/ssl_msg.c#L3678-L3684 and the corresponding comment mentions that this should be handled in the caller.
I'll have to look into this. Also note that I'd gratefully accept a PR as well.
@derhex3r: Thank you for your contribution again! I've been thinking about this. As the code I've quoted above shows, there is not way to rise this error to Python as it doesn't even leave the C function where it's been generated. I wouldn't know how to handle it in my TLSWrappedSocket
either as the socket already does what it's supposed to do, transparently.
I think the handling for this use case has to occur in user code, that is, the server you write using these libraries.
In the present case, the server should just close and reset the TLSWrappedSocket
or TLSWrappedBuffer
.
Thanks! Do I understand that right that if I will just TLSWrappedSocket I will lose gotten ClientHello message? Do you have some ideas about how can I establish a new TLSWrappedSocket with this ClientHello message if I will just close the old one?
Unless I misunderstood, the best is to reset the connection and restart the handshake.
I am submitting a …
Description
When DTLS clients use the same port and try to reconnect appears mbedtls debug log error which I can not handle on the python level. Is there some way to intercept this error in python code? Or somehow make the server handle it like an epoch 0 message instead of just dropping it?
Current behavior
We are able to see this error message in the mbedtls debug log but there is no error rising in the python code.
Expected behavior
Rise some Python error that can be handled correctly. In the best case - make mbedtls server handle the same client hello message again as the epoch 0 message without resending it from the client.
Steps to reproduce
Minimal demo of the problem
Server-side code:
Client-side code: