Cum să configurezi HSTS fără să îți blochezi accesul

HSTS este simplu până când nu mai este

HTTP Strict Transport Security, prescurtat de obicei HSTS, le spune browserelor: „pentru acest site, folosește întotdeauna HTTPS.” După ce un browser primește antetul printr-o conexiune HTTPS validă, reține regula pe durata pe care o specifici.

Este util. Previne atacurile de retrogradare a protocolului, reduce cererile nesigure accidentale și evită momentul stânjenitor în care un utilizator tastează example.com și atinge pentru scurt timp HTTP simplu înainte de redirecționare.

Este și persistent. Dacă publici politica HSTS greșită, browserele pot continua să o aplice mult timp după ce elimini antetul de pe server. Așa ajung echipele să își blocheze accesul: nu neapărat la propriul panou de administrare, ci la browserele utilizatorilor, subdomenii, sisteme de staging, endpoint-uri vechi și servicii uitate care nu sunt pregătite pentru HTTPS forțat.

Scopul nu este să eviți HSTS. Scopul este să îl implementezi ca pe o migrare, nu ca pe un comutator.

Ce face de fapt antetul HSTS

Un antet HSTS tipic arată astfel:

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

Are trei părți importante:

• max-age: cât timp, în secunde, browserul trebuie să impună HTTPS pentru această gazdă.
• includeSubDomains: dacă regula se aplică și fiecărui subdomeniu.
• preload: un semnal că vrei ca domeniul să fie inclus în listele preload ale browserelor.

Browserul are încredere în acest antet doar când îl primește prin HTTPS valid. Dacă certificatul este invalid, expirat sau nepotrivit, browserul nu ar trebui să accepte o nouă politică HSTS din acel răspuns.

După ce politica este stocată, încercările viitoare de a vizita http://example.com sunt actualizate de browser la https://example.com înainte ca cererea să fie trimisă. Acesta este câștigul de confidențialitate: cererea nesigură nu părăsește niciodată dispozitivul.

Scenariile de blocare de evitat

Cele mai multe eșecuri HSTS nu sunt cauzate de site-ul principal. Se întâmplă la margini.

1. Un subdomeniu uitat nu este pregătit pentru HTTPS

includeSubDomains sună ordonat, dar este absolut. Dacă îl setezi pe example.com, se aplică pentru:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• orice altceva sub acel domeniu

Dacă oricare dintre aceste gazde nu poate servi HTTPS valid, utilizatorii cu politica HSTS în cache nu le vor putea accesa prin HTTP.

2. Un certificat expiră

Fără HSTS, utilizatorii uneori trec mai departe după avertismentele de certificat. Nu este o practică bună de securitate, dar se întâmplă.

Cu HSTS, browserele moderne nu permit ocolirea ușoară a erorilor de certificat pentru acea gazdă. Acesta este scopul. Înseamnă, de asemenea, că reînnoirea certificatelor trebuie să fie banală, monitorizată și testată.

3. Instrumentele de staging sau interne sunt sub domeniul de producție

Plasarea instrumentelor interne sub *.example.com poate deveni dureroasă după ce domeniul părinte folosește includeSubDomains. Dacă acele instrumente folosesc certificate auto-semnate, autorități de certificare private, configurații TLS vechi sau deloc HTTPS, HSTS va expune scurtătura.

Acesta este unul dintre motivele pentru care multe echipe păstrează sistemele interne și experimentale sub un domeniu separat, care are propria politică de securitate.

4. Preload este tratat ca o bifă de rutină

HSTS preload nu este doar o altă directivă. Înseamnă că domeniul tău poate fi livrat în browsere ca fiind exclusiv HTTPS înainte ca vreun utilizator să îți fi vizitat site-ul.

Asta închide golul de la „prima vizită”, dar este mult mai greu de anulat. Eliminarea din listele preload poate dura săptămâni sau luni până ajunge la utilizatori, în funcție de ciclurile de lansare ale browserelor. Preload este potrivit pentru domenii stabile, mature. Nu este potrivit pentru un site care încă își descoperă inventarul de subdomenii.

Un plan de lansare sigur

Step 1: Auditează fiecare hostname pe care îl controlezi

Înainte să setezi includeSubDomains, listează fiecare hostname de sub domeniu. Înregistrările DNS sunt un început, dar nu întreaga poveste. Verifică configurațiile CDN, dashboard-urile de hosting, hostname-urile legate de email, instrumentele vechi de marketing, bucket-urile de stocare și documentația internă.

Pentru fiecare hostname, răspunde:

• Servește HTTP, HTTPS sau ambele?
• Certificatul HTTPS este valid și reînnoit automat?
• Redirecționează HTTP către HTTPS curat?
• Este menit să fie public?
• Mai este necesar?

Dacă echipa ta are deja obiceiuri de depanare a antetelor în producție, acest lucru se potrivește natural lângă verificările de redirecționări și antete. Am acoperit acel flux de lucru în un mic toolkit pentru depanarea redirecționărilor și antetelor HTTP în producție.

Step 2: Repară HTTPS înainte de a adăuga HSTS

HSTS nu face sigură o configurare HTTPS stricată. Doar face HTTPS obligatoriu.

Înainte să îl activezi, verifică:

• Certificatele TLS acoperă hostname-urile corecte.
• Certificatele se reînnoiesc automat.
• HTTP redirecționează către HTTPS printr-un singur pas curat, acolo unde este posibil.
• Redirecționările gazdei canonice sunt consecvente, de exemplu de la non-www la www, sau invers.
• Resursele aplicației nu depind de URL-uri nesigure http://.

Conținutul mixt este mai puțin frecvent decât era, dar încă apare în teme CMS vechi, fragmente de analytics, media încorporată și căi de imagini hardcodate.

Step 3: Începe cu un max-age foarte scurt

Nu începe cu un an. Începe cu cinci minute:

Strict-Transport-Security: max-age=300

Implementează-l doar pe hostname-ul pe care îl testezi, de obicei site-ul de producție canonic. Lasă deoparte includeSubDomains pentru moment.

Apoi testează în browsere reale și cu cereri din linia de comandă:

curl -I https://example.com

Ar trebui să vezi exact un singur antet Strict-Transport-Security. Antetele HSTS duplicate de la un server de aplicație și un CDN sunt o sursă comună de confuzie. Browserele aplică în general politica efectivă, dar oamenii care depanează un incident nu au nevoie de ambiguitate.

Step 4: Crește treptat

Dacă nu se strică nimic, mărește durata în etape:

Strict-Transport-Security: max-age=86400

Apoi:

Strict-Transport-Security: max-age=604800

Apoi poate:

Strict-Transport-Security: max-age=2592000

Un calendar practic este:

• 5 minute
• 1 zi
• 1 săptămână
• 1 lună
• 6 luni sau 1 an

Nu există niciun premiu pentru grabă. Întregul scop al lansării etapizate este să le dai monitorizării, inboxului de suport și cazurilor de margine timp să îți spună ce a ratat checklist-ul.

Step 5: Adaugă includeSubDomains doar după ce auditul este real

După ce fiecare subdomeniu public este pregătit pentru HTTPS, poți lua în calcul:

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

Acesta este momentul să fii conservator. Dacă un serviciu legacy încă are nevoie de HTTP, nu adăuga includeSubDomains pe domeniul părinte. Fie migrezi acel serviciu, fie îl muți pe alt domeniu, fie accepți că politica ta HSTS trebuie să rămână mai îngustă deocamdată.

Antetele de securitate ar trebui să reflecte realitatea. Nu ar trebui folosite ca postere motivaționale pentru infrastructura pe care speri să o ai mai târziu.

Step 6: Tratează preload ca pe un proiect separat

Ia în calcul preload doar când toate cele de mai jos sunt adevărate:

• Domeniul și toate subdomeniile acceptă HTTPS valid.
• HTTP redirecționează către HTTPS.
• Antetul HSTS folosește max-age de cel puțin 31536000 de secunde.
• Antetul include includeSubDomains.
• Antetul include preload.
• Ești sigur că nu vei avea nevoie de HTTP simplu nicăieri sub domeniu.

Un antet pregătit pentru preload arată astfel:

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

Trimiterea către lista preload este un angajament pe termen lung. Dacă site-ul este un microsite de campanie, un domeniu temporar de produs sau un domeniu cu limite neclare de proprietate, sari peste acest pas.

Exemple de configurare

Nginx

Folosește always pentru ca antetul să fie trimis și pe răspunsurile de eroare:

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

După ce lansarea este stabilă:

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

Apache

Cu mod_headers activat:

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

Mai târziu:

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

CDN sau platformă edge

Dacă CDN-ul setează antete de răspuns, preferă să gestionezi HSTS într-un singur loc. Nu seta o politică la origin și alta la edge decât dacă ai un motiv foarte clar.

Verifică și dacă CDN-ul aplică antetele pe redirecționări, erori din cache și pagini de eroare personalizate. Un site de producție nu înseamnă doar răspunsul său 200 OK.

Cum să anulezi HSTS în siguranță

Dacă trebuie să dezactivezi HSTS, trimite:

Strict-Transport-Security: max-age=0

Dar există o capcană: browserul trebuie să poată ajunge cu succes la site prin HTTPS valid pentru a primi acel antet. Dacă HTTPS însuși este stricat, utilizatorii cu o politică HSTS în cache nu pot prelua instrucțiunea care ar șterge-o.

Așadar, ordinea obișnuită de recuperare este:

1. Restaurează HTTPS valid.
2. Servește Strict-Transport-Security: max-age=0.
3. Păstrează-l suficient timp pentru ca utilizatorii care revin să îl primească.
4. Elimină sau înlocuiește antetul după ce incidentul este rezolvat.

Dacă domeniul este preloaded, servirea lui max-age=0 nu este suficientă pentru profilurile noi de browser. Trebuie, de asemenea, să soliciți eliminarea din lista preload și să aștepți ca acea schimbare să fie livrată prin actualizările browserelor.

Checklist de testare înainte de lansare

Folosește acest checklist înainte să mărești max-age sau să adaugi includeSubDomains:

• URL-ul HTTPS canonic returnează un certificat valid.
• HTTP redirecționează către HTTPS.
• Există un singur antet HSTS.
• Antetul apare pe redirecționări și pe răspunsurile de eroare, acolo unde este cazul.
• Toate subdomeniile publice au HTTPS valid.
• Reînnoirea certificatelor este monitorizată.
• Niciun sistem intern critic nu depinde de HTTP sub același domeniu părinte.
• Preload a fost discutat explicit, nu adăugat din obișnuință.

Lighthouse poate semnala, de asemenea, antete de securitate lipsă sau slabe în anumite contexte, dar nu ar trebui să fie singura ta metodă de verificare. Dacă îl folosești ca parte a unei revizuiri mai ample, citește constatările ca semnale, nu ca verdicte; aceeași mentalitate se aplică atunci când citești un raport Lighthouse fără panică.

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

💡 Încercați asta: Înainte și după fiecare modificare HSTS, inspectați răspunsul Strict-Transport-Security cu Get Headers pentru a confirma că max-age, includeSubDomains și preload sunt așa cum vă așteptați.

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

Argumentul de confidențialitate pentru HSTS

HSTS este adesea prezentat ca un antet de securitate, și chiar este. Are și un beneficiu de confidențialitate: reduce șansa ca prima cerere a unui utilizator să se scurgă prin HTTP simplu într-o rețea nesigură.

Acest lucru contează pe Wi-Fi de aeroport, rețele de hotel, rețele corporate pentru oaspeți și oriunde traficul unui utilizator ar putea fi observat sau modificat. O cerere HTTP simplă poate expune hostname-ul, calea, cookie-urile fără flag-ul Secure și alte detalii ale cererii. HTTPS nu este magie, dar impunerea lui consecventă elimină o întreagă clasă de scurgeri evitabile.

Cele mai bune implementări HSTS sunt neinteresante. Sunt lansate lent, susținute de certificate fiabile și suficient de plictisitoare încât nimeni să nu le observe. Exact asta îți dorești de la un antet al cărui mod de eșec poate fi dramatic.