Примітка. Свою оригінальну відповідь я написав дуже поспішно, але з тих пір це перетворилося на досить популярне запитання / відповідь, тому я її трохи розширив і зробив більш точним.
Можливості TLS
"SSL" - це ім'я, яке найчастіше використовується для позначення цього протоколу, але SSL спеціально посилається на фірмовий протокол, розроблений Netscape в середині 90-х. "TLS" - це стандарт IETF, заснований на SSL, тому я буду використовувати TLS у своїй відповіді. Сьогодні шанси на те, що майже всі ваші захищені з'єднання в Інтернеті справді використовують TLS, а не SSL.
TLS має кілька можливостей:
- Зашифруйте дані рівня додатків. (У вашому випадку протоколом рівня додатків є HTTP.)
- Аутентифікувати сервер для клієнта.
- Аутентифікувати клієнта на сервері.
№1 і №2 дуже поширені. №3 зустрічається рідше. Ви, здається, зосереджуєтесь на №2, тому я поясню цю частину.
Аутентифікація
Сервер ідентифікує себе клієнту за допомогою сертифіката. Сертифікат - це сукупність даних [1], яка містить інформацію про веб-сайт:
- Доменне ім'я
- Публічний ключ
- Компанія, яка їй належить
- Коли він був виданий
- Коли термін його дії закінчується
- Хто його видав
- І т.д.
Ви можете домогтися конфіденційності (№1 вище), використовуючи відкритий ключ, включений у сертифікат, для шифрування повідомлень, які можна розшифрувати лише відповідним приватним ключем, який слід безпечно зберігати на цьому сервері. [2] Давайте назвемо цю ключову пару KP1, щоб згодом не заплутатися. Ви також можете перевірити, чи відповідає доменне ім'я сертифіката веб-сайту, який ви відвідуєте (№2 вище).
Але що робити, якщо супротивник може змінити пакети, надіслані на сервер і з нього, і що робити, якщо той противник змінив сертифікат, який вам подарували, і вставив власний відкритий ключ або змінив будь-які інші важливі дані? Якщо це сталося, противник міг перехопити та змінити будь-які повідомлення, які, на вашу думку, надійно зашифровані.
Щоб запобігти цій самій атаці, сертифікат криптографічно підписується чиїсь приватним ключем таким чином, що підпис може перевірити будь-хто, хто має відповідний відкритий ключ. Давайте назвемо цю ключову пару KP2, щоб зрозуміти, що це не ті самі ключі, якими користується сервер.
Органи сертифікації
То хто створив KP2? Хто підписав довідку?
Дещо спрощуючи, сертифікаційний орган створює KP2, і вони продають послугу використання свого приватного ключа для підписання сертифікатів для інших організацій. Наприклад, я створюю сертифікат і плачу такій компанії, як Verisign, щоб підписати його своїм приватним ключем. [3] Оскільки ніхто, крім Verisign, не має доступу до цього приватного ключа, ніхто з нас не може підробити цей підпис.
І як я особисто отримав відкритий ключ у KP2, щоб підтвердити цю підпис?
Ми вже бачили, що сертифікат може містити відкритий ключ - а комп'ютерні фахівці люблять рекурсію - так чому б не ввести відкритий ключ KP2 у сертифікат і не поширити його таким чином? Спочатку це звучить трохи шалено, але насправді саме так воно і працює. Продовжуючи приклад Verisign, Verisign виробляє сертифікат, який включає інформацію про те, хто вони є, які типи речей вони можуть підписувати (інші сертифікати) та їх відкритий ключ.
Тепер, якщо у мене є копія цього сертифікату Verisign, я можу використовувати його для перевірки підпису на сертифікаті сервера для веб-сайту, який я хочу відвідати. Легко, правда ?!
Ну, не так швидко. Мені довелося десь отримати сертифікат Verisign . Що робити, якщо хтось підробляє сертифікат Verisign і додає туди свій відкритий ключ? Тоді вони можуть підробити підпис на сертифікаті сервера, і ми повернулися туди, де ми почали: атака "людина-в-середині".
Ланцюжки сертифікатів
Продовжуючи рекурсивно мислити, ми, звичайно, можемо ввести третій сертифікат і третю пару ключів (KP3) і використовувати це для підписання сертифікату Verisign. Ми називаємо це ланцюжком сертифікатів: кожен сертифікат у ланцюжку використовується для перевірки наступного сертифіката. Сподіваємось, ви вже можете побачити, що цей рекурсивний підхід - це лише черепахи / сертифікати аж донизу. Де зупиняється?
Оскільки ми не можемо створити нескінченну кількість сертифікатів, очевидно, що ланцюжок сертифікатів повинен десь зупинитися , і це робиться, включивши сертифікат у ланцюг, який самостійно підписується .
Я на хвилину замовчу, поки ти вибереш шматочки мозкової речовини з голови, що вибухає. Самопідпис ?!
Так, наприкінці ланцюжка сертифікатів (він же "корінь") з'явиться сертифікат, який використовує власну клавішу для підписання. Це усуває нескінченну проблему рекурсії, але вона не виправляє проблему автентифікації. Будь-хто може створити самопідписаний сертифікат, який говорить про що завгодно, так само як я можу створити фальшивий диплом Принстона, який говорить про те, що я потрійно маю на увазі політику, теоретичну фізику та застосовую ноги, а потім підпишу своє власне ім’я внизу.
[Дещо незвичне] рішення цієї проблеми полягає лише в тому, щоб вибрати якийсь набір самопідписаних сертифікатів, яким ви явно довіряєте. Наприклад, я можу сказати: "Я довіряю цьому сертифікату самопідписання Verisign".
Маючи таку явну довіру, тепер я можу підтвердити весь ланцюжок сертифікатів. Незалежно від того, скільки сертифікатів у ланцюжку є, я можу підтвердити кожен підпис аж до кореня. Коли я дістаюсь до кореня, я можу перевірити, чи є цей кореневий сертифікат, якому я явно довіряю. Якщо так, то я можу довіряти всій ланцюжку.
Довірена довіра
Для аутентифікації в TLS використовується система наданої довіри . Якщо я хочу найняти автомеханіка, я не можу довіряти жодному випадковому механіку, який я знайду. Але, можливо, мій друг поручається на конкретного механіка. Оскільки я довіряю своєму другові, то я можу довіряти цьому механіку.
Купуючи комп'ютер або завантажуючи веб-переглядач, він отримує декілька сотень кореневих сертифікатів, яким він явно довіряє. [4] Компанії, які володіють цими сертифікатами та керують ними, можуть надавати довіру іншим організаціям, підписуючи свої сертифікати.
Це далеко не досконала система. Інколи КА може помилково видавати сертифікат. У цих випадках сертифікат, можливо, буде потрібно відкликати. Скасування є складним, оскільки виданий сертифікат завжди буде криптографічно правильним; позапрофільний протокол необхідний, щоб з’ясувати, які раніше дійсні сертифікати були анульовані. На практиці деякі з цих протоколів не надто захищені, і багато браузери все одно не перевіряють їх.
Іноді весь ЦА піддається компрометації. Наприклад, якщо ви повинні прорватися до Verisign і викрасти їх кореневий ключ для підписання, ви можете підробити будь-який сертифікат у світі. Зверніть увагу, що це не стосується лише клієнтів Verisign: навіть якщо мій сертифікат підписує Thawte (конкурент Verisign), це не має значення. Мій сертифікат все ще можна підробити за допомогою компромісного ключа підпису від Verisign.
Це не просто теоретично. Це сталося в дикій природі. DigiNotar був зламаний, а згодом збанкрутував. Комодо також був зламаний , але незрозуміло, що вони залишаються в бізнесі і донині.
Навіть коли ЦС не піддаються прямому злому, в цій системі є й інші загрози. Наприклад, уряд використовує юридичний примус, щоб примусити ЦС підписати підроблену довідку. Ваш роботодавець може встановити власний сертифікат CA на комп'ютер вашого працівника. У цих різних випадках трафік, який ви очікуєте "захищений", насправді повністю видимий / модифікований для організації, яка контролює цей сертифікат.
Запропоновано деякі заміни, зокрема конвергенція , TACK та DANE .
Кінцеві замітки
[1] Дані сертифіката TLS відформатований в відповідно до стандартом X.509 . X.509 заснований на ASN.1 ("Абстрактна нотація синтаксису №1"), що означає, що це не бінарний формат даних. Тому X.509 повинен бути закодований у двійковий формат. DER і PEM - це два найпоширеніші кодування, про які я знаю.
[2] На практиці протокол насправді переходить на симетричний шифр, але це деталь, яка не стосується вашого питання.
[3] Імовірно, CA фактично підтверджує, хто ти є, перед тим, як підписати свій сертифікат. Якщо вони цього не зробили, я можу просто створити сертифікат для google.com і попросити ЦА підписати його. З цим сертифікатом я міг би перетворити будь-яке "безпечне" з'єднання з google.com. Тому крок перевірки є дуже важливим фактором в роботі СА. На жаль, не дуже зрозуміло, наскільки жорсткий цей процес перевірки у сотнях ЦА по всьому світу.
[4] Див. Список надійних ЦО Mozilla .
