Как да настроите HSTS, без да си отрежете достъпа

HSTS е прост, докато не престане да бъде

HTTP Strict Transport Security, обикновено съкращавано до HSTS, казва на браузърите: „за този сайт винаги използвай HTTPS“. След като браузър получи този хедър през валидна HTTPS връзка, той запомня правилото за срока, който сте задали.

Това е полезно. Предотвратява атаки за понижаване на протокола, намалява случайните несигурни заявки и избягва неловкия момент, в който потребителят въвежда example.com и за кратко докосва обикновен HTTP, преди да бъде пренасочен.

Но правилото е и устойчиво. Ако публикувате грешна HSTS политика, браузърите може да продължат да я прилагат дълго след като сте премахнали хедъра от сървъра си. Така екипите си отрязват достъпа: не точно до собствения си администраторски панел, а до браузърите на потребителите, поддомейните, staging системите, наследените крайни точки и забравените услуги, които не са готови за задължителен HTTPS.

Целта не е да избягвате HSTS. Целта е да го внедрите като миграция, а не като превключвател.

Какво всъщност прави HSTS хедърът

Типичен HSTS хедър изглежда така:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Той има три важни части:

• max-age: колко дълго, в секунди, браузърът трябва да налага HTTPS за този хост.
• includeSubDomains: дали правилото важи и за всеки поддомейн.
• preload: сигнал, че искате домейнът да бъде включен в preload списъците на браузърите.

Браузърът се доверява на този хедър само когато го получи през валиден HTTPS. Ако сертификатът е невалиден, изтекъл или не съответства, браузърът не би трябвало да приеме нова HSTS политика от този отговор.

След като политиката бъде съхранена, бъдещите опити за посещение на http://example.com се надграждат от браузъра до https://example.com, преди заявката да бъде изпратена. Това е ползата за поверителността: несигурната заявка никога не напуска устройството.

Сценариите на блокиране, които да избягвате

Повечето HSTS проблеми не се причиняват от основния уебсайт. Те се случват по краищата.

1. Забравен поддомейн не е готов за HTTPS

includeSubDomains звучи подредено, но е абсолютно. Ако го зададете за example.com, то важи за:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• всичко останало под този домейн

Ако някой от тези хостове не може да обслужва валиден HTTPS, потребителите с кеширана HSTS политика няма да могат да го достигнат през HTTP.

2. Сертификат изтича

Без HSTS потребителите понякога продължават въпреки предупрежденията за сертификати. Това не е добра практика за сигурност, но се случва.

С HSTS съвременните браузъри не позволяват лесно заобикаляне на грешки в сертификата за този хост. Именно това е идеята. Но то означава също, че подновяването на сертификатите трябва да бъде скучно, наблюдавано и тествано.

3. Staging или вътрешни инструменти живеят под production домейна

Поставянето на вътрешни инструменти под *.example.com може да стане болезнено, след като родителският домейн използва includeSubDomains. Ако тези инструменти използват самоподписани сертификати, частни сертификационни органи, стари TLS конфигурации или изобщо нямат HTTPS, HSTS ще извади наяве този пряк път.

Това е една от причините много екипи да държат вътрешните и експерименталните системи под отделен домейн със собствена политика за сигурност.

4. Preload се третира като рутинна отметка

HSTS preload не е просто още една директива. Той означава, че вашият домейн може да бъде доставян вътре в браузърите като HTTPS-only още преди който и да е потребител да е посетил сайта ви.

Това затваря пропуска при „първото посещение“, но е много по-трудно за отмяна. Премахването от preload списъците може да отнеме седмици или месеци, докато достигне до потребителите, в зависимост от циклите на изданията на браузърите. Preload е подходящ за стабилни, зрели домейни. Не е подходящ за сайт, който все още открива какви поддомейни има.

Безопасен план за внедряване

Step 1: Одитирайте всеки hostname, който контролирате

Преди да зададете includeSubDomains, избройте всеки hostname под домейна. DNS записите са начало, но не са цялата история. Проверете CDN конфигурации, hosting dashboards, свързани с имейл hostname-и, стари marketing tools, storage buckets и вътрешна документация.

За всеки hostname отговорете:

• Обслужва ли HTTP, HTTPS или и двете?
• Валиден ли е HTTPS сертификатът и подновява ли се автоматично?
• Пренасочва ли HTTP към HTTPS чисто?
• Трябва ли да бъде публичен?
• Все още ли е нужен?

Ако вашият екип вече има навици за debugging на production хедъри, това естествено се вписва до проверките на пренасочвания и хедъри. Описахме този работен процес в малък набор от инструменти за debugging на пренасочвания и HTTP хедъри в production.

Step 2: Поправете HTTPS, преди да добавите HSTS

HSTS не прави счупена HTTPS настройка сигурна. Той само прави HTTPS задължителен.

Преди да го включите, проверете:

• TLS сертификатите покриват правилните hostname-и.
• Сертификатите се подновяват автоматично.
• HTTP пренасочва към HTTPS с един чист hop, когато е възможно.
• Пренасочванията към canonical host са последователни, например от non-www към www или обратното.
• Application assets не зависят от несигурни http:// URL-и.

Mixed content е по-рядко срещан от преди, но все още се появява в стари CMS themes, analytics snippets, embedded media и hard-coded image paths.

Step 3: Започнете с много кратък max-age

Не започвайте с една година. Започнете с пет минути:

Strict-Transport-Security: max-age=300

Разгърнете това само на hostname-а, който тествате, обикновено canonical production уебсайта. Засега оставете includeSubDomains извън хедъра.

След това тествайте в реални браузъри и с command-line заявки:

