Спільна група DH, свіжі секрети: чому атака дешевшає
Свіжі секрети сеансу не виправляють слабку групу над скінченним полем. Повторне використання однієї групи розподіляє найдорожчу стадію атаки на кожен обмін, що її узгоджує.
Параметри групи є публічними за задумом, і саме ця публічність робить їх легкими для ігнорування. У Diffie-Hellman над скінченним полем модуль і генератор спільні, а приватні показники й отримані ключі сеансу — ні. Дорога стадія атаки решетом по числовому полю залежить від групи, а не від одного обміну, тому одна слабка група, використана всюди, стає спільною відповідальністю. Називати параметри публічними точно й не по суті, бо повторно використовується вартість атаки саме на цю групу.
Публічна половина не є вразливою половиною, і в цьому пастка
Звичний половинчастий аргумент каже, що параметри опубліковані в стандарті, отже атакувальник їх уже знає, і приховування нічого не змінило б. Обидва твердження правильні, і жодне не випливає з іншого. Поставлена за замовчуванням група публічна, а приватна група, яку ви створили минулого тижня, теж видима кожному, хто завершує рукостискання. Таємність ніколи не була контролем; ним є сила й перевірка.
Змінюється те, скільки місць поділяють ту саму слабкість. Організація, що створює власну 2048-бітну групу, платить за свою атаку, а протокольне значення за замовчуванням, вибране мільйонами, амортизує одну вартість на всіх. У цьому сенсі незвична група не є автоматично кращою. Замала незвична група — це просто менший спільний секрет, за яким менше очей.
Перевірка важлива не менше за розмір. Партнер, який надсилає модуль із малими множниками або не тієї форми, якої очікує протокол, може розкрити інформацію про приватний показник навіть тоді, коли бітова довжина виглядає поважно. Бібліотеки, що відкидають спотворені параметри на вході, роблять справжню роботу, тому саморобний розбір параметрів — погане місце для економії зусиль.
Що попереднє обчислення насправді дає атакувальнику
У решета по числовому полю є стадія, що залежить лише від простого числа, і її результат можна повторно використовувати проти кожного обміну, який використовує це просте число. Це весь механізм історичного занепокоєння: дорога частина сплачується один раз, а гранична вартість кожного наступного сеансу падає. Свіжі показники все ще захищають кожен окремий обмін від пасивного спостерігача, доки група достатньо велика, щоб просіювання було неможливим. Обидва твердження сумісні, і більшість суперечок на цю тему походить із вибору одного й відкидання іншого.
Робота Logjam 2015 року продемонструвала зниження до 512-бітного Diffie-Hellman експортного рівня і оцінила, скільки коштуватиме атака на більші, широко повторно використовувані групи зі значними ресурсами. Демонстрація була конкретною, оцінки були оцінками, і жодне з них не було доказом того, що конкретний сеанс VPN було розшифровано.
Посилайтеся на роботу заради механізму й продемонстрованого зниження, а не як на вимірювання вашого розгортання. Стара статистика про те, скільки серверів поділяли групу за замовчуванням, описує інтернет того року, а не мережу, яку можна обстежити сьогодні. Корисне, що варто перенести, — це питання: чи узгоджують ваші пристрої досі групу, яка мала або слабо перевірена?
Стандартизований не означає слабкий
RFC 7919 визначає іменовані групи над скінченним полем, щоб обидві сторони домовлялися про групу за ідентифікатором і застосовували узгоджену політику. Стандартизованість — перевага, бо вона усуває неоднозначність переговорів і дозволяє реалізації відхиляти непідтримувані розміри. Іменована група слабка лише тоді, коли її розмір нижчий за політику, якої ви нібито дотримуєтесь, а не тому, що вона з'являється в документі. Та сама логіка стосується груп еліптичних кривих, які мають іншу структуру й інші режими відмови.
Тримайте конструкції окремо, коли міркуєте про них. Висновок про Diffie-Hellman над скінченним полем нічого не каже про X25519, а висновок про 1024-бітну групу MODP нічого не каже про 3072-бітну. Політика сили визначається за механізмом, за розміром і за версією протоколу, тому фраза стійка криптографія не є перевірюваним твердженням.
Автентифікація — це друга половина, і вона не замінює. Стійка група без перевірки партнера залишає атакувальника посередині, а чинний сертифікат не врятує 768-бітний обмін. Розглядайте їх як дві незалежні лінії, потім підтвердьте, що обидві справді узгоджуються.
Прочитайте узгоджену групу на реальному з'єднанні
Читайте узгоджену групу з пристрою, а не з шаблону конфігурації. Шаблони описують намір, а цікаве значення — те, про яке обидві сторони домовилися під час останнього рукостискання. На кінцевій точці IPsec вивід стану зазвичай друкує вибрану пропозицію, включно з групою MODP.
Зафіксуйте цей рядок до і після зміни політики та збережіть обидва в журналі змін. Порівняння і є доказом.
ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -nooutЯкщо після зміни стан усе ще показує стару групу, з'єднання не переузгодило параметри, і правка конфігурації нічого не довела. Перезапустіть партнера або очистіть асоціацію безпеки, потім знову прочитайте стан. Політика, застосована лише до нових з'єднань, залишить довгоживучі тунелі на старих параметрах, доки вони підняті.
Перевіряйте групу й особу партнера окремо
Відокремте те, що захищає група, від того, хто на іншому кінці. Записуйте метод обміну ключами, розмір групи й метод автентифікації як три поля, бо вони відмовляють незалежно. Тунель, що узгодив 3072-бітну групу, але приймає будь-який сертифікат, — не той самий ризик, що тунель, який закріплює партнера й використовує 2048-бітну групу.
Запишіть критерії прийняття до початку перевірки, щоб результат був порівнянням, а не думкою. Мінімальний розмір групи для кожної версії протоколу, список дозволених іменованих груп і обов'язкова перевірка партнера достатні, щоб зробити рішення механічним. Саме неоднозначність цього списку перетворює перевірку на суперечку, а суперечки не виправляються. Тоді вивід — список кінцевих точок, що порушують заявлене правило.
ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'Замкніть цикл, перечитавши узгоджені значення після виправлення. Відповідний файл конфігурації не є доказом того, що тунель його прийняв. Доказом є вивід стану й одне свіже рукостискання, і зібрати їх швидше, ніж провести нараду про те, чи потрібні вони.