Простой обмен ключами, один сервер

Я пытаюсь лучше понять, как работает TLS. Я понимаю, что в обычном случае использования вам нужны различные случайные значения, сгенерированные и используемые при обмене ключами, чтобы предотвратить повторное использование какой-либо MITM предыдущей передачи для подделки сервера или клиента.

Однако давайте предположим некоторый вырожденный случай, когда есть один сервер, единственный открытый ключ которого уже известен его клиентам, а также различным злоумышленникам. В этом случае, я думаю, все, что, строго говоря, необходимо для выполнения безопасного обмена ключами, будет следующим:

1. Клиент использует открытый ключ RSA сервера для шифрования случайного симметричного сеансового ключа.
2. Клиент отправляет серверу зашифрованный сеансовый ключ
3. Сервер расшифровывает ключ сеанса, используя закрытый ключ RSA сервера.
4. Сервер использует сеансовый ключ для шифрования «готового» сообщения.
5. Сервер отправляет клиенту зашифрованное «завершенное» сообщение
6. Клиент использует сеансовый ключ для расшифровки «готового» сообщения.
7. Клиент подтверждает, что сообщение «закончено», рукопожатие завершено

Таким образом, в этом упрощенном процессе единственным значением, изменяющимся в каждом сеансе, является сам ключ сеанса, поэтому случайный выбор предыдущего клиента или сервера не используется; и нет премастерного секрета, опять же только сеансовый ключ.

Это похоже на резкое упрощение вещей, но мне трудно понять, что я упускаю. Если основная цель обмена ключами состоит в том, чтобы убедиться, что сервер является единственным, кто получает ключ сеанса, это кажется безопасным. Доказательство от противного, снова отслеживая описанный выше процесс, но с точки зрения противника:

1. У злоумышленника уже есть открытый ключ сервера, и он может зашифровать свой собственный симметричный сеансовый ключ для целей MITM.
2. Злоумышленник может видеть зашифрованный сеансовый ключ от клиента, но не может его расшифровать; может отправить серверу свой собственный зашифрованный сеансовый ключ MITM
3. Сервер расшифровывает сеансовый ключ MITM, не зная о его происхождении
4. Сервер использует сеансовый ключ MITM для шифрования "готово"
5. Сервер отправляет клиенту (фактически противнику) зашифрованное "готовое"
6. Злоумышленник может расшифровать «готово», но не может повторно зашифровать и отправить клиенту с сеансовым ключом клиента, который злоумышленник не может расшифровать.
7. В конечном итоге клиент никогда не получит правильно зашифрованное «готовое» ни от сервера, ни от злоумышленника.

Таким образом, кажется, что единственная потенциальная слабость здесь заключается в том, что сервер не может узнать, общается ли он с законным клиентом или противником, но, насколько я понимаю, аутентификация клиента никогда не рассматривалась с самого начала. Аутентификация сервера есть, но в данном случае это не проблема, так как есть только один сервер.

Итак, правильно ли я понимаю, что если бы кто-то использовал эту схему, противник не смог бы выполнить атаку MITM? Или как это победить?

Одна очевидная проблема с вашим «вырожденным случаем TLS» заключается в том, что при развертывании TLS нельзя предполагать, что клиент заранее знает открытый ключ сервера; который нужно как-то передать (и аутентифицировать).

Тем не менее, ваш вопрос был:

Или как это победить?

Ну, одна очевидная проблема заключается в том, что он довольно уязвим для атак воспроизведения на стороне клиента. Предположим, действительный клиент выполняет согласование с действительным сервером, а затем продолжает отправлять некоторые команды. Злоумышленник может записать то, что отправил клиент, а затем снова отправить эти сообщения. Сервер будет выполнять точно такие же операции, генерировать такие же симметричные ключи, а затем обрабатывать те же зашифрованные команды. Насколько плохо это было бы, зависело бы от того, что это были за команды - если бы это было требование загрузить веб-страницу, а не проблема - если бы это была команда для выполнения банковской транзакции, ну, это, вероятно, было бы проблемой.

Другая проблема (с точки зрения современного TLS) заключается в том, что ему не хватает совершенной секретности пересылки — если кому-то удастся украсть закрытый ключ сервера, он не только сможет маскироваться под сервер (что неизбежно; если вы узнаете все, что известно серверу, вы можете делать все, что может действительный сервер), они могут вернуться и расшифровать предыдущие сеансы. Последние версии TLS (в частности, TLS 1.3) не позволяют злоумышленнику сделать это.