Что мешает MIM отправлять зашифрованный API Token

Я пытаюсь понять, как использовать маркеры API для аутентификации запросов на сервер. Я понимаю общую концепцию, что токен отправляется с каждым запросом и сравнивается с токеном, хранящимся в каком-то сеансе, для аутентификации запроса. Я также понимаю, что токен никогда не должен отправляться "в диком виде", поэтому он обычно шифруется с использованием SSL.

Я не понимаю, как это останавливает человека в средних атаках. Рассмотрим следующую ситуацию.

Скажем, я зашел в систему и хочу изменить свою электронную почту. Когда я вхожу в ящик, для меня генерируется токен, скажем, токен = 1234. Так что скажем, я пришлю следующую команду https://example.com/[email protected]&token=1234

Для простоты предположим, что [email protected] = xyz (зашифровано SSL), [email protected] = abc (зашифровано SSL) и 1234 = 4321 (зашифровано SSL).

Таким образом, MIM получает что-то вроде https://example.com/updateEmail?email=xyz&token=4321.

Что мешает MIM получить это и изменить его на https://example.com/updateEmail?email=abc&token=4321? Разве сервер не расшифровал бы с 4321 по 1234 год, скажем, что он соответствует и обновляет письмо по адресу [email protected]?

Примечание. Я не передаю идентификатор пользователя, потому что это хранилище в переменной сеанса на сервере.