Двостороннє уточнення SSL


76

Я дещо збентежений, як працює двосторонній SSL. Як клієнт створює свій сертифікат для надсилання на сервер? Чи генерується він із сервера та розподіляється клієнту?

Крім того, яка перевага двостороннього SSL перед одностороннім SSL?

Відповіді:


104

Обидва сертифікати повинні існувати до підключення. Зазвичай їх створюють органи сертифікації (не обов’язково однакові). (Є альтернативні випадки, коли перевірка може бути здійснена по-різному, але потрібно буде провести певну перевірку )

Сертифікат сервера повинен створюватися центром сертифікації, якому довіряє клієнт (і дотримуючись правил іменування, визначених у RFC 6125 ).

Клієнтський сертифікат повинен створювати центр сертифікації, якому сервер довіряє.

Кожна із сторін сама вирішує, чому вона довіряє.

Існують онлайн-інструменти ЦС, які дозволять вам подати заявку на сертифікат у своєму браузері та встановити його там, як тільки ЦС видає його. Вони не повинні бути на сервері, який вимагає автентифікації клієнт-сертифікат.

Розподіл сертифікатів та управління довірою - це роль Інфраструктури відкритих ключів (PKI), що реалізується через CA. Клієнт SSL / TLS та сервери, а потім лише користувачі цього PKI.

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

Основними перевагами автентифікації сертифіката клієнта є:

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

Вас можуть зацікавити Переваги сертифікатів клієнта для аутентифікації клієнта? (на Security.SE) .


вам слід замінити "створений" на "підписаний", щоб зберегти це доречним
CharlieS

1
@CharlieS " Зберігайте це доречно " ... Ви маєте на увазі, що це не актуально, коли використовується "створено" (формулювання відповідає запитанню) ;-)? "Видано" може бути справді кращим словом.
Бруно,

CA - це орган, що підписує сертифікат. Не має значення, як сертифікат був виданий чи створений, важливо лише те, що він підписаний сертифікованим органом. Я розумію, що більшість центрів сертифікації створюють / видають сертифікати відкритого ключа, підписані ними самими, і їх можна використовувати, але якщо потрібен вже існуючий відкритий ключ, він повинен бути підписаний ЦС.
CharlieS

@CharlieS Ні, насправді підписання - це насправді лише останній технічний крок у процесі сертифікації (який полягає у видачі сертифіката). Для ЦС не має сенсу підписувати сертифікат, виданий іншим ЦС, оскільки для перевірки потрібно побудувати DN видавця до DN суб’єкта. Сертифікат "створюється" лише тоді, коли він підписаний, оскільки до цього це CSR або трохи пізніше структура TBSCertificate (але все ще не сертифікат). Ти зачіпка на «створення», але сертифікат X.509 повинен бути підписаний на існування, і його підписання саме те , що виходить , що структура даних в CERT.
Бруно

Ви не дозволяєте підписувати сертифікати, видані іншим органом. x509 підписується, але не обов'язково надійним органом.
CharlieS

44

Те, що ви називаєте "двостороннім SSL", зазвичай називається TLS / SSL із аутентифікацією сертифіката клієнта.

У "звичайному" підключенні TLS до example.com лише клієнт перевіряє, чи справді він спілкується із сервером example.com. Сервер не знає, хто такий клієнт. Якщо сервер хоче аутентифікувати клієнта, звичайним є використання паролів, тому клієнту потрібно надіслати ім'я користувача та пароль на сервер, але це відбувається всередині з'єднання TLS як частина внутрішнього протоколу (наприклад, HTTP), це не частина самого протоколу TLS. Недоліком є ​​те, що вам потрібен окремий пароль для кожного сайту, оскільки ви надсилаєте його на сервер. Отже, якщо ви використовуєте той самий пароль, наприклад, на PayPal і MyPonyForum, то кожного разу, коли ви входите в MyPonyForum, ви надсилаєте цей пароль на сервер MyPonyForum, щоб оператор цього сервера міг перехопити його та спробувати на PayPal і може здійснювати платежі на ваше ім’я .

Аутентифікація сертифіката клієнта пропонує інший спосіб автентифікації клієнта в TLS-з'єднанні. На відміну від входу до пароля, автентифікація сертифіката клієнта вказується як частина протоколу TLS. Це працює аналогічно способу автентифікації сервера клієнтом: клієнт генерує пару відкритих приватних ключів і передає відкритий ключ довіреному центру сертифікації для підписання. Центр сертифікації повертає сертифікат клієнта, який можна використовувати для автентифікації клієнта. Клієнт тепер може використовувати один і той же сертифікат для автентифікації на різних серверах (тобто ви можете використовувати один і той же сертифікат для PayPal та MyPonyForum, не ризикуючи зловживати ним). Це працює так, що після того, як сервер надіслав свій сертифікат, він просить клієнта також надати сертифікат. Потім відбувається якась магія відкритого ключа (якщо ви хочете знати прочитані деталіRFC 5246 ), і тепер клієнт знає, що він взаємодіє з правильним сервером, сервер знає, що він спілкується з правильним клієнтом, і обидва мають загальний ключовий матеріал для шифрування та перевірки з'єднання.


Я створив client-rest-api, який викликає server-rest-api (односторонній післявиклик). Мій client-rest-api використовує сертифікати, видані сервером-rest-api. Однак мій client-rest-api ніколи не видавав жодних сертифікатів серверу-rest-api. Це підходить під односторонній ssl або двосторонній ssl? Подія, хоча це лише односторонній дзвінок від клієнта до сервера, я думаю, що його двосторонній ssl, оскільки тут server-rest-api перевіряє, чи має клієнт відповідні сертифікати, видані сервером?
Гімалай Маджумдар

1
@HimalayMajumdar: Якщо на вашому сервері є сертифікат, підписаний центром сертифікації, або якщо ви жорстко закодували цей сертифікат у своєму клієнті (закріплення), тоді так, це все ще належний TLS з аутентифікацією сертифіката клієнта (ви називаєте це двостороннім ssl). Ага :-). Якщо ваш клієнт, однак, довіряє вашому сертифікату сервера наосліп, технічно це все ще TLS з аутентифікацією сертифіката клієнта, але оскільки сертифікат сервера не може бути перевірений клієнтом, це не двосторонній спосіб, і в більшості випадків це дійсно погана ідея. Не роби цього :-(.
NEOatNHNG

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

5

У двох напрямках ssl клієнт запитує сервери цифрового сертифіката, а сервер запитує те саме у клієнта. Це більш надійно, як і в обидві сторони, хоча і трохи повільно. Як правило, ми не дотримуємося цього, оскільки сервер не піклується про ідентичність клієнта, але клієнт повинен переконатися в цілісності сервера, до якого він підключається.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.