Наскільки безпечним є тунель або з'єднання SSH?

Я часто радив людям використовувати тунель SSH, щоб забезпечити їх перегляд на відкритих WIFI або в інших небезпечних ситуаціях.
Нещодавно друг мене запитав, наскільки безпечний тунель SSH після того, як я запропонував тунелювання SSH. Я трохи спотикався і повторив "його безпечний".

Незважаючи на те, що він був задоволений цією відповіддю, він трохи засмутив мене, що я не зміг повністю відповісти.
Отож, запитання виходить перед вами:

"Наскільки безпечний тунель SSH?"

Я хотів би трохи процитувати тут Вікіпедію:

Навіть якщо симетричний шифр в даний час нерозривний, використовуючи структурні слабкі місця в його алгоритмі, можна пробігти весь простір клавіш у тому, що називається грубою силою атаки. Оскільки довші симетричні ключі потребують експоненціально більшої роботи для грубого пошуку сили, досить довгий симетричний ключ робить цю лінію атаки непрактичною.

З ключем довжиною n біт існує 2 ⁿ можливих клавіш. Ця кількість зростає дуже швидко зі збільшенням n. Закон Мура передбачає, що обчислювальна потужність збільшується приблизно кожні 18 - 24 місяці, але навіть цей подвоєний ефект залишає більші симетричні довжини ключів, які в даний час вважаються прийнятними, недоступними. Велика кількість операцій (2 ¹²⁸) Потрібно спробувати всі можливі 128-бітні клавіші, як вважається, недоступними для звичайних цифрових обчислювальних прийомів в осяжному майбутньому. Однак передбачаються альтернативні форми обчислювальної техніки, які можуть мати вищу обробну потужність, ніж класичні комп'ютери. Якщо квантовий комп'ютер відповідного розміру, здатний надійно запустити алгоритм Гровера, стане доступним, це дозволило б скоротити 128-бітний ключ до 64-бітової безпеки, приблизно в еквіваленті DES. Це одна з причин, чому AES підтримує 256-бітну довжину ключа. Для отримання додаткової інформації дивіться дискусію про залежність між ключовими довжинами та квантовими обчисленнями внизу цієї сторінки.

Таким чином, 128-бітний ключ матиме 340,282,366,920,938,463,463,374,607,431,768,211,456 можливих перестановок. Уявіть, що переживаєте все це. Навіть потужний настільний комп'ютер може спробувати лише кілька за секунду.

Тож хоча теоретично можливо розшифрувати потік SSH з грубою силою, до моменту, коли ключ буде розшифрований найпотужнішим комп’ютером, можна уявити дві речі:

1. Ключ був би змінений SSH
2. Всі ми загинули б, а сонце вибухнуло і знищило землю.

^{<відмова від відповідальності: не фахівець з криптографії>}

SSHv2 використовує в основному ті ж алгоритми, що і TLS / SSL:

• DH , нещодавно ECDH або RSA для обміну ключами;
• RSA , DSA або ECDSA для автентифікації сервера (і дуже часто, аутентифікації клієнта).
• AES для симетричного шифрування (весь потік даних шифрується за допомогою довільно генерованого ключа).

Усі вони широко використовуються та перевірені безпечно для щоденного використання.

Однак у будь-якому протоколі безпека залежить від того, що ви знаєте, що ви спілкуєтесь із правильним сервером. У випадку SSH (стандартна конфігурація), при першому підключенні до сервера ви повинні перевірити його відбиток пальців . (Не просто підтверджуйте це, не перевіряючи насправді, як це роблять багато людей.) Наступного разу ключ сервера буде перевірятися на кешовану копію, щоб запобігти атакам "людина-в-середині" - але тільки в тому випадку, якщо праву клавішу було кешовано на першому місці.

(Для порівняння, TLS / SSL обробляє вищевикладене за допомогою сертифікатів X.509, виданих відомими органами влади, яким довіряють не підписувати фальшиві сертифікати.)

Справжня проблема безпеки SSH - це сертифікати. Дуже багато компаній видадуть захищені ключі для SSH-з'єднань, і це не перший раз, коли бази даних, що містять ці ключі, отримують злом. Тож найкращим рішенням для забезпечення безпеки є створення власної пари ключів, але це клопот, і це те, на що ми покладаємось на ці компанії ... Поки вони не будуть зламані, а ми не зробимо; не потрібно перевіряти 340,282,366,920,938,463,463,374,607,431,768,211,456 ключів, але тільки onces у базі даних ..