RPC and security (MitM)

нетривиальный пароль ?

нетривиальный пароль ?

Да, как вариант. Тоже думал над тем, как держать баланс между длиной ключа и скоростью. Тут больше человеческий фактор.

нетривиальный пароль ?

Никакой пароль не поможет - хоть простой, хоть нетривиальный! MitM перехватит и повторит любой пароль! Тут только шифрование всего обмена поможет.

Работой поверх HTTPS, очевидно.

Работой поверх HTTPS, очевидно.

А в локальной сети как поможет HTTPS?

Тут только шифрование всего обмена поможет.

Да, так и есть. Имеется в виду, либо симметричное шифрование со сложным паролем. Но тогда будет проблема перехвата пароля («проблема посыльного» в военном деле). Либо, асимметричное шифрование, но закрытый ключ тоже надо передавать. В этом, собственно, и вся проблема с паролями.

Либо, асимметричное шифрование, но закрытый ключ тоже надо передавать.

Кагбэ весь смысл асимметрической криптографии в том, что закрытый ключ никуда не передаётся.

Но MitM подразумевает, что кроме возможности восстановления оригинального сообщения есть ещё возможность подделки сообщения. Вот этого и хотелось бы избежать. Ведь открытый-то ключ для «фейковых» блоков данных можно перехватить. Разумеется, если не погружаемся в декомпиляцию самого протокола/формата обмена.

Поэтому сообщения шифруются публичным ключём адресата *и* подписываются приватным ключём отправителя, а получатель проверяет подпись с помощью публичного ключа отправителя.

Тут только шифрование всего обмена поможет.

Я читал когда-то рекомендации ФСТЭК для таких систем и ГОСТы.

Напрашивается разделение на уровни доступа (роли) и ручной контроль за нетипичной активностью. Вроде, в моем случае это должно помочь.

либо симметричное шифрование со сложным паролем

Всё уже придумано - dh для выработки общего секрета и остаётся только придумать механизм его согласования, чтобы исключить митм.

*и* подписываются приватным ключём отправителя

Теперь понятно. Пока не начал по шагам смотреть RSA, в теории не мог понять. Спасибо.

и остаётся только придумать механизм его согласования

Который, следует заметить, тоже придуман, причем далеко не один.

причем далеко не один.

Окей. Принцип я понял. Задача Core Wars - увлекательная, но очень уж головоломная.

Как обеспечивается защита от MitM для RPC-протоколов?

Кмк, вопрос не правильный. Потому что, правильный вопрос - как произвести аутентификацию вызывающей стороны и протокол тут уже вроде как и не причём.

аутентификацию вызывающей стороны

Канал связи считаем незащищённым. То есть, условный Wi-Fi. Вопрос сводится к шифрованию открытого протокола. Считаем, что протокол тоже не закрыт.

А локальная сеть чем-то отличается от глобальной? В локальной вдруг не работает HTTPS?

Кмк, вопрос не правильный.

Как-то в 1990-е годы глянул на центральную теорему эллиптической криптографии (требовалось доказать её неразрешимость), и понял, что мне в этой сфере математики делать нечего. Даже не понял, как подступиться к этой теореме.

В локальной вдруг не работает HTTPS?

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