Remove references to WhoTheFAreU? from replay server/client code

[nkinkade]

This message show up a few times in the code:

• https://github.com/NEU-SNS/wehe-py3/blob/master/src/replay_server.py#L390
• https://github.com/NEU-SNS/wehe-py3/blob/master/src/replay_server.py#L393
• https://github.com/NEU-SNS/wehe-py3/blob/master/src/replay_client.py#L240

The message was probably meant to be amusing or funny when it was added a long time ago, and surely almost nobody will ever encounter it. However, recently an M-Lab site host actually shut down and entire M-Lab site because they thought that the servers were compromised and had been defaced. It would probably be better to change that message to something slightly more benign, possibly with a link to a page about what Wehe is.

[zeinabshmeis]

I have changed this message to SuspiciousClientIP! in the branch remove-ambiguous-references. The following change requires changing the client side as well.

@nkinkade do you have an idea how we can reproduce this event? Do we have logs or something that shows what triggered this event?

[drchoffnes]

I believe it's when you establish a TCP connection on an unexpected port and/or send unexpected data on that port---all without have a sidechannel estblished.

[zeinabshmeis]

Okey, I have been trying to test this, but I seem to keep failing to re-create such incident.

Things I tried:

• modify source IP of incoming packets so that the replay packets have different IP from the side channel packets. Results is that the socket closes and replay is not performed.
• modify the replayTrace file so that the payload size and/or content is different. For the size, the socket just closes because of TO for not receiving anything. For the content, the replay continues successfully.

I guess we can for now just change the message to "SuspiciousClientIP!" and be optimistic that nothing break. In worst case scenario I would expect the replay to simply just fail without affecting the server.

Changes are in the attached branch, and ready to be merged.

[drchoffnes]

I’m ok with that!

…

On Mon, May 8, 2023 at 3:24 PM zeinab shmeis ***@***.***> wrote: Okey, I have been trying to test this, but I seem to keep failing to re-create such incident. Things I tried: - modify source IP of incoming packets so that the replay packets have different IP from the side channel packets. Results is that the socket closes and replay is not performed. - modify the replayTrace file so that the payload size and/or content is different. For the size, the socket just closes because of TO for not receiving anything. For the content, the replay continues successfully. I guess we can for now just change the message to "SuspiciousClientIP!" and be optimistic that nothing break. In worst case scenario I would expect the replay to simply just fail without affecting the server. — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACOPSOZRM7HR5JBTQP6VQTXFFB6BANCNFSM6AAAAAAWFUOF5E> . You are receiving this because you commented.Message ID: ***@***.***>