Обмін ключами TLS проти клієнтського сертифіката: що з них виконує вхід?
Відокремте узгодження ключа від автентифікації клієнта та ідентичності застосунку і прочитайте повідомлення рукостискання, які показують, що саме використало з'єднання.
Передавання публічного значення обміну ключами в рукостисканні — не та сама подія, що вхід клієнта. Одне встановлює криптографічний стан для з'єднання; інше повідомляє, ким є клієнт, і відбувається лише тоді, коли сервер цього попросить і обмін це підтримує. Якщо вважати перше другим, можна дійти хибних висновків про те, що VPN приховує, а що ні. Прочитайте повідомлення і лише потім вирішіть, яку з чотирьох властивостей ви справді спостерігали.
Два об'єкти, які в записі виглядають однаково
Клієнт TLS 1.3 може передати матеріал обміну ключами в першому польоті, не пред'являючи жодного сертифіката. Цей внесок публічний за задумом, бо серверові він потрібен для виведення спільної таємниці. Клієнтський сертифікат — інше повідомлення, він надсилається лише після того, як сервер його попросить. Він несе ідентичність, яку сервер потім перевіряє, а взаємна автентифікація — рішення сервера, а не властивість, яку нібито накладає набір шифрів. Ідентичність застосунку — зовсім третя річ: форма входу, bearer-токен, cookie. Ніщо з цього не з'являється в рукостисканні, і все це переживає зміну мережевого шляху.
| Object in play | What it establishes |
|---|---|
| Key-exchange share | Cryptographic state for this connection |
| Server certificate | Which server the client reached |
| Client certificate | Client authentication, when requested |
| Application session | Account identity inside the application |
Чотири рядки незалежні. З'єднання може мати перший і другий рядок, пропустити третій і все одно нести четвертий у заголовку cookie.
Вирішіть, що може довести записане рукостискання
Лише з рукостискання спостерігач дізнається узгоджену версію, набір шифрів, сертифікат сервера та публічні значення обміну ключами. Цього достатньо, щоб зняти відбиток реалізації клієнта і побачити, до якого сервера зверталися. Чого воно не дає — приватного стану, потрібного для розшифрування з'єднання; його таємність спирається на ефемерний обмін, а не на публічну частку. Воно також не дає ідентичності облікового запису, якої від початку не було в рукостисканні.
Отже, чесний висновок вузький: у цьому обміні клієнтський сертифікат не пред'являвся. Річ не в тому, що клієнт не надіслав нічого зіставлюваного, і вже точно не в тому, що сеанс не ніс жодного ідентифікатора.
Читайте повідомлення, а не назву шифру
Запитайте сервер, що він запитує, замість того щоб висновувати з набору шифрів. Рукостискання TLS 1.3 із запитом сертифіката видно в розшифровці, і його відсутність так само помітна.
openssl s_client -connect app.example.net:443 -tls1_3 -msg < /dev/null 2>&1 | grep -i -E 'key_share|CertificateRequest'Потім повторіть із налаштованим клієнтським сертифікатом і порівняйте. Другий запуск має показати, що сертифікат надсилається й приймається; перший не має показувати нічого, і саме в цьому конкретна різниця, про яку йдеться.
openssl s_client -connect app.example.net:443 -tls1_3 -cert client.pem -key client.key -quietЯкщо вам потрібен лише звичайний випадок перегляду, докладного виводу клієнта достатньо, щоб побачити версію протоколу, результат перевірки та чи пропонувався клієнтський сертифікат. Сервер, який ніколи не надсилає запит сертифіката, не міг його отримати.
Де відновлення змінює відповідь
Відновлення в TLS 1.3 використовує квитки, пов'язані з таємним станом, тож пізніше з'єднання може завершитися без повного обміну сертифікатами. Це зменшує те, що бачить спостерігач, і змінює те, що доводить розшифровка. Воно не створює ідентичності там, де її не було. Відновлений сеанс усе ще належить тому самому сеансу застосунку, і будь-який cookie або токен у ньому залишається значущим ідентифікатором.
Тому огляд приватності, що зупиняється на «клієнтського сертифіката немає», пропускає цікаве. Питання в тому, яка сторона має стабільний ідентифікатор, а не яке повідомлення було відсутнє в одному рукостисканні.
Запишіть чотири властивості, а не один вердикт
Запишіть узгодження ключа, перевірку сервера, автентифікацію клієнта та ідентичність застосунку як чотири окремі рядки, з доказом для кожного. Цей перелік переживає зміни версії протоколу і робить доказ про приватність перевірним для іншої людини. Потім додайте, що дає мережевий шлях. VPN змінює адресу джерела, яку бачить сервіс; він не видаляє вхід, cookie або відбиток пристрою, які застосунок уже має.
Запишіть разом узгоджену версію з'єднання та результат запиту сертифіката, бо саме ця пара потрібна рецензентові, щоб відтворити ваш висновок без власного запису.