Skip to content

Conversation

@TheBlueMatt
Copy link
Owner

This closes #6, ensuring no future MiTM-based downgrade attacks can
occur. Note that obviously this doesn't do anything for TOFU
clients as any MiTM attacker can also replace the pubkey, but it
does protect either connection-reset-based MiTM attackers as the
pubkey must not change and also any clients which specify the
expected public key.

This closes #6, ensuring no future MiTM-based downgrade attacks can
occur. Note that obviously this doesn't do anything for TOFU
clients as any MiTM attacker can also replace the pubkey, but it
does protect either connection-reset-based MiTM attackers as the
pubkey must not change and also any clients which specify the
expected public key.
@jonasnick
Copy link

This does not solve downgrade attacks fully because the messages are replayable. The MiTM can store an old version message and replace a newer one with the old version preventing any protocol upgrade. You could add a timestamp to the messages and have implementations reject old timestamps.

@jonasnick
Copy link

Oh, I see now how putting the client field in the protocol_version message prevents replay attacks. However, that only works in one direction: If the server intends to bump the protocol version while the client min-version/max-version/flags stay the same then an old protocol_version message can be replayed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants