Repository navigation
Server ignores handshake after queueing application data from client. #254
Description
Your environment.
- Server: pion/dtls v2.0.0
- Client: nRF9160 (Mbed TLS)
What did you do?
- A client successfully handshakes with a server and sends application data.
- The server goes down, without notifying the client, then starts back up.
- The client continues to send application data. The server log says:
dtls DEBUG: 14:39:43.547692 conn.go:643: received packet of next epoch, queuing packet
dtls TRACE: 14:39:43.547699 handshaker.go:146: [handshake:server] Flight 0: Preparing
dtls TRACE: 14:39:43.547756 handshaker.go:146: [handshake:server] Flight 0: Sending
dtls TRACE: 14:39:43.547768 handshaker.go:146: [handshake:server] Flight 0: Waiting
dtls TRACE: 14:39:44.551177 handshaker.go:146: [handshake:server] Flight 0: Sending
dtls TRACE: 14:39:44.551224 handshaker.go:146: [handshake:server] Flight 0: Waiting
...
- After not receiving a response for some time (application layer), the client decides to restart and initiates a new connection with the server.
What did you expect?
A successful second handshake.
What happened?
The client is completely ignored. There is nothing more in the server logs.
Thoughts
I can work around the issue by blocking the application data that the client sends after the server restart. It is this application data (which the server queues) that seems to interfere with the second handshake.
However, the client's second connection is from a different source port, with which the server has no prior association. Application data from a one source should not interfere with a handshake from another.
Activity
Sean-Der commentedon Jun 1, 2024
Sorry I didn't respond to this sooner @gordonklaus. I am working on releasing the next major of pion/dtls so cleaning these up now.
I think you have to detect this on the client side. If the server doesn't send you a packet or ACK for N seconds you consider the connection dead.
If the new server could modify/notify the client that would be an attack vector. That would me anyone could MITM and modify your session. Maybe you could export the
Stateevery couple seconds in case you have a crash?Happy to discuss it further/come up with helpful ideas :)
gordonklaus commentedon Jun 1, 2024
Better late than never, I suppose :) Although I have long since moved on from this project.
I think, from reading my description (and a vague recollection), that I already did just as you suggested: detect on the client side and try to reconnect. The issue was that the reconnection attempt was ignored by the server.
I would suspect rather that an attack vector already exists, if the server can be made to ignore client connection attempts. Not as bad as a MITM but more of a DOS.