SSTP і SSL 3.0: ярлик проти узгодженої версії

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

Дві відповіді на те саме питання

Аргумент від ярлика легко сформулювати: SSTP описано як захищений протокол тунелювання через сокети, історична назва каже SSL, отже з’єднання має бути SSL 3.0. Він тримається тому, що назва справді походить із цієї лінії, і тому, що більшість тих, хто його повторює, ніколи не дивилися на рукостискання. Він тримається ще й тому, що висновок звучить обережно, ніби припустити найгірше — безпечний вибір. Припускати найгірше і вимірювати фактичну версію — різні заняття, і лише одне з них щось змінює.

Аргумент від доказу ставить вужче питання. Про яку версію протоколу домовилися цей клієнт і цей сервер, на цій кінцевій точці, у цей момент? Відповідь надходить від служби, яка завершує TLS, а не з маркетингової сторінки чи з браузера, що потрапив на схоже названий сайт.

Ці два аргументи різняться тим, що вони можуть довести. Ярлик не відрізняє старе розгортання від виправленого, а рукостискання не скаже, чим займається стороння служба на тому самому вузлі. Користуйтеся другим і перестаньте користуватися першим.

Прочитайте версію, яку служба справді вибирає

Почніть із переліку компонентів: клієнтська реалізація, серверна реалізація, кінцева точка TLS і все між ними, що завершує й заново встановлює TLS. Балансувальник навантаження, який завершує TLS і говорить із бекендом звичайним HTTP, змінює те, чию політику вам потрібно читати.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null> | grep -E 'Protocol|Cipher'
Get-WinEvent -LogName System -ProviderName Schannel -MaxEvents 20

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

Відокремте поле запису від узгодження

Старомодний на вигляд номер версії в одному полі — не той самий факт, що сеанс SSL 3.0. RFC 7568 розглядає версію рівня записів і узгоджений протокол як різні питання, і саме з цього розрізнення беруться впевнені хибні відповіді. Прочитайте узгоджений протокол, потім шифр, і лише потім робіть висновок про сеанс.

Той самий документ недвозначний щодо самого протоколу: SSL 3.0 не можна використовувати, а узгодження або відкат до нього заборонені. Причина — зламана конструкція CBC, яку використала атака POODLE, і це властивість протоколу, а не конфігурація одного застосунку.

Тому «це навантаження, ймовірно, важко експлуатувати» не є аргументом за те, щоб залишити SSL 3.0 увімкненим. Вимога — вилучити протокол, а не виграти суперечку про одну демонстрацію.

Виведіть SSL 3.0 з експлуатації з політикою, яку можна обґрунтувати

У Windows параметри протоколів Schannel містяться в розділі Protocols і читаються окремо для ролі клієнта та ролі сервера, тому зміна, що виправляє один напрямок, може залишити інший недоторканим. Поточні параметри та вимоги до перезапуску задокументовані Microsoft, а стороння бібліотека TLS на тому самому вузлі повністю їх ігнорує.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server'
Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols'

Змініть політику через підтримуваний шлях адміністрування, переконайтеся, що служба-власник заново отримує конфігурацію, і збережіть схвалений шлях повернення. Вставлення широкого скрипту реєстру з іншого середовища — це спосіб перетворити виправлення однієї служби на простій для кожного TLS-клієнта на машині. Обсяг перезапуску тут важливий: параметр, який виглядає застосованим, може все ще зберігатися в пам’яті служби, що його не перечитала.

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

Приймайте зміну на нових з’єднаннях

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

Пам’ятайте, чого рукостискання не охоплює. SSTP передає автентифікацію PPP після рівня TLS, тож сучасна версія протоколу нічого не каже про те, який користувач був авторизований або до яких ресурсів може дістатися сеанс. Це окремі механізми контролю з окремими доказами.

Запишіть результат як служба, бекенд, дозволена політика й спостережувана версія. Такий запис точно відповідає на питання безпеки, чого не робить ні аргумент від ярлика, ні аргумент від незручності.