Назад | Перейти на главную страницу

SSH + RC4 Cipher: что именно подвергается риску?

У меня есть ситуация, когда медленная машина Windows должна периодически автоматизировать подключения к другой машине через SSH. Производительность SSH на этой медленной машине настолько низка, что это даже стало проблемой. Я уже предлагал заменить проблемную машину на более быструю, но меня сбили.

Я подумываю о том, чтобы попробовать arcfour -aka RC4 -cipher с SSH на медленной машине. Я читал, что это менее безопасно, но быстрее, чем AES или blowfish. Так что же именно подвергается риску? Насколько я понимаю, есть 3 вещи, которые SSH предлагает безопасность:

  1. Конфиденциальность данных, передаваемых через SSH
  2. Уверенность сервера в том, что клиент является тем, кем он / она себя называет. То есть действительное имя пользователя + пароль / комбинация клавиш SSH.
  3. Сообщение клиенту о том, что серверная машина является тем, кем он себя называет, через ключи в каталоге сервера / etc.

В моем конкретном случае мы можем жить с довольно низкой безопасностью для №1, №2 вызывает беспокойство, но не нарушает условия сделки. Для этой медленной машины также подходит №3. Но я обеспокоен тем, что № 3 каким-то образом повлияет на Другой клиентов.

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

P.S .: Функция совместного использования соединения SSH, вероятно, была бы лучшим ответом, но, к сожалению, она не поддерживается в Windows. Кроме того, использование шифра blowfish вместо AES дало некоторые улучшения, но все еще довольно плохо.

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

Это означает, что ваш выбор алгоритма симметричного шифрования не повлияет на проверку сервера (правильно или неправильно).

При этом я могу более или менее гарантировать вам, что изменение симметричного шифрования с AES на RC4 не приведет к заметному повышению производительности: даже с очень медленным (или истощенным) процессором разница в скорости между ними невелика. не будет заметно.

если вам нужна дополнительная информация, кто-то действительно выполнил подробный анализ если характеристики AES против RC4 (включая несколько режимов работы для AES)

Я не эксперт в этом, но (при условии, что проблема связана с шифрами) использование RC4 не помогает с аутентификацией сервера - RC4 используется в качестве алгоритма симметричного шифрования, а не в качестве фазы установки асимметричного соединения (где идентификатор IIRC определены). Может быть, метод на основе PSK был бы более подходящим методом, чтобы избежать проблем с производительностью из-за накладных расходов на вычисления?