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

сертифікати

Темпи впровадження HTTPS сьогодні досить швидкі - безпека в мережі досить актуальна тема. SSL сертифікати , Щоб забезпечити ця безпечне з'єднання, стають все більш затребуваними. Це актуально ще й тому, що найпопулярніший браузер оголосив про пред'явлення масового ультиматуму сайтам, які пропонують користувачам реєструватися на сайтах, що працюють по незахищеному протоколу http.

Відсоток сайтів з першого мільйона найпопулярніших сайтів за статистикою Alexa, де стоїть редирект на версію HTTPS

Як можна бачити на діаграмі, швидкість впровадження HTTPS збільшується. Судячи з усього, це справжній прогрес. При цьому процес отримання сертифікату безпеки стає простішим, в тому числі, завдяки їх безкоштовним версіями від Let's Encrypt .

Якщо коротко, потрібно просто відправити запит на отримання сертифіката (Certificate Signing Request, CSR) в центр сертифікації (CA), на що той запропонує довести факт володіння доменом. Зазвичай це робиться за допомогою зміни запису DNS TXT або розміщення спеціального коду десь за випадковим URL на домені. Як тільки завдання виконано, CA видає сертифікат, і ми можемо пред'являти його браузерам і насолоджуватися зеленим замком і зазначенням HTTPS в адресному рядку.

Однак, щось завжди може піти не за планом.

Якщо вас хакнули

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

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

скасування сертифіката

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

Сертифікат необхідно відкликати, як тільки факт злому був встановлений. Необхідно зв'язуватися з CA і попросити відкликати ваш сертифікат. При цьому потрібно довести факт володіння сертифікатом і після цього CA позначить сертифікат як відкликаний. Тепер потрібен спосіб повідомити про цей факт кожного клієнта, з яким може знадобитися дана інформація. Прямо в цей момент браузер, звичайно, нічого не знає, і це проблема. Є два механізми, які використовуються для поширення інформації: це список відкликаних сертифікатів (Certificate Revocation List, CRL) та протокол перевірки статусу сертифіката (Online Certificate Status Protocol, OCSP).

Списки відкликаних сертифікатів

CRL - дійсно дуже проста концепція, це просто список всіх сертифікатів, які CA позначив як відкликані. Клієнт може відправити запит до сервера CRL і завантажити копію списку. Маючи копію цього списку, браузер звіряє з ним пред'явлений сертифікат. Якщо він там присутній, то браузер знає, що вони недійсні і йому не можна довіряти, він тоді видасть помилку і розірве з'єднання. Якщо сертифіката в списку немає, то все нормально - і браузер продовжить роботу.

Проблема CRL в тому, що списки містять багато сертифікатів від конкретних центрів сертифікації. Не вдаючись у зайві деталі, вони розбиваються на проміжні сертифікати CA, а центр сертифікації може видавати списки меншими частинами, але проблема залишається тією ж. Список CRL досить великий. Інша проблема в тому, що у клієнта немає свіжої копії CRL, йому потрібно запросити її при першому підключенні до сайту, що може зробити всю процедуру помітно повільніше. Виглядає все це не дуже приємно, так що подивимося на OCSP.

Протокол перевірки статусу сертифіката

OCSP пропонує набагато більш гарне рішення проблеми і має значну перевагу перед CRL. Тут потрібно запитати у CA статус єдиного, конкретного сертифіката. Це означає, що CA повинен повернути тільки проста відповідь: сертифікат або хороший, або відкликаний, і така відповідь набагато менше за розміром, ніж список CRL.

Звичайно, OCSP перевершує CRL за швидкістю отримання відповіді, однак за цю перевагу потрібно платити і плата досить висока - ваша приватність ... Якщо подумати про суть запиту OCSP, це дуже конкретний запит на єдиний сертифікат HTTPS. По суті, відбувається витік інформації. Коли ви відправляєте запит OCSP, ви буквально питаєте у ЦС:

Сертифікат для pornhub.com валідний?

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

повний збій

Вище сказано про CRL і OCSP, двох механізмах перевірки сертифікатів браузером, і вони виглядають таким чином.

Після отримання сертифіката, браузер звернеться до одного з цих сервісів і відправить запит для остаточного з'ясування статусу сертифіката. Але що буде, якщо у вашого CA поганий день і його інфраструктура в офлайні? Що, якщо ситуація виглядає так?

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

частковий збій

Сьогодні браузери виконують так звану перевірку відкликання сертифікату з частковим збоєм. Тобто браузер спробує перевірити статус сертифіката, але якщо відповідь не прийшла зовсім або не прийшов за короткий проміжок часу, браузер про це просто "забуває". Найгірше, що Chrome навіть не намагається перевірити статус сертифіката, який до нього надходить. Однак це зовсім не дивно. Проблема з повним збоєм очевидна: якщо у CA поганий день, то він буде і у вас - так ми приходимо до логіки часткового збою. Браузер тепер намагається здійснити перевірку сертифіката на предмет відкликання, але повністю відмовляється від неї, якщо вона займає надто багато часу або якщо здається, що CA пішов в офлайн. Тобто перевірка сертифіката на предмет відкликання скасовується, «якщо здається, що CA пішов в офлайн». Цікаво, чи може зловмисник імітувати такі умови?

При здійсненні атаки MiTM для цього блокується запит на перевірку сертифіката і створюється враження, що CA не працює. Браузер тоді зіткнеться з частковим збоєм перевірки і продовжить використовувати відкликаний сертифікат. Якщо вас ніхто не атакує, то кожен раз при перевірці цього конкретного сертифіката ви будете витрачати час і ресурси на перевірку, що талон не відкликаний. І один раз, коли вас атакують - той єдиний раз, коли вам по-справжньому потрібна така перевірка - зловмисник просто заблокує з'єднання, і браузер буде проходити через частковий збій.

Що ж, Адам Ленглі з Google порівняв скасування сертифіката з ременем безпеки, який начебто завжди повинен вас захищати, але тут же підводить в момент аварії.

виправлення проблеми

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

Пріоритетні механізми

Якщо сайт скомпрометований і зловмисник отримав секретний ключ, він може підробити цей сайт і запустити цей фейк в мережу. Якщо це великий інформаційний ресурс або ж комерційна організація, масштаб можливої ​​трагедії очевидний. Однак може бути і гірше. Що якщо CA скомпрометований і зловмисник отримав секретний ключ для проміжного сертифіката? Це було б катастрофою, тому що тоді зловмисник може підробити буквально будь-який сайт, який захоче, підписавши власний сертифікат. Тому замість онлайнової перевірки проміжних сертифікатів на предмет відкликання у Chrome і Firefox є власні механізми для тієї ж задачі.

У Chrome він називається CRLsets , А в Firefox - OneCRL . Ці механізми перевіряють списки відкликаних сертифікатів, об'єднуючи доступні CRL і вибираючи звідти сертифікати. Так перевіряються особливо цінні сертифікати на кшталт проміжних, але що щодо звичайних?

OCSP Must-Staple

Щоб пояснити, що таке OCSP Must-Staple, потрібно спочатку коротко розібратися, що таке OCSP Stapling. Він позбавляє браузер від необхідності відправляти запит OCSP, видаючи відповідь OCSP разом з самим сертифікатом. Назва OCSP Stapling в буквальному сенсі означає, що сервер повинен «скріпити» (staple) відповідь OCSP з сертифікатом і видати їх разом.

На перший погляд це може здатися дивним, тому що сервер як ніби «сам засвідчує» власний сертифікат як невідкликаних, але все працює правильно. Відповідь OCSP діє тільки короткий проміжок часу і підписаний CA точно так же, як сертифікат. Так що якщо браузер може упевнитися, що сертифікат підписаний CA, то точно так він може упевнитися, що відповідь OCSP теж підписаний цим CA. Це усуває велику проблему приватності і позбавляє клієнта від тягаря виконувати зовнішній запит. Але це так само не кращий варіант ... OCSP Stapling - відмінна річ, і всі ми повинні підтримувати цю технологію на своїх сайтах, проте зловмисник цього робити не буде. Тому, дійсно, що в цьому випадку потрібно - це змусити сервер підтримувати OCSP Stapling, і ось для чого потрібен OCSP Must-Staple. При запиті сертифікату у CA потрібно попросити встановити на ньому прапор OCSP Must-Staple. Цей прапор вказує браузеру, що сертифікат повинен поставлятися з відгуком OCSP або він буде відкинутий. Встановлюється він легко.

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

OCSP Expect-Staple

Незважаючи на те, що Must-Staple здається відмінним рішенням перевірки відкликання сертифікатом, це не зовсім так. Однією з найбільших проблем є те, що оператор сайту не може точно знати, наскільки надійні мітки OCSP Staple і як їх приймає клієнт. Без включеного OCSP Must-Staple в цьому не буде нічого страшного, але якщо включити OCSP Must-Staple, а в надійності або правильності OCSP Staple ви не впевнені, для сайту це буде проблема. Щоб спробувати і отримати якусь зворотний зв'язок про якість міток OCSP Staple, можна активувати функцію під назвою OCSP Expect-Staple. Подробиці ви можете дізнатися в блозі OCSP Expect-Staple , Тут буде описано коротко. до того ж до списку предзагрузкі HSTS ви запитуєте браузер надіслати звіт, чи задоволений він міткою OCSP Staple. Ви можете збирати звіти самі або використовувати сервіс report-uri.io - в обох випадках ви точно дізнаєтесь, коли ваш сайт зіткнувся з проблемами при роботі OCSP Must-Staple. Оскільки використання списку предзагрузкі HSTS не так очевидно, була створена специфікація для визначення нового заголовка безпеки під назвою Expect-Staple , Щоб забезпечувати ту ж функціональність ціною менших зусиль. Ідея полягає в тому, що тепер ви можете встановити цей заголовок і включити функцію відправки звітів, які так нам потрібні, ще до активації Must-Staple. Установка заголовка буде простий:

Expect -Staple: max -age = 31536000; report-uri = "https://scotthelme.report-uri.io/r/d/staple"; includeSubDomains; preload

підроблені сертифікати

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

Certificate Transparency

CT - нова вимога, яке стане обов'язковим на початку наступного року. Воно передбачає, що всі сертифікати повинні заноситися в публічний журнал для того, щоб браузер їм довіряв. Тобто суть цього нововведення в тому, що CA заносить всі видані сертифікати в журнал CT.

Ці журнали повністю відкриті, і будь-хто може їх погортати. Тому, якщо хтось отримає сертифікат на ваш сайт, тут ви відразу ж про це дізнаєтеся. Для цієї ж мети існує сервіс CertSpotter , А так само інструмент Facebook Certificate Transparency Monitoring , Який надсилає вам лист кожен раз, коли виданий сертифікат на заданий домен.

Авторизація центрів сертифікації

Запобігти видачу сертифіката набагато простіше, ніж намагатися відкликати його, і саме для цього потрібна авторизація центрів сертифікації (CAA). Суть цього підходу в тому, що ви можете авторизувати тільки конкретні центри сертифікації видавати вам сертифікати. Авторизація робиться так само просто, як створення запису DNS:

scotthelme.co.uk. IN CAA 0 issue "letsencrypt.org"

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

І кілька слів наостанок

Як ви вже зрозуміли, на сьогодні відкликати сертифікат, якщо хтось заволодів вашим секретним ключем, дуже складно. Один з варіантів запобігання цієї проблеми - це обмежити розмір збитку від витоку, скоротивши термін дії свого сертифіката. Замість трьох років вказуйте один рік або навіть менше. Зокрема, Let's Encrypt видає сертифікати, які дійсні лише 90 днів. Скоротивши час життя вашого сертифіката, ви тим самим скоротіть можливий період шкідливого використання його шахраєм.

Джерело: https://habrahabr.ru/