Channel init Replay Angriff

[mchlnix]

New channels init messages are recognized by their channel id being new to the Mix. Afterwards the message is processed without further checks.

Since the channel id is sent over the line in plain text an attacker can copy the initialization message and change the channel id, creating a channel with the same secrets as that of the victim.

The attacker doesn't know the actual secrets, that the victim generated, but could mirror the messages the victim is sending and may get access to resources or information only the victim would've known about.

Additionally, more than one message with the same appearance would make tracking the victim easier, since the replay detection only works within a channel.

[mchlnix]

A fix for this situation would be to encrypt the used channel id into the first asymmetrically encrypted block. So the first Mix can check if the channel ids match, preventing an attacker from replaying the message with a different channel id in the front.

That would only work for the first mix in the chain, though, since the client only chooses the channel id with the first mix, not the following.

That would be enough, if replaying messages only works or is only advantageous before the first Mix.

[mchlnix]

If an attacker copies messages and changes only their channel ID, after the first mix. then the Mix can't detect that. It doesn't compare CTR prefixes or sym keys between the channels, so it can only go by the channel id, which is (probably) new to it.

Therefore the Mix creates a Channel object, which generates an entry in its channel table and sends the channel init message along for the next Mix to do the same.

When the message reaches the ExitPoint only the Channel ID, destination address and Port are transferred, as of now. (The fact that this is done in plain text can be regarded, since the ExitPoint should probably be run on the last Mix, without any actual network traffic)

It is at this point, that the ExitPoint should be able to recognize, that two channels want to connect to the same IP:Port pair from the same IP:Port pair, which should be a red flag. At this point it cannot see this, however.

If we implemented this behavior, then the problem of who is the real client still stands, however, since it cannot be guaranteed, that the legitimate clients channel init message comes first, due to the nature of mixing and UDP.

If we discard both channels residing from this ip:port pair, then it is another way of potentially denying service. To a (random) client.

[mchlnix]

Since we now use link encryption with GCM the channel id is protected by encryption and integrity protected by the MAC of the GCM encryption.