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

HSTS је једноставан док не престане да буде

HTTP Strict Transport Security, обично скраћено HSTS, поручује прегледачима: „за овај сајт увек користи HTTPS.” Када прегледач прими заглавље преко важеће HTTPS везе, памти то правило током периода који наведете.

То је корисно. Спречава нападе снижавања протокола, смањује случајне небезбедне захтеве и избегава непријатан тренутак у ком корисник унесе example.com и накратко додирне обичан HTTP пре преусмеравања.

Такође је лепљиво. Ако објавите погрешну HSTS политику, прегледачи могу наставити да је спроводе дуго након што уклоните заглавље са сервера. Тако тимови сами себи ускрате приступ: не баш сопственом админ панелу, већ корисничким прегледачима, поддоменима, staging системима, legacy крајњим тачкама и заборављеним сервисима који нису спремни за принудни HTTPS.

Циљ није да избегнете HSTS. Циљ је да га уведете као миграцију, а не као прекидач.

Шта HSTS заглавље заправо ради

Типично HSTS заглавље изгледа овако:

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

Има три важна дела:

• max-age: колико дуго, у секундама, прегледач треба да спроводи HTTPS за овај host.
• includeSubDomains: да ли се правило примењује и на сваки поддомен.
• preload: сигнал да желите да домен буде укључен у browser preload листе.

Прегледач верује овом заглављу само када га прими преко важећег HTTPS-а. Ако је сертификат неважећи, истекао или не одговара host-у, прегледач не би требало да прихвати нову HSTS политику из тог одговора.

Када се политика сачува, будући покушаји посете http://example.com надограђују се у прегледачу на https://example.com пре него што се захтев пошаље. То је добитак за приватност: небезбедан захтев никада не напушта уређај.

Сценарији ускраћеног приступа које треба избећи

Већину HSTS проблема не изазива главни website. Догађају се на ивицама.

1. Заборављени поддомен није спреман за HTTPS

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

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• било шта друго под тим доменом

Ако било који од тих host-ова не може да послужи важећи HTTPS, корисници са кешираном HSTS политиком неће моћи да им приступе преко HTTP-а.

2. Сертификат истекне

Без HSTS-а, корисници понекад прођу кроз упозорења о сертификату. То није добра безбедносна пракса, али се дешава.

Са HSTS-ом, модерни прегледачи не дозвољавају лако заобилажење грешака сертификата за тај host. То је и поента. Такође значи да обнова сертификата мора бити досадна, надгледана и тестирана.

3. Staging или интерни алати живе под production доменом

Смештање интерних алата под *.example.com може постати болно када родитељски домен користи includeSubDomains. Ако ти алати користе самопотписане сертификате, приватне ауторитете за сертификате, старе TLS конфигурације или уопште немају HTTPS, HSTS ће открити ту пречицу.

То је један од разлога због којих многи тимови држе интерне и експерименталне системе под засебним доменом који има сопствену безбедносну политику.

4. Preload се третира као рутинско поље за потврду

HSTS preload није само још једна директива. То значи да ваш домен може бити испоручен унутар прегледача као HTTPS-only пре него што било који корисник посети ваш сајт.

То затвара празнину „прве посете”, али је много теже поништити. Уклањање са preload листа може потрајати недељама или месецима док не стигне до корисника, у зависности од циклуса издања прегледача. Preload је прикладан за стабилне, зреле домене. Није прикладан за сајт који још увек открива сопствени инвентар поддомена.

Безбедан план увођења

Корак 1: Проверите сваки hostname који контролишете

Пре постављања includeSubDomains, наведите сваки hostname под доменом. DNS записи су почетак, али не и цела прича. Проверите CDN конфигурације, hosting контролне табле, hostname-ове повезане са е-поштом, старе маркетиншке алате, storage bucket-е и интерну документацију.

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

• Да ли служи HTTP, HTTPS или оба?
• Да ли је HTTPS сертификат важећи и аутоматски се обнавља?
• Да ли се HTTP чисто преусмерава на HTTPS?
• Да ли је намењен јавности?
• Да ли је и даље потребан?

Ако ваш тим већ има навике debug-овања production заглавља, ово се природно уклапа уз провере преусмеравања и заглавља. Тај workflow смо обрадили у малом комплету алата за debug-овање преусмеравања и HTTP заглавља у production окружењу.

Корак 2: Поправите HTTPS пре додавања HSTS-а

HSTS не чини покварено HTTPS подешавање безбедним. Он само чини HTTPS обавезним.

Пре него што га омогућите, проверите:

• TLS сертификати покривају исправне hostname-ове.
• Сертификати се аутоматски обнављају.
• HTTP се преусмерава на HTTPS једним чистим кораком где је то могуће.
• Преусмеравања канонског host-а су доследна, на пример са non-www на www, или обрнуто.
• Ресурси апликације не зависе од небезбедних http:// URL-ова.

Mixed content је ређи него раније, али се и даље појављује у старим CMS темама, analytics snippet-има, уграђеним медијима и hard-coded путањама до слика.

Корак 3: Почните са веома кратким max-age

Не почињите са једном годином. Почните са пет минута:

Strict-Transport-Security: max-age=300

Поставите то само на hostname који тестирате, обично канонски production website. За сада изоставите includeSubDomains.

Затим тестирајте у стварним прегледачима и помоћу захтева из командне линије:

curl -I https://example.com

Требало би да видите тачно једно Strict-Transport-Security заглавље. Дуплирана HSTS заглавља са app server-а и CDN-а чест су извор забуне. Прегледачи углавном примењују ефективну политику, али људима који debug-ују инцидент није потребна двосмисленост.

Корак 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 година

Нема награде за журбу. Цела поента постепеног увођења је да вашем monitoring-у, support inbox-у и рубним случајевима дате времена да вам кажу шта је ваша контролна листа пропустила.

Корак 5: Додајте includeSubDomains тек након стварне провере

Када је сваки јавни поддомен спреман за HTTPS, можете размотрити:

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

Ово је тренутак за конзервативност. Ако један legacy сервис и даље треба HTTP, немојте додавати includeSubDomains на родитељски домен. Или мигрирајте тај сервис, преместите га на други домен, или прихватите да ваша HSTS политика за сада мора остати ужа.

Безбедносна заглавља треба да одражавају стварност. Не треба их користити као мотивационе постере за инфраструктуру коју се надате да ћете имати касније.

Корак 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 домен или домен са нејасним границама власништва, прескочите то.

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

Nginx

Користите always како би се заглавље слало и на одговорима са грешком:

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 примењује заглавља на преусмеравања, кеширане грешке и прилагођене странице грешака. 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 није довољно за нове профиле прегледача. Такође треба да затражите уклањање са preload листе и сачекате да та промена буде испоручена кроз ажурирања прегледача.

Контролна листа за тестирање пре испоруке

Користите ову контролну листу пре повећања max-age или додавања includeSubDomains:

• Канонски HTTPS URL враћа важећи сертификат.
• HTTP се преусмерава на HTTPS.
• Постоји само једно HSTS заглавље.
• Заглавље се појављује на преусмеравањима и одговорима са грешком где је прикладно.
• Сви јавни поддомени имају важећи HTTPS.
• Обнова сертификата се надгледа.
• Ниједан критичан интерни систем не зависи од HTTP-а под истим родитељским доменом.
• О preload-у се експлицитно разговарало, није додат из навике.

Lighthouse такође може да означи недостајућа или слаба безбедносна заглавља у неким контекстима, али не би требало да буде ваш једини метод провере. Ако га користите као део шире ревизије, читајте налазе као сигнале, а не као пресуде; исти начин размишљања важи када читате Lighthouse извештај без панике.

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

💡 Испробајте ово: Пре и после сваке HSTS промене проверите Strict-Transport-Security одговор помоћу Get Headers да бисте потврдили да су max-age, includeSubDomains и preload онакви какве очекујете.

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

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

HSTS се често представља као безбедносно заглавље, и то јесте. Има и корист за приватност: смањује вероватноћу да први захтев корисника процури преко обичног HTTP-а на непоузданој мрежи.

То је важно на аеродромском Wi-Fi-ју, хотелским мрежама, корпоративним guest мрежама и свуда где би кориснички саобраћај могао бити посматран или измењен. Обичан HTTP захтев може открити hostname, путању, cookies без Secure заставице и друге детаље захтева. HTTPS није магија, али његово доследно наметање уклања читаву класу избегљивог цурења.

Најбоље HSTS имплементације су незанимљиве. Уводе се споро, ослоњене су на поуздане сертификате и довољно су досадне да их нико не примети. То је управо оно што желите од заглавља чији режим отказа може бити драматичан.