wkrp
commented
4 months ago Replay attack is a general concept. The effect of a replay depends on the details of the protocol used. For some protocols it matters, for some it doesn't.
Generally, replay attacks are used when the attacker is missing some piece of information that a genuine user has. For example, a genuine user may know a password that allows them to produce authenticated ciphertexts. If the attacker doesn't know the password, the only way it can get an authenticated ciphertext is to observe one that is produced by a genuine user. Attackers might also try replaying observed traffic with a few bytes changed, in order to see how the server reacts to error conditions.
Here are a few examples of replay attacks against circumvention systems and their effects:
https://groups.google.com/g/traffic-obf/c/CWO0peBJLGc/m/Py-clLSTBwAJ
The censor can record a legitimate Shadowsocks session, then replay the client→server packets. When replaying, the censor tweaks the byte corresponding to the most significant byte of DATA.LEN, which will tend to make the decrypted DATA.LEN large, which will cause the server to continue trying to read from the client, until timeout.
https://gfw.report/publications/imc20/en/
5.1 Intention Behind Replay-based Probes
The reaction of a server to type R1 identical replays depends on whether it has a replay defense mechanism or not. … Type R4 probes may be a chosen ciphertext attack, targeting Shadowsocks servers that use stream ciphers with a 16-byte IV. … when stream ciphers are used, the servers’ reactions to identical and byte-changed replays are inconsistent.
https://www.bamsoftware.com/papers/fep-flaws/#sec:shadowsocks (#24)
Not knowing the server's secret key, an attacker cannot produce ciphertexts of its own that will decrypt to anything meaningful. But what it can do is replay a past legitimate ciphertext. The full attack is to send the server a previously recorded encrypted Shadowsocks session, tweaking the first 7 bytes so that they decrypt to a specification of an address controlled by the attacker.
https://www.bamsoftware.com/papers/fep-flaws/#sec:vmess (https://github.com/v2ray/v2ray-core/issues/2523)
The idea of the active probing attack is to repeatedly replay an authentic client request, taking advantage of the lack of integrity in the command block to modify the field P that indicates how much padding there is. Record a legitimate encrypted command block, and set the 4 ciphertext bits that correspond to the P field to 0000. Send the modified command block to the suspected VMess server, but stop just before the variable-length fields. Then resume sending, one byte at a time (the values are not important), with a delay after each byte, until the server closes the connection. The hash verification will almost certainly eventually fail, because of the changes to the ciphertext, but a vulnerable VMess server will not disconnect until it has read the full N bytes of address, P bytes of padding, and 4 bytes of hash.
I am wondering why they do that? what it the reasons? They want to detect? decrypt? corrupt the connection? What they can do if the protocol we use have no defense against that