Аудит конфігурації HTTPS

Вставте заголовки відповіді сайту — а, якщо маєте, його сертифікат, фрагмент вихідного коду сторінки і ім'я хоста — і ця сторінка повідомить, як налаштовано бік HTTPS: чи встановлено HSTS і на скільки, чи оновлює політика безпеки вмісту небезпечні запити, чи позначено cookie як Secure і SameSite, чи банер сервера видає версію і що кажуть прокси-заголовки про запит, який справді бачив застосунок. Сертифікат аудитується в тому самому звіті, прості підресурси http:// підраховуються з вихідного коду сторінки, а команди, які бачать рукостискання, перелічено для запуску вами. Усе працює у вашому браузері, і сторінка не робить власних запитів.
1. Заголовки відповіді
Увесь блок заголовків відповіді, включно з рядком статусу. Найпростіше джерело: curl -sI https://example.com/ у терміналі або панель Headers вкладки Network в інструментах розробника браузера, скопійована з початку файлу. Додаткові заголовки читаються і ігноруються; повідомляються лише ті, що стосуються HTTPS.
2. Сертифікат або ланцюжок (необов'язково)
Коли це заповнено, той самий звіт також містить повний аудит сертифіката, тож конфігурацію і сертифікат читають разом. Працюють PEM, голе тіло base64 або hex і .p7b PKCS#7; перевірник сертифікатів глибше розбирає сам сертифікат окремо.
3. Фрагмент вихідного коду сторінки (необов'язково)
Вставте вихідний код сторінки (або лише теги з URL), і буде перелічено кожну просту адресу http://, бо підресурс, завантажений по HTTP, ламає значок замка і може бути переписаний у дорозі, навіть коли сама сторінка прийшла по HTTPS. Адреси на власний хост сайту виділяються окремо, бо саме їх відносний URL міг би виправити.
4. Ім'я хоста (необов'язково)
Якщо тут вказано ім'я хоста, аудит перевіряє альтернативні імена суб'єкта так, як це робить браузер, включно з правилами підстановок, і зіставляє прості адреси http:// з ним.
аудит ще не проведено
Зразок навмисно недосконалий, щоб кожна частина звіту мала що показати: блок заголовків з HSTS і політикою безпеки вмісту (але без preload і з одним cookie без SameSite), дворівневий ланцюжок сертифікатів і фрагмент сторінки, що завантажує скрипт по простому http:// і вказує зображення на власний хост сайту так само. Очікуйте F на зразку і читайте знахідки нижче, щоб побачити, що означає кожна.
Що перевіряється. З блоку заголовків: HSTS, його max-age, includeSubDomains і preload; політика безпеки вмісту, що оновлює небезпечні запити; прапорці Secure, HttpOnly і SameSite на кожному Set-Cookie; банер сервера, що називає продукт і версію; і прокси-заголовки, які повідомляють, чи бачив застосунок запит як HTTPS. З блоку сертифіката: повний аудит сертифіката, аж до того, чи справді кожне посилання ланцюжка підписало наступне. З вихідного коду сторінки: прості підресурси http://. Три частини звітуються окремо, а потім підсумовуються разом, бо зламаний значок замка зазвичай є однією з цих трьох, а не двома іншими. Для повного списку OWASP заголовків відповіді безпеки — X-Content-Type-Options, захист від фреймів, Referrer-Policy, Permissions-Policy, COOP, COEP, CORP і оцінку за балами — вставте той самий блок заголовків на сторінку Перевірка заголовків безпеки; дві сторінки розділяють роботу за шаром TLS і шаром заголовків.

Чого вона не бачить. Ця сторінка ніколи не відкриває з'єднання TLS. Браузери не розкривають сторінці рукостискання, тож версія протоколу, набір шифрів, група обміну ключами, OCSP stapling, відновлення сесії, 0-RTT, ланцюжок сертифікатів, який справді надсилає живий сервер, і чи відбувається перенаправлення з HTTP на HTTPS на origin або на проксі — усе це поза межами того, що може повідомити будь-яка веб-сторінка. Вона також не може дістатися до стороннього сайту, щоб зібрати заголовки за вас, і не може сказати, чи довірений сертифікат, бо це залежить від сховища коренів, яке сторінка не може прочитати. Команди нижче бачать ці речі, і їх мусите запускати ви самі, на власній машині.

Де взяти блок заголовків. У терміналі curl -sI https://example.com/ виводить саме те, чого хоче ця сторінка. У браузері відкрийте інструменти розробника, перейдіть на вкладку Network, перезавантажте сторінку, виберіть запит документа і скопіюйте всю область Response Headers, або скористайтеся Copy → Copy response headers. Для перевірки перенаправлення також виконайте curl -sI http://example.com/ і вставте обидва блоки — сторінка звітує їх один за одним.
Звіт аудиту
Аудит ще не проведено. Вставте блок заголовків вище і натисніть Провести аудит конфігурації для повного звіту; сертифікат, фрагмент вихідного коду сторінки і ім'я хоста необов'язкові, і кожне додає власний розділ.
Перевірка досяжності — єдина частина цієї сторінки, що використовує мережу
Сторінка не може відкрити з'єднання TLS, але може спробувати звичайний запит. Якщо сайт дозволяє читання між джерелами, URL, на який врешті потрапляє відповідь, показує, чи було перенаправлено http:// на https://, і це все, що тут можна довести. Якщо запит не вдається, ця сторінка не може сказати, чи хост недоступний, чи ваше власне з'єднання не працює, чи сайт просто не дозволяє читання між джерелами — останнє є поширеним випадком, бо більшість сайтів не надсилає Access-Control-Allow-Origin. URL http:// відповідається до будь-якого перенаправлення, тож це єдине, що тут спробує браузер через звичайне з'єднання. Нічого не покидає браузер, доки ви не натиснете кнопку.
Команди, які справді бачать рукостискання
curl -sI https://example.com/ # the header block this page reads curl -sI http://example.com/ # is plain HTTP answered, or redirected? curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' http://example.com/ openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null 2>/dev/null \ | openssl x509 -noout -subject -issuer -dates -ext subjectAltName nmap --script ssl-enum-ciphers -p 443 example.com testssl.sh example.com # or: docker run --rm -ti drwetter/testssl.sh example.com
Їх мусите запускати ви, на машині, яку контролюєте, проти хоста, який вам дозволено тестувати. Вивід -showcerts можна вставити прямо в перевірник сертифікатів, а вивід заголовків — назад на цю сторінку.
Сертифікат — публічний документ. Кожен публічно довірений сертифікат публікується в журналах прозорості сертифікатів, тож будь-яке ім'я хоста всередині нього — зокрема внутрішнє чи помилково надруковане, яке підписав публічний центр сертифікації, — можна знайти, шукаючи в цих журналах. Сертифікат також містить адреси відкликання, які обрав його видавець, і вони іноді називають внутрішній хост. Тому сертифікат, який віддає CDN, нічого не каже про origin-сервер: імена в ньому належать CDN. Якщо аудит виявляє ім'я хоста, якого ви не очікували, вважайте його публічним і замініть те, що воно захищає.

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