Щоб налаштувати SSL сертифікат, один з наших клієнтів, Олексій, слідував покрокового керівництва, і, здавалося, все пройшло добре. Але пізніше почали з'являтися негативні наслідки, наприклад, тривалий час завантаження, часткова недоступність веб-сайту. Все це дуже засмутило Олексія, так як від установки SSL сертифікату він очікував тільки поліпшення роботи свого веб-проекту. Наша підтримка вирішила розібратися з помилками конфігурації і допомогти Олексію насправді захистити дані відвідувачів його сайту.
Якщо налаштувати SSL невірно, користі не буде навіть від найкращого сертифіката
Олексій вибрав SSL сертифікат від постачальника, який обіцяв найвищий рівень захисту за кілька кліків. Вивчивши інформацію, Олексій зрозумів, що простого сертифіката з перевіркою тільки домену буде недостатньо. Він вибрав рішення середнього класу і замовив SSL сертифікат з перевіркою компанії. Раніше ми вже розглядали різні рівні валідації.
Пройшовши перевірку і отримавши файли сертифіката, Олексій взявся за його установку. Він крок за кроком слідував посібника з інсталяції. Але щось пішло не так ... Сторінка початку завантажуватися повільніше, часом була недоступною, і, як з'ясувалося в тесті від Qualys SSL Labs, що не була дійсно захищеною. Що ж сталося?
Помилки конфігурації через застаріле керівництва
Олексій зв'язався з нами і надіслав результати тесту SSL-сервера, так як йому вони були не зовсім зрозумілі. Ми також попросили Олексія надіслати нам керівництво, за яким він встановлював SSL сертифікат. При цьому виявилося, що в інструкції не враховувалося актуальний стан в справ в області безпеки, в зв'язку з чим багато користувачів залишалися в небезпеці, навіть з встановленим сертифікатом.
Конфігурація SSL при обміні ключами
Далі ми проаналізували, як відбувається обмін ключами. SSL-тест від Qualys для цього дозволяє змоделювати процес рукостискання. З'ясувалося, що підтримка SNI була включена, а ось від прямої секретності Олексій відмовився. Пряма секретність (скорочено - PFS, від «Perfect Forward Секретність») - це функція, яка використовує ключа сеансу для того, щоб в ретроспективі можна було розшифрувати передані повідомлення. Після закінчення сесії ключ сеансу видаляється і зв'язок залишається в секретності. Детальніше ви дізнаєтеся в нашій статті «Налаштування прямий секретності».
Далі ми пояснили Олексію, що термін дії сертифіката, довіреність центру сертифікації, а також використовувані алгоритми хешування також впливають на оцінку. Олексій вибрав дуже хороший SSL сертифікат, тому до досягнення гарної оцінки залишалося всього кілька кроків. Насправді, сертифікати EV з розширеною перевіркою оцінюються вище, це Олексій знав і раніше, але дозволив собі заощадити. Проте, він простежив, щоб при випуску сертифіката використовувався довгий приватний ключ, який він сам зберігає на захищеному комп'ютері. Олексій захистив сертифікатом імена користувачів і паролі, як він і планував. Але помилки в налаштуванні SSL можуть зробити навіть найкращий сертифікат марним.
Cookies також слід захищати
Олексій вирішив використовувати файли Cookies. Він додав відповідне попередження для відвідувачів сайту і вказав на використання цього технології в Політиці конфіденційності.
Проте, він не помітив одну деталь: файли cookies також необхідно захищати, в іншому випадку збільшується ймовірність проведення MITM-атаки. За допомогою спеціальних прапорів можна встановити, чи будуть cookies передаватися по захищеному HTTPS-з'єднання або по незахищеному HTTP-з'єднання.
Якщо не встановити прапори безпеки, відбувається наступне: користувач звертається до вашого сайту по HTTPS і cookie починає свою роботу, тобто відстежує дії цього користувача. Пізніше, відвідувач повертається, але на цей раз він звертається до сайту по HTTP. Cookie як і раніше відправляється до веб-додатку. У такій ситуації зловмисник може відстежити cookie, видати себе за користувача, і вільно діяти від його імені.
Використання HSTS для усунення помилок
Як ми бачимо, можливість управляти зашифрованими сайтами через HTTP, тобто по незахищеному каналу, відкриває велику дірку в безпеці. Цю проблему можна вирішити за допомогою механізму HSTS. HSTS (скорочено від «HTTP Strict Transport Security») - це технологія, яка примусово активує захищене HTTPS-з'єднання. Всі сучасні браузери використовують HSTS як стандарт. Активоване HSTS встановлює, що (HTTP-) сервера повинні використовувати захищене з'єднання. Також HSTS-стандарт зобов'язує прикладні програми взаємодіяти з сайтом тільки по зашифрованому каналу. У двох словах: HSTS запобігає використання HTTP і активує HTTPS-з'єднання.
OCSP для збільшення секретності
За допомогою методу «OCSP-Степлінг» можна вирішити проблеми, викликані OCSP. Через певні проміжки часу, наприклад, кожну годину, веб-сервер отримує OCSP-відповідь про стан власного сертифіката. Ця відповідь відправляється безпосередньо браузеру користувача при первинному рукостисканні. З'єднання між браузером користувача та OCSP-відповідачем з цією метою не потрібно. Безпека процесу забезпечується тим, що відповідь OCSP-відповідь завжди підписаний OCSP-відповідачем центру сертифікації, і цей підпис перевіряє браузер.
HPKP - пиннинг відкритого ключа
Чи можна довіряти сертифікату з ланцюжка кореневого і проміжних сертифікатів? Щоб отримати відповідь на це питання, використовується процедура, яка називається HPKP, скорочено від HTTP Public Key Pinning. Пиннинг відкритого ключа дозволяє визначити, коли відкритий ключ сертифіката був змінений для певного хоста. Це може статися з скомпрометовані сертифікатами. Таким чином, HPKP стає механізмом, який перевіряє справжність сертифікатів SSL / TLS.
Правильна настройка SSL сертифікату: інструкції, яким можна довіряти
Звичайно ж, інструкцій по установці довіряти можна і потрібно, але вони повинні бути актуальними. Наступні рекомендації з надійних джерел допоможуть вам уникнути помилок:
загальні рекомендації
Наступні рекомендації носять загальний характер і, отже, служать в якості орієнтира:
- використовуйте безпечне HTTPS-з'єднання для всіх веб-сервісів;
- автоматичне перенаправлення: щоб уникнути незашифрованих звернень до сервера, налаштуйте автоматичне перенаправлення на HTTPS-версію;
- бібліотеки TLS: покладайтеся лише на останні версії. При використанні TLS ви нікого не виключаєте, але якщо ви застосовуєте незахищений SSL, ви також вмикаєте і потенційних хакерів;
- налаштуйте HSTS, щоб гарантовано виключити незашифровані з'єднання. Це можна зробити двома способами: по-перше, ви можете доповнити заголовок HSTS так, щоб браузер звертався тільки до HTTPS-версії сайту. По-друге, ви можете помістити свій сайт в список попереднього завантаження HSTS. Він оповіщає сучасні браузери, що HTTP-звернення необхідно автоматично перенаправляти на HTTPS;
- замовляйте SSL / TLS сертифікати тільки на довірених сайтах;
- найкраще замовляйте SSL сертифікати з розширеною перевіркою (Extended Validation). Вони підвищують довіру відвідувачів до достовірності вашого сайту;
- переконайтеся, що ваш постачальник SSL сертифікатів швидко замінить їх в разі компрометації. У важливості цього аспекту ми переконалися після необхідності масово міняти сертифікати внаслідок Heartbleed;
- використовуйте такі механізми, як PFS, щоб не допустити розшифровку даних в ретроспективі, якщо їх вдалося роздобути.
Наша підтримка готова відповісти на всі ваші запитання і допомогти вам захистити ваш веб-сайт!
Купити SSL сертифікат
Забезпечте захист переданих даних за допомогою SSL сертифікату