Решта матеріали циклу:

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

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

1. Користувач запитує доступ до деякої мережевої служби;
2. За запитом сервер посилає клієнтові свій серверний сертифікат (сертифікат SSL). Клієнт перевіряє його на валідність. Якщо перевірка провалилася, на цьому все закінчується;
3. Якщо перевірка пройшла успішно, клієнт запитує доступ до ресурсів служби;
4. Служба налаштована на обов'язкову аутентифікацію користувача і відправляє клієнту доступні (на сервері) методи аутентифікації. У нашому випадку це вимога клієнтського сертифіката;
5. Клієнт посилає на сервер публічну частину свого сертифіката і певний обсяг підписаних клієнтським сертифікатом даних. Сервер перевіряє клієнтський сертифікат на валідність. Якщо сертифікат не пройшов перевірку - розмова клієнта і сервера на цьому завершується. Якщо сертифікат пройшов перевірку, сервер намагається зіставити (або асоціювати) сертифікат з обліковим записом користувача. Якщо порівняння не вдалося - розмова завершується.
6. Якщо обліковий запис знайдений і сертифікат вдалося зіставити з нею, сервер починає установку захищеного каналу. Після установки цього каналу, сервер надає користувачеві ресурси в тому обсязі, в якому це дозволяють списки доступу (ACL, наприклад).

Я вважав за потрібне трохи розгорнути останній пункт, щоб ви розуміли загальна будова цього каналу (оскільки, у людей є деякі помилки на цей рахунок):

1. Клієнт запитує установку безпечного каналу;
2. Сервер відповідає згодою і пересилає клієнту список підтримуваних симетричних протоколів шифрування;
3. Клієнт посилає на сервер свого списку протоколів симетричного шифрування;
4. Клієнт і сервер домовляються і вибирають найбільш підходящий протокол. Наприклад, - Я вмію DES і 3DES, а що вмієш ти? - А я вмію тільки 3DES і AES. - Дуже добре, давай тоді використовувати 3DES;
5. Клієнт на своєму боці генерує сесійний симетричний ключ шифрування і шифрує його відкритим ключем сертифікату сервера. Цей процес називається Key exchange. Як ми знаємо, прочитати цей ключ зможе тільки веб сервер, тому що тільки він володіє закритим ключем, який асоційований з конкретним сертифікатом SSL;
6. Після цього, всі передані дані шифруються саме цим сесійним ключем. Пам'ятайте, що при передачі даних сертифікати вже не використовуються (а багато хто вважає, що всі дані шифруються відкритими ключами сертифікатів). Сертифікати використовуються тільки при оновленні сесійного ключа (який періодично змінюється).

Трохи інший процес відбувається при інтерактивному логоні або логоні на сервер терміналів за допомогою Remote Desktop за допомогою смарт-карти.

Інтерактивна аутентифікація в Active Directory за сертифікатом не є самостійним механізмом. Як і завжди, основний протокол аутентифікації в домені - Kerberos. Щоб забезпечити взаємодію між аутентифікацією по смарт-карті і Керберос, застосовується нехитрий протокол PKINIT. PKINIT, в свою чергу, є лише надбудовою над Керберос (або розширенням протоколу). Ось як він приблизно працює:

Примітка: якщо у користувача вже є відповідний сервісний тікет (TGS), виконуються тільки кроки 5 і 6.

1. Користувач вводить PIN від смарт-карти і надсилає запит AS-REQ на контролер домену (він же Key Distribution Center - KDC). Цей запит містить преаутентіфікаціонние дані PA_PK_AS_REQ, які, в свою чергу, містять логоні сертифікат і підписана тимчасова мітка і опціональні атрибути. Як опціональних атрибутів, клієнт посилає список підтримуваних алгоритмів, кореневих CA, параметри Diffie-Hellman і т.д. Більш детально структуру запиту (а там є досить цікавих речей) можна знайти в RFC 4556 §3.2.1 (Пункт 5 на сторінці 12). У зв'язку з цим (наприклад, передача списку довірених кореневих CA від клієнта на сервер) час Логон смарт-картою буде значно повільніше, ніж при зв'язці логін / пароль. Плюс витрати на криптографічні операції.
2. Сервер KDC перевіряє запит і пробує асоціювати отриманий сертифікат з обліковим записом користувача. Якщо зіставлення сертифіката з обліковим записом відбулося успішно, KDC формує відповідь AS-REP, включаючи в нього Ticket-Granting Ticket (TGT) та іншу необхідну інформацію. Відповідь підписується сертифікатом самого KDC (саме тому, при використанні смарт-карти для Логон, сервер KDC повинен мати свій власний сертифікат (про нього ми поговоримо в наступних статтях).
3. Клієнт перевіряє цю відповідь і перевіряє підпис (разом з сертифікатом KDC). Якщо з відповіддю і сертифікатом все добре, клієнт, на основі наявного TGT, генерує Ticket Granting Service запит - TGS-REQ для доступу до конкретної службі і відправляє його на KDC.
4. KDC перевіряє запит TGS-REQ і в разі позитивного вердикту формує відповідь Ticket-Granting Service (TGS-REP), включаючи в нього всю необхідну інформацію для інтерактивного Логон, включаючи всі необхідні SID'и і облікові дані для аутентифікації за допомогою NTLM.
5. Клієнт генерує спеціальний токен GSS-API ( RFC 1964 ) І в нього загортає отриманий TGS-REP. На виході виходить запит AP-REQ, який прямує вже до конкретної службі, куди потрібен доступ.
6. Тут, власне, відбувається вже авторизація клієнта і між ними (клієнтом і серверної службою) починається свій власний діалог. Можливо, про баб :-)

В принципі, ось як приблизно (на досить високому рівні) відбувається клієнтська аутентифікація за сертифікатом. Дещо я опустив (що нам не настільки актуально в рамках даної статті), але дещо ми будемо більш щільно розглядати в наступних статтях - наприклад, маппинг сертифікатів (асоціація або зіставлення сертифіката з обліковим записом в Active Directory).

На останок, особливо допитливим умам - захоплююче чтиво: