Як перевіряються сертифікати ssl?

Яка серія кроків необхідна для надійної перевірки ssl сертифікату? Моє (дуже обмежене) розуміння полягає в тому, що, коли ви відвідуєте веб-сайт https, сервер надсилає клієнту сертифікат (браузер) сертифікат, і браузер отримує інформацію про емітента сертифіката з цього сертифіката, потім використовує його для зв’язку з видавцем, і якось порівнює сертифікати на дійсність.

• Як саме це робиться?
• А що з цим процесом робить його незахищеним від атак людини на середину?
• Що заважає якійсь випадковій людині створити власну службу перевірки для використання в атаках "людина-посеред", тому все "виглядає" безпечно?

Ось дуже спрощене пояснення:

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

2. Ваш веб-браузер оснащений відкритими ключами всіх основних сертифікаційних органів. Він використовує цей відкритий ключ для підтвердження того, що сертифікат веб-сервера справді був підписаний довіреним органом сертифікації.

3. Сертифікат містить доменне ім’я та / або ip-адресу веб-сервера. Ваш веб-браузер підтверджує з органом сертифікації, що адреса, зазначена в сертифікаті, є тією, до якої він має відкрите з'єднання.

4. Ваш веб-браузер генерує спільний симетричний ключ, який буде використовуватися для шифрування трафіку HTTP на цьому з'єднанні; це набагато ефективніше, ніж використання шифрування публічного / приватного ключа для всього. Ваш веб-переглядач зашифровує симетричний ключ із відкритим ключем веб-сервера, після чого надсилає його назад, забезпечуючи тим самим, що тільки веб-сервер може розшифрувати його, оскільки лише приватний веб-сервер має свій приватний ключ.

Зауважте, що сертифікаційний орган (CA) має важливе значення для запобігання нападів "посередника". Однак навіть непідписаний сертифікат не дозволить комусь пасивно слухати ваш зашифрований трафік, оскільки у них немає можливості отримати доступ до вашого спільного симетричного ключа.

Варто зауважити, що крім придбання сертифіката (як уже згадувалося вище), ви можете також створити свій власний безкоштовно; це позначається як "самопідписаний сертифікат". Різниця між самопідписаним сертифікатом та придбаним простим: придбаний сертифікат був підписаний органом сертифікації, про який ваш браузер уже знає. Іншими словами, ваш веб-переглядач може легко підтвердити справжність придбаного сертифіката.

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

Якщо ви надійно поширюєте самопідписаний сертифікат (або сертифікат CA, як запропонував bobince), і встановлюєте його в браузери, які використовуватимуть ваш сайт , він настільки ж безпечний, як придбаний і не вразливий для людини в середині напади та підробка церта. Очевидно, це означає, що це можливо лише в тому випадку, якщо лише декілька людей потребують безпечного доступу до вашого сайту (наприклад, внутрішні додатки, особисті блоги тощо).

Ти сказав це

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

Клієнт не повинен спілкуватися з емітентом, оскільки дві речі:

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

Зауважте, що 2. не обійтися без 1.

Це краще пояснено в цій великій діаграмі, яку я склав деякий час тому

(перейти до "що таке підпис?" внизу)

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

Ви можете вивчити та / або змінити список довірених органів. Часто ви робите це, щоб додати до місцевого органу влади сертифікат, якому ви знаєте, якому ви довіряєте - наприклад, компанії, в якій ви працюєте, або школі, яку відвідуєте, чи ні.

Список попередньо насіннєвих елементів може змінюватися залежно від того, якого клієнта ви використовуєте. Великі постачальники сертифікатів SSL гарантують, що їх кореневі сертифікати є у всіх основних браузерах ($$$).

Атаки мавпи в середині "неможливі", якщо зловмисник не має приватного ключа довіреного кореневого сертифіката. Оскільки відповідні сертифікати широко розгорнуті, викриття такого приватного ключа може мати серйозні наслідки для безпеки електронної комерції. Через це ці приватні ключі дуже і дуже ретельно охороняються.

якщо ви більш технічно налаштовані, цей сайт, мабуть, те, що ви хочете: http://www.zytrax.com/tech/survival/ssl.html

попередження: кроляча нора заглиблюється :).