Add timestamp validation and deduplication to hello handshake messages

[zeusoo001]

Summary

When TRON nodes process handshake (Hello) messages, although the messages include a timestamp signature, the receiver currently does not validate the timestamp, nor is there a mechanism for message uniqueness or deduplication. Historical messages could be intercepted and reused to establish connections. Adding timestamp validation and a simple deduplication mechanism can more effectively filter out expired or repeated messages, improving handshake stability and node connection reliability.

Root Cause

Hello messages include a timestamp signature, but the receiver does not validate its freshness, and there is no unique identifier or deduplication. Historical messages could be intercepted and replayed to establish connections, which slightly affects node connection stability.

Reproduction

• Construct a Hello message containing a historical timestamp or previously sent content.
• Send this message from different peers to the target node.
• The target node processes each Hello message from each peer normally, without verifying timestamp validity or message uniqueness.

Impact

• A malicious node that intercepts and replays historical messages could successfully establish connections with the target node.
• This may cause unnecessary connection attempts and additional resource consumption on the target node.

Suggested Fix

Add lightweight validation in the existing handshake process:

• Implement timestamp validation to ensure it falls within a reasonable time window (e.g., 30s).
• Introduce a simple unique identifier (e.g., based on timestamp) and perform short-term deduplication using a cache.

By using the above methods, handshake message processing can be more standardized and stable without affecting the existing signature mechanism.

[lxcmyf]

Looked through the current handshake path and this issue is directionally correct, with one nuance:

HandshakeService.processHelloMessage(...) already rejects a second hello on the same PeerConnection (peer.getHelloMessageReceive() != null), so there is a per-connection duplicate guard today. But there is still no freshness check for msg.getTimestamp() in either HandshakeService or HelloMessage.valid(), which means an old hello can still be replayed on a new connection.

Another detail from the current implementation: in RelayService.checkHelloMessage(...), the signature check is effectively over ByteArray.fromLong(msg.getTimestamp()). So if an attacker reuses the same signed hello payload, the signature remains valid as long as the node only checks signature/address and never checks timestamp freshness.

A couple of implementation notes that may help:

• adding a bounded timestamp window in the handshake path is the lowest-risk improvement
• if dedup is added, keying only by timestamp is probably too weak because different peers can legitimately share the same timestamp
• a better short-term cache key would be something like (address or nodeId, timestamp, signature) with a small TTL
• if the goal is stronger replay resistance rather than just rate reduction, a dedicated nonce/session challenge would be more robust, but that is a larger protocol change than a timestamp-window check

So I think the minimal practical fix is: keep the existing per-connection duplicate rejection, add timestamp freshness validation for all hello messages, and only add cache-based dedup if it is keyed on more than timestamp alone.

[lvs0075]

The timestamp signature in the current handshake flow is only enforced on the sender side — the receiver never validates freshness, which effectively makes the signature protection meaningless. An attacker only needs to record one legitimate Hello message and can replay it at any point in the future.

For the fix, I'd suggest a two-layer approach:

Layer 1: Time window validation
Add a timestamp check at the HelloMessage handler entry point (NodeImpl or ChannelManager) and reject messages whose timestamp deviates from local time beyond a reasonable threshold (e.g., ±30s). One
thing to be careful about: clock synchronization quality varies across TRON nodes, so the threshold shouldn't be set too aggressively to avoid false rejections of legitimate peers.

Layer 2: Short-term deduplication
Maintain a local cache (e.g., Guava Cache or a bounded ConcurrentLinkedHashMap) keyed on (nodeId + timestamp) or the message signature, with a TTL matching the time window. Reject duplicate messages within the window. The cache should have an explicit size cap to prevent memory exhaustion from a flood of forged messages.

These two layers together effectively block replay attacks without touching the existing signature verification logic.

[xxo1shine]

@lxcmyf Thanks for the detailed analysis — the overall direction is accurate.

One note on the dedup cache key: using timestamp alone is sufficient in practice. The same connection will never reuse the same timestamp, and the probability of two different connections colliding on exactly the same timestamp is negligibly low. Introducing a nonce field adds protocol complexity with little real benefit.

So the minimal fix looks right:

• Add timestamp freshness validation in the handshake path (e.g., a ±30s window) to reject stale messages
• Keep the existing per-connection duplicate guard
• Add a short-TTL cache keyed by timestamp to handle cross-connection replay

These three together cover the main replay risk without requiring any protocol-level changes.

[xxo1shine]

@lvs0075 Agreed on the two-layer approach. One suggestion on the cache design:

Use the address recovered from the signature as the cache key, and store the timestamp from the most recent handshake. On each incoming Hello message, verify that the timestamp is strictly greater than the cached value — reject if not. This replaces TTL-based expiry with a monotonically increasing constraint, which is simpler and removes the need to cap cache size.

On the time window, ±30s may be too tight. Given the wide geographic distribution of TRON nodes and varying clock synchronization quality, a larger window like ±15 minutes is more appropriate to avoid false rejections of legitimate peers.