If I understand the blog post and this diagram correctly the new connection handshake is an improvement but might still be attacked. Consider the following attack workflow:Blubberbub wrote:
- the attacker sends a connection request with a (random) client ID and a spoofed IP address
- the server replies to the spoofed IP with the client ID and the server ID
- the attacker intercepts the reply (ant therefore now knows the server ID)
- the attacker sends the server a "connection reply confirm" with the client and server IDs
- the server sends the client a "connection accept"
- heartbeats are now sent to the attacked client
The cornerstone of this attack is of course the ability of the attacker to intercept replies from the server to the client. This is easy on a LAN. In the end this might not be a concern on a WAN as it seems to me considerably more difficult to intercept packages. But even if it's difficult it might be possible and could be taken into account (even if it's not a priority) on how this handshake it designed. If this is indeed a problem, my take on it would probably be to encrypt the handshake.
On a different note,
Is more info available about what the peer-to-peer was being used for? Why is it being removed? Centralising seems to be going a step back, but I can't have a sound opinion since I don't know what the P2P was used for.As the peer-to-peer network model is being removed