Я часто советовал людям использовать SSH-туннель для обеспечения безопасности их просмотра в открытых WIFI или в других небезопасных ситуациях.
Недавно мой друг спросил, насколько безопасен туннель SSH после того, как я предложил туннелирование SSH. Я немного споткнулся и повторил "безопасно".
Несмотря на то, что он был удовлетворен этим ответом, он немного раздражал меня, что я не мог ответить полностью.
Итак, вопрос к вам, ребята:
«Насколько безопасен туннель SSH?"
Я просто хотел бы процитировать немного из Википедии здесь:
Даже если симметричный шифр в настоящее время не может быть взломан за счет использования структурных недостатков в его алгоритме, можно пройти через все пространство ключей в так называемой атаке методом грубой силы. Поскольку более длинные симметричные ключи требуют экспоненциально больше работы для поиска методом грубой силы, достаточно длинный симметричный ключ делает эту линию атаки непрактичной.
С ключом длиной n битов есть 2 n возможных ключей. Это число растет очень быстро с ростом n. Закон Мура предполагает, что вычислительная мощность удваивается примерно каждые 18–24 месяца, но даже этот эффект удвоения оставляет большие длины симметричных ключей, которые в настоящее время считаются приемлемо, недосягаемыми. Считается, что большое количество операций (2 128), необходимых для проверки всех возможных 128-битных ключей, недостижимо для традиционных методов цифровых вычислений в обозримом будущем. Однако ожидаются альтернативные формы вычислительной техники, которые могут иметь более высокую вычислительную мощность, чем классические компьютеры. Если квантовый компьютер подходящего размера, способный к надежному выполнению алгоритма Гровера, станет доступным, он уменьшит 128-битный ключ до 64-битной защиты, примерно эквивалентно DES. Это одна из причин, почему AES поддерживает 256-битную длину ключа. См. Обсуждение взаимосвязи между длиной ключа и атаками на квантовые вычисления в нижней части этой страницы для получения дополнительной информации.
Таким образом, 128-битный ключ будет иметь 340 282 366 920 938 463 463 374 607 431 768 211 456 возможных перестановок. Представь, что ты проходишь через все это. Даже мощный настольный компьютер может попробовать только несколько в секунду.
Таким образом, хотя теоретически возможно дешифрование потока SSH методом «грубой силы», к тому времени, когда ключ будет расшифрован самым мощным компьютером, который можно себе представить, произойдет две вещи:
<отказ от ответственности: не эксперт по криптографии>
SSHv2 использует в основном те же алгоритмы, что и TLS/SSL:
Все они широко используются и доказали свою безопасность для повседневного использования.
Однако в любом протоколе безопасность зависит от знания того, что вы общаетесь с нужным сервером. В случае SSH (стандартная конфигурация) при первом подключении к серверу необходимо проверить его отпечаток. (Не просто подтвердите это без фактической проверки, как это делают многие люди.) В следующий раз ключ сервера будет проверен на соответствие кэшированной копии, чтобы предотвратить атаки типа «человек посередине», но только в том случае, если правильный ключ был кеширован в первую очередь.
(Для сравнения, TLS/SSL обрабатывает вышеупомянутое, используя сертификаты X.509, выпущенные известными властями, которым доверяют не подписывать поддельные сертификаты.)
Настоящая проблема безопасности SSH - сертификаты. Многие компании выдают защищенные ключи для соединений SSH, и базы данных, содержащие эти ключи, не впервые взламываются. Поэтому лучшее решение для обеспечения безопасности - это создать собственную пару ключей, но это хлопотно, и именно поэтому мы полагаемся на эти компании ... Пока они не взломаны, и нам не нужно проверять 340 282 366 920 938 463 463 374 607 431 768 211 456 ключей, а только элементы в базе данных.
