Я дещо збентежений, як працює двосторонній SSL. Як клієнт створює свій сертифікат для надсилання на сервер? Чи генерується він із сервера та розподіляється клієнту?
Крім того, яка перевага двостороннього SSL перед одностороннім SSL?
Відповіді:
Обидва сертифікати повинні існувати до підключення. Зазвичай їх створюють органи сертифікації (не обов’язково однакові). (Є альтернативні випадки, коли перевірка може бути здійснена по-різному, але потрібно буде провести певну перевірку )
Сертифікат сервера повинен створюватися центром сертифікації, якому довіряє клієнт (і дотримуючись правил іменування, визначених у RFC 6125 ).
Клієнтський сертифікат повинен створювати центр сертифікації, якому сервер довіряє.
Кожна із сторін сама вирішує, чому вона довіряє.
Існують онлайн-інструменти ЦС, які дозволять вам подати заявку на сертифікат у своєму браузері та встановити його там, як тільки ЦС видає його. Вони не повинні бути на сервері, який вимагає автентифікації клієнт-сертифікат.
Розподіл сертифікатів та управління довірою - це роль Інфраструктури відкритих ключів (PKI), що реалізується через CA. Клієнт SSL / TLS та сервери, а потім лише користувачі цього PKI.
Коли клієнт підключається до сервера, який вимагає автентифікацію сертифіката клієнта, сервер надсилає список ЦС, які він готовий прийняти як частину запиту клієнтського сертифіката. Потім клієнт може надіслати свій сертифікат клієнта, якщо він цього бажає, і є відповідний.
Основними перевагами автентифікації сертифіката клієнта є:
Вас можуть зацікавити Переваги сертифікатів клієнта для аутентифікації клієнта? (на Security.SE) .
Те, що ви називаєте "двостороннім SSL", зазвичай називається TLS / SSL із аутентифікацією сертифіката клієнта.
У "звичайному" підключенні TLS до example.com лише клієнт перевіряє, чи справді він спілкується із сервером example.com. Сервер не знає, хто такий клієнт. Якщо сервер хоче аутентифікувати клієнта, звичайним є використання паролів, тому клієнту потрібно надіслати ім'я користувача та пароль на сервер, але це відбувається всередині з'єднання TLS як частина внутрішнього протоколу (наприклад, HTTP), це не частина самого протоколу TLS. Недоліком є те, що вам потрібен окремий пароль для кожного сайту, оскільки ви надсилаєте його на сервер. Отже, якщо ви використовуєте той самий пароль, наприклад, на PayPal і MyPonyForum, то кожного разу, коли ви входите в MyPonyForum, ви надсилаєте цей пароль на сервер MyPonyForum, щоб оператор цього сервера міг перехопити його та спробувати на PayPal і може здійснювати платежі на ваше ім’я .
Аутентифікація сертифіката клієнта пропонує інший спосіб автентифікації клієнта в TLS-з'єднанні. На відміну від входу до пароля, автентифікація сертифіката клієнта вказується як частина протоколу TLS. Це працює аналогічно способу автентифікації сервера клієнтом: клієнт генерує пару відкритих приватних ключів і передає відкритий ключ довіреному центру сертифікації для підписання. Центр сертифікації повертає сертифікат клієнта, який можна використовувати для автентифікації клієнта. Клієнт тепер може використовувати один і той же сертифікат для автентифікації на різних серверах (тобто ви можете використовувати один і той же сертифікат для PayPal та MyPonyForum, не ризикуючи зловживати ним). Це працює так, що після того, як сервер надіслав свій сертифікат, він просить клієнта також надати сертифікат. Потім відбувається якась магія відкритого ключа (якщо ви хочете знати прочитані деталіRFC 5246 ), і тепер клієнт знає, що він взаємодіє з правильним сервером, сервер знає, що він спілкується з правильним клієнтом, і обидва мають загальний ключовий матеріал для шифрування та перевірки з'єднання.
У двох напрямках ssl клієнт запитує сервери цифрового сертифіката, а сервер запитує те саме у клієнта. Це більш надійно, як і в обидві сторони, хоча і трохи повільно. Як правило, ми не дотримуємося цього, оскільки сервер не піклується про ідентичність клієнта, але клієнт повинен переконатися в цілісності сервера, до якого він підключається.