TCPShield Plugin 2.5 not supported

[haveachin]

Describe the bug TCPShield Plugin throws an exception when a client joins from a remote network.

To Reproduce Spin up an Infrared proxy with "realIp": true and proxy the traffic to a server running TCPShield Plugin 2.5. In the TCPShield Plugin config set debug-mode: true and add 127.0.0.1/32 at the bottom of the tcpshield-ips.list file. Connect through Infrared to the server from a remote network (the client joining the server must have a valid public IP address). This is important due to how the TCPShield Plugin handles local connection.

You should now be able to see this in the server log:

[TCPShield] Debug : unknown[unknown/null] was disconnected because no proxy info was received and only-allow-proxy-connections is enabled. Raw payload = "example.com///123.4.567.89:12345///1621048346"

Expected behavior Client should be able to connect to the server and his "real" IP should be passed through.

Additional context (Optional) TCPShield Plugin 2.5 code that causes the exception: https://github.com/TCPShield/RealIP/blob/master/src/main/java/net/tcpshield/tcpshield/TCPShieldPacketHandler.java#L106

[haveachin]

There is no easy fix for this. TCPShield is now using a signature to validate to authenticity of the payloads. This hardens their security and makes Minecraft server using the plugin now immune to IP spoofing.

Proposal Infrared should generate it's own an ECDSA private key and sign RealIP payloads. This will require the TCPShield Plugin to use the public key that was generated by Infrared instead of the TCPShield one. The public key replacement should be possible by a command line tool that is integrated in Infrared. This will couple the plugin to a specific Infrared instance and thus the underlying private key respectively, securing the payload like TCPShield intended it.

[xPlumpOrange]

Hi, I am a contributor to TCPShield, I happened to do their 2.5 release. With my own digging to find the root cause, I found that infrared cuts off the last section of the handshake payload; the format that is used is as follows HOSTNAME///REAL_IP///TIMESTAMP///SIGNATURE. This format has been used for several iterations of TCPShield now, even before 2.4. It seems, somehow, the last section is removed during the handshake packet process. The reason this never affected 2.4 was because 2.4 only used 2 arguments, instead of all 4, so this issue has gone un-noticed. A proposed solution is to either find out why the last payload section is cut off, or sign it yourself, then TCPShield users can override the public key inside the jar with a simple ZIP program/command line interface, or build it themselves.

[haveachin]

@xPlumpOrange I hope https://github.com/TCPShield/RealIP/issues/50#issuecomment-846100949 clears things up a bit. Infrared does not manipulate either forwards the payload without modification or creates its own. https://github.com/haveachin/infrared/blob/3cbaca23ebb9b2ca3247e2c9787d1b94b3a952d8/protocol/handshaking/serverbound_handshake.go#L84-L99

[xPlumpOrange]

@xPlumpOrange I hope https://github.com/TCPShield/RealIP/issues/50#issuecomment-846100949 clears things up a bit. Infrared does not manipulate either forwards the payload without modification or creates its own.

https://github.com/haveachin/infrared/blob/3cbaca23ebb9b2ca3247e2c9787d1b94b3a952d8/protocol/handshaking/serverbound_handshake.go#L84-L99

Thanks for clearing that up, I was left without the knowledge that Infrared had its own IP payload, so for this case, the solution would be to create private and public keys for this process and it should fix using this feature with TCPShield.