curl -I https://example.com

Трябва да видите точно един Strict-Transport-Security хедър. Дублираните HSTS хедъри от app server и CDN са често срещан източник на объркване. Браузърите обикновено прилагат ефективната политика, но хората, които debug-ват инцидент, нямат нужда от двусмислие.

Step 4: Увеличавайте постепенно

Ако нищо не се счупи, увеличавайте продължителността на етапи:

Strict-Transport-Security: max-age=86400

След това:

Strict-Transport-Security: max-age=604800

После може би:

Strict-Transport-Security: max-age=2592000

Практичен график е:

• 5 минути
• 1 ден
• 1 седмица
• 1 месец
• 6 месеца или 1 година

Няма награда за бързане. Целият смисъл на поетапното внедряване е да дадете време на мониторинга, support inbox-а и edge cases да ви покажат какво е пропуснал checklist-ът ви.

Step 5: Добавете includeSubDomains само след реален одит

След като всеки публичен поддомейн е готов за HTTPS, можете да обмислите:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Това е моментът да бъдете консервативни. Ако една наследена услуга все още се нуждае от HTTP, не добавяйте includeSubDomains към родителския домейн. Или мигрирайте тази услуга, или я преместете в друг домейн, или приемете, че HSTS политиката ви засега трябва да остане по-тясна.

Хедърите за сигурност трябва да отразяват реалността. Те не бива да се използват като мотивационни плакати за инфраструктура, която се надявате да имате по-късно.

Step 6: Третирайте preload като отделен проект

Обмисляйте preload само когато всички следни условия са изпълнени:

• Домейнът и всички поддомейни поддържат валиден HTTPS.
• HTTP пренасочва към HTTPS.
• HSTS хедърът използва max-age от поне 31536000 секунди.
• Хедърът включва includeSubDomains.
• Хедърът включва preload.
• Уверени сте, че никъде под домейна няма да ви трябва обикновен HTTP.

Хедър, готов за preload, изглежда така:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Изпращането към preload списъка е дългосрочен ангажимент. Ако сайтът е campaign microsite, временен product domain или домейн с неясни граници на собственост, пропуснете го.

Примери за конфигурация

Nginx

Използвайте always, така че хедърът да се изпраща и при error responses:

add_header Strict-Transport-Security "max-age=300" always;

След като внедряването е стабилно:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache

С активиран mod_headers:

Header always set Strict-Transport-Security "max-age=300"

По-късно:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CDN или edge платформа

Ако вашият CDN задава response headers, предпочитайте да управлявате HSTS на едно място. Не задавайте една политика в origin и друга в edge, освен ако нямате много ясна причина.

Проверете също дали CDN прилага хедъри към redirects, cached errors и custom error pages. Production сайтът не е само неговият 200 OK отговор.

Как безопасно да отмените HSTS

Ако трябва да изключите HSTS, изпратете:

Strict-Transport-Security: max-age=0

Но има уловка: браузърът трябва успешно да достигне сайта през валиден HTTPS, за да получи този хедър. Ако самият HTTPS е счупен, потребителите с кеширана HSTS политика не могат да изтеглят инструкцията, която би я изчистила.

Затова обичайният ред за възстановяване е:

1. Възстановете валиден HTTPS.
2. Обслужвайте Strict-Transport-Security: max-age=0.
3. Дръжте го достатъчно дълго, за да го получат завръщащите се потребители.
4. Премахнете или заменете хедъра, след като инцидентът бъде разрешен.

Ако домейнът е preloaded, обслужването на max-age=0 не е достатъчно за нови browser profiles. Трябва също да поискате премахване от preload списъка и да изчакате тази промяна да бъде доставена чрез актуализациите на браузърите.

Checklist за тестване преди пускане

Използвайте този checklist, преди да увеличите max-age или да добавите includeSubDomains:

• Canonical HTTPS URL връща валиден сертификат.
• HTTP пренасочва към HTTPS.
• Има само един HSTS хедър.
• Хедърът се появява при redirects и error responses, където е уместно.
• Всички публични поддомейни имат валиден HTTPS.
• Подновяването на сертификатите се наблюдава.
• Нито една критична вътрешна система не зависи от HTTP под същия родителски домейн.
• Preload е обсъден изрично, а не добавен по навик.

Lighthouse може също да маркира липсващи или слаби security headers в някои контексти, но не трябва да бъде единственият ви метод за проверка. Ако го използвате като част от по-широк преглед, четете констатациите като сигнали, а не като присъди; същият подход важи, когато четете Lighthouse отчет без паника.

<!-- tool-cta:start -->

💡 Опитайте това: Преди и след всяка промяна на HSTS проверете отговора Strict-Transport-Security с Get Headers, за да потвърдите, че max-age, includeSubDomains и preload са такива, каквито очаквате.

<!-- tool-cta:end -->

Аргументът за поверителност при HSTS

HSTS често се представя като security header, и той е такъв. Но има и полза за поверителността: намалява вероятността първата заявка на потребителя да изтече през обикновен HTTP в недоверена мрежа.

Това има значение при airport Wi-Fi, hotel networks, corporate guest networks и навсякъде, където трафикът на потребителя може да бъде наблюдаван или променян. Обикновена HTTP заявка може да разкрие hostname, path, cookies без Secure flag и други детайли на заявката. HTTPS не е магия, но последователното му налагане премахва цял клас предотвратими течове.

Най-добрите HSTS внедрявания са безинтересни. Те се пускат бавно, подкрепени са от надеждни сертификати и са достатъчно скучни, че никой да не ги забележи. Точно това искате от хедър, чийто режим на отказ може да бъде драматичен.