Що доводить специфікація протоколу VPN, а що ні

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

Документ — це початок аргументу, а не його висновок.

Що документ насправді визначає

Для WireGuard опис протоколу визначає рукостискання Noise IK, фіксований набір примітивів, структури повідомлень і транспортне обрамлення, яке потім несе пакети. Для IKEv2 порівнюваний документ — RFC 7296, який визначає обміни, корисні навантаження та узгодження пропозицій. В обох випадках межі точні: повідомлення, машина станів і припущення, за яких діють цілі безпеки.

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

Де закінчуються гарантії

Формальний аналіз відповідає на питання про модель. Робота з верифікації WireGuard використовує символічну модель у доводжувачі Tamarin, який може показати, що проєкт витримує певні атаки за своїх припущень; він не показує, що поставлена реалізація в просторі користувача не має помилки безпеки пам'яті. Саме в цій прогалині між моделлю та машиною живуть реальні інциденти. Читати доказ як сертифікат реалізації — категоріальна помилка.

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

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

Простежте байти до самої збірки

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

openvpn --version | head -3
wg --version
dpkg -l | grep -E 'openvpn|wireguard|libssl'
ss -lunp | grep -E '1194|51820'
sha256sum ./wireguard-tools_1.0.20210914_amd64.deb

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

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

Тримайте експлуатаційні практики окремо

Записи облікових даних, платіжні дані та звернення до підтримки — це рішення оператора, які не обмежує жоден текст протоколу. Звіт аудиту охоплює названі компоненти в заявлених межах, а політика конфіденційності описує наміри та практики; жодне не замінює інше, і жодне не є криптографічним твердженням.

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