MITM attack #2

New issue

Open

opened 2025-12-11 12:49:40 +01:00 by hloth · 0 comments

hloth commented

2025-12-11 12:49:40 +01:00

Owner

Consider encrypting authorization token payload to mitigate man-in-the-middle attack.

Currently

Initial communication

Client -> Server: /login [password]
Server -> Client: Use this authorization token in future: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Later

Server -> Client: Requesting authorization token for UUID 00000000-0000-0000-0000-000000000000
Client -> MITM -> Server: Authorization token is ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

MITM intercepted the authorization token and can now impersonate Client

Proposal

Add public/private key encryption with local cache

Initial communication

Server -> Client: My public key is aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Client: Caches public key locally for the first time
Client -> Server: [Encrypted payload using server's public key: My public key is eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee]
Client -> Server /login [password]
Server -> MITM -> Client: [Encrypted payload using client's public key: Use this authorization token in future: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff]

Result: MITM intercepted encrypted payload from server to client that cannot be decrypted without client's private key

Later

Server -> Client: My public key is aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Client: public key matches local cache, all good
Server -> Client: Requesting authorization token for UUID 00000000-0000-0000-0000-000000000000. [Signature of the message using public key]
Client: Checks signature using public key
Client -> MITM -> Server: [Encrypted payload using server's public key: Authorization token is ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff]

Result: MITM intercepted encrypted payload that cannot be decrypted without server's private key

MITM attack

Server -> MITM -> Client: My public key is ~~aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa~~ [MITM replaces it with their own key: bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb]
Client: The key does not match cached key. Aborting all communications.

Problems

In the proposal the only vulnerable place is the initial key exchange. MITM can intercept the first server's message and replace the public key with their own.

The solution would be to either somehow tie server's address to public key for client's local verification or to provide fingerprint.

To clear public key cache user can authorize with /login command again — the mod then trusts the new public key.

Consider encrypting authorization token payload to mitigate man-in-the-middle attack. ## Currently ### Initial communication Client -> Server: `/login [password]` Server -> Client: Use this authorization token in future: `ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff` ### Later Server -> Client: Requesting authorization token for UUID `00000000-0000-0000-0000-000000000000` Client -> MITM -> Server: Authorization token is `ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff` MITM intercepted the authorization token and can now impersonate Client ## Proposal Add public/private key encryption with local cache ### Initial communication Server -> Client: My public key is `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa` Client: Caches public key locally for the first time Client -> Server: [*Encrypted payload using server's public key:* My public key is `eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee`] Client -> Server `/login [password]` Server -> MITM -> Client: [*Encrypted payload using client's public key:* Use this authorization token in future: `ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff`] Result: MITM intercepted encrypted payload from server to client that cannot be decrypted without client's private key ### Later Server -> Client: My public key is `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa` Client: public key matches local cache, all good Server -> Client: Requesting authorization token for UUID `00000000-0000-0000-0000-000000000000`. [Signature of the message using public key] Client: Checks signature using public key Client -> MITM -> Server: [*Encrypted payload using server's public key:* Authorization token is `ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff`] Result: MITM intercepted encrypted payload that cannot be decrypted without server's private key ### MITM attack Server -> MITM -> Client: My public key is ~`aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa`~ [*MITM replaces it with their own key:* `bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb`] Client: The key does not match cached key. Aborting all communications. ## Problems In the proposal the only vulnerable place is the initial key exchange. MITM can intercept the first server's message and replace the public key with their own. The solution would be to either somehow tie server's address to public key for client's local verification or to provide fingerprint. To clear public key cache user can authorize with /login command again — the mod then trusts the new public key.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: demovio/easy-auth-local-sessions#2

No description provided.

Rows
Columns