Как я могу аутентифицировать клиентское соединение безопасным способом?

Question

Допустим, у меня есть сервер, прослушивающий порт 1234. У меня есть клиентское программное обеспечение, которое должно быть в состоянии подключиться к этому порту.Но я хочу, чтобы злоумышленники не могли обойти клиентское программное обеспечение и подключиться к порту другими способами (например, с помощью консоли или другого программного обеспечения).

Доверенное клиентское программное обеспечение и сервер могут совместно использовать секретный ключ, если это необходимо.Я бы предпочел не отправлять такой ключ в виде открытого текста, но данные после аутентификации могут быть в виде открытого текста.В частности, я пытаюсь выяснить, как победить атаку «человек посередине», когда злонамеренный пользователь использует программное обеспечение доверенного клиента для вычисления правильных ответов на вызовы сервера.

Можно ли получить отздесь?

Я мог бы привязать порт прослушивания сервера только к localhost и потребовать, чтобы клиенты сначала получили доступ к машине через ssh.Затем клиентское программное обеспечение может использовать библиотеку ssh для запуска команды на сервере, который подключается к локальному порту (в этом случае злоумышленник не сможет использовать ssh для доступа к компьютеру, поскольку у него не будет пароля).Но тогда весь мой трафик зашифрован, что является дополнительным расходом.Возможно, есть программа, похожая на ssh, которая только выполняет аутентификацию, но затем оставляет канал в незашифрованном виде?

Обновление:

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

spew.rb выводит 10 миллионов строк по 100 символов.

CONTROL:

fantius@machine> time /home/fantius/spew.rb > /dev/null

real    0m35.015s
user    0m34.934s
sys     0m0.084s

top показывает 25% использования процессора (одно полное ядро ​​из четырех ядер)

TEST:

fantius@machine> time ssh localhost /home/fantius/spew.rb > /dev/null

real    0m40.704s
user    0m19.981s
sys     0m1.400s

top показывает 45% использования процессора (почти два полных ядра)

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

Answer 1

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

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

Что касается человека посередине, вы можете сделать очень мало. У банков уже достаточно проблем, как и в случае с троянами, истощающими счета людей. Если кто-то посередине, он может делать почти все, что хочет. При достаточном мониторинге они могут копировать весь ваш протокол связи и копировать ваше приложение.