HSTS și lista preload HSTS

De ce nu este suficient doar HTTPS

Cei mai mulți vizitatori ajung pe un site tastând numele sau urmând un link vechi care începe cu http://. Serverul redirecționează apoi către HTTPS, însă acea primă cerere necriptată poate fi interceptată într-o rețea ostilă. Un atacator aflat la mijloc poate ține victima pe HTTP și poate transmite mai departe site-ul real prin el însuși; tehnica, numită SSL stripping, funcționează în tăcere atât timp cât utilizatorul nu observă lipsa lacătului din bara de adrese. Redirecționarea în sine nu închide această fereastră, pentru că atacatorul o poate elimina fără ca utilizatorul să o vadă vreodată.

HTTP Strict Transport Security (RFC 6797) închide fereastra pentru vizitatorii care revin. După ce un browser a văzut antetul Strict-Transport-Security printr-o conexiune HTTPS validă, rescrie intern către HTTPS fiecare cerere viitoare către acea gazdă, înainte ca ceva să plece în rețea. În plus, nu îi mai permite utilizatorului să treacă peste erorile de certificat pentru acea gazdă. Politica acoperă doar numele care a trimis antetul și este ținută minte pe durata max-age; fiecare răspuns nou care poartă antetul repornește acest interval.

Antetul

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

Browserele ignoră antetul când acesta sosește prin HTTP simplu, pentru că acolo un atacator l-ar putea injecta. Trimiteți-l așadar doar în răspunsurile HTTPS și puneți-l în fiecare răspuns, inclusiv în redirecționări și în paginile de eroare, astfel încât politica să fie împrospătată indiferent pe ce pagină ajunge vizitatorul. Separați directivele prin punct și virgulă și trimiteți antetul o singură dată în același răspuns, pentru că browserele folosesc primul antet valid și îl ignoră pe restul. Nici ghilimelele din jurul valorii nu sunt necesare; cele din exemplele nginx și Apache țin de sintaxa configurației, nu de antetul propriu-zis.

server {
    listen 443 ssl;
    server_name example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

<VirtualHost *:443>
    ServerName example.com
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</VirtualHost>

Cum activați HSTS în siguranță

Riscul la HSTS nu este antetul în sine, ci memoria lui. Dacă publicați o politică de un an și apoi aveți nevoie de HTTP simplu pe acea gazdă sau dacă expiră un certificat, browserele care au văzut antetul refuză să se conecteze până la expirarea politicii. O activare etapizată scoate la iveală aceste probleme cât timp max-age este încă scurt și reduce revenirea la o chestiune de câteva minute.

Înainte de pasul 3, listați fiecare subdomeniu care există în DNS și verificați că fiecare funcționează prin HTTPS cu un certificat valid. Interogare DNS și exportul zonei dumneavoastră DNS sunt punctul de plecare; nu uitați imprimantele, vechile nume de intranet și gazdele de staging folosite doar de oamenii din companie. Lista scoasă din fișierul de zonă nu este de obicei suficientă: numele ascunse în spatele înregistrărilor wildcard și subdomeniile create de alte echipe din panourile lor proprii nu apar acolo.

Anunțați fiecare etapă echipelor care administrează subdomenii. O notă scurtă cu data și valoarea max-age planificată le dă ocazia să mute pe HTTPS un serviciu care merge doar pe HTTP, înainte ca acesta să se strice. Păstrarea anunțului într-un loc scris elimină și întrebarea de peste câteva luni despre cine și când a activat politica.

Verificați cu Verificatorul de antete HTTP că antetul apare în răspunsurile dumneavoastră reale. Instrumentul raportează max-age în zile și spune dacă includeSubDomains și preload sunt prezente. Repetați verificarea nu doar pe pagina principală, ci și pe o pagină internă, pe un răspuns 404 și pe domeniul fără www care redirecționează; antetele lipsă apar de obicei exact în aceste trei locuri.

Ce poate strica includeSubDomains

includeSubDomains setat pe example.com se aplică fiecărui nume aflat sub el, inclusiv celor servite de alte echipe sau de furnizori. Orice subdomeniu care trebuie accesat în continuare prin HTTP simplu devine inaccesibil pentru browserele care au primit politica. Victimele tipice sunt uneltele interne, echipamentele de rețea cu certificate autosemnate și vechile microsite-uri de marketing. Cum cele mai multe dintre aceste nume nu apar în inventarul dumneavoastră, problema iese la iveală de regulă la câteva zile după activare.

• Gazde interne precum intranet.example.com, servite prin HTTP în rețeaua din birou.
• Echipamente cu certificate autosemnate, pentru că HSTS elimină opțiunea de a trece peste avertisment.
• Subdomenii găzduite la furnizori (centre de ajutor, pagini de stare) unde nu controlați certificatul.
• Portaluri captive sau API-uri care merg doar pe HTTP, pe subdomenii folosite de clienți vechi.

Antetul este respectat doar pentru gazda care l-a trimis și pentru subdomeniile acesteia. O politică cu includeSubDomains trimisă de www.example.com acoperă *.www.example.com, nu și api.example.com. Pentru a acoperi întregul domeniu, antetul trebuie trimis chiar de example.com, ceea ce înseamnă că utilizatorii trebuie să viziteze măcar o dată domeniul fără subdomeniu sau că domeniul trebuie să fie în lista preload. De aceea contează ca răspunsul de redirecționare să poarte antetul chiar și atunci când domeniul gol doar redirecționează către www.

Lista preload

HSTS protejează un browser abia după prima vizită HTTPS reușită. Lista preload elimină această fereastră de la prima vizită: este o listă de domenii compilată în Chromium și folosită și de Firefox, Safari și Edge, care tratează acele domenii ca fiind sub HSTS de la bun început. Domeniile se trimit prin hstspreload.org, care verifică automat cerințele și respinge cererile incomplete. Chiar și un domeniu acceptat ajunge la utilizatori abia după săptămâni, pentru că lista este distribuită odată cu versiunile noi de browser.

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

Unele domenii de prim nivel sunt incluse în întregime în lista preload, așa că orice domeniu înregistrat sub ele cere HTTPS în browsere încă de la prima vizită. Dacă folosiți un astfel de TLD, comportamentul HSTS este deja în vigoare indiferent de antetul dumneavoastră, iar subdomeniile care merg pe HTTP simplu nu se vor deschide deloc. Trimiteți totuși antetul: propria politică acoperă și browserele vechi care nu aplică regula domeniului de prim nivel.

Redirecționări care funcționează cu HSTS

Un lanț curat de redirecționări contează atât pentru HSTS, cât și pentru preload. Secvența recomandată este: http://example.com → https://example.com (care setează HSTS pentru domeniul fără subdomeniu) → https://www.example.com, dacă folosiți www. O redirecționare directă de la http://example.com la https://www.example.com sare peste răspunsul HTTPS al domeniului gol, așa că acesta nu își trimite niciodată politica.

http://example.com/        301 → https://example.com/
https://example.com/       301 → https://www.example.com/   (with Strict-Transport-Security)
http://www.example.com/    301 → https://www.example.com/
https://www.example.com/   200                               (with Strict-Transport-Security)

Verificatorul de redirecționări urmărește lanțul pornind de la http:// și listează fiecare pas, ceea ce face ușor de confirmat că primul pas rămâne pe aceeași gazdă. Verificați la fiecare pas că apare și antetul; uitarea antetului pe răspunsurile de redirecționare este unul dintre cele mai frecvente motive de respingere a cererilor de preload. Ghidul despre redirecționări acoperă buclele și pașii inutili.

Greșeli frecvente

Ultimul rând apare des în spatele CDN-urilor și al proxy-urilor inverse: aplicația trimite o valoare, iar marginea adaugă alta. Decideți care strat deține antetele de securitate, eliminați-l pe celălalt și confirmați răspunsul final din exterior cu Verificatorul de antete HTTP. Notați pe scurt decizia în depozitul de infrastructură; altfel aceeași pereche de antete revine la următoarea configurare de CDN.

HSTS și mecanismele înrudite

Mai multe funcții recente împing și ele browserele către HTTPS, iar relația lor cu HSTS merită cunoscută. Niciuna nu înlocuiește HSTS pentru un site pe care îl administrați, dar schimbă ce experimentează vizitatorii pe site-urile fără el. Cea mai importantă diferență este cine decide: pe unele le setați dumneavoastră, iar altele țin de preferința din browserul utilizatorului și nu sunt deloc sub controlul dumneavoastră.

HSTS rămâne mecanismul aflat sub controlul dumneavoastră care face erorile de certificat imposibil de ocolit și îi protejează pe vizitatorii care revin, în fiecare browser care îl implementează. Celelalte sunt completări utile, iar upgrade-insecure-requests se potrivește bine cu HSTS mai ales în perioada de curățare a conținutului vechi.

Viața de zi cu zi cu HSTS

HSTS transformă problemele de certificat în întreruperi. Automatizați reînnoirea, monitorizați separat expirarea și testați reînnoirile pe gazdele de staging. Un certificat expirat pe un site fără HSTS afișează doar un avertisment; pe un site cu HSTS, vizitatorii pur și simplu nu mai pot intra.

• Monitorizați expirarea certificatelor pentru fiecare gazdă acoperită de politică, inclusiv subdomeniile.
• Adăugați subdomenii noi doar cu HTTPS din prima zi.
• Păstrați antetul în fiecare răspuns HTTPS, inclusiv în răspunsurile de la marginea CDN-ului.
• Documentați că domeniul folosește HSTS sau este în lista preload, ca echipele viitoare să nu planifice pe el servicii doar pe HTTP.
• Folosiți HSTS împreună cu celelalte antete de securitate; ghidul CSP îl acoperă pe cel mai complex dintre ele.

Organizațiile mari au deseori multe domenii, iar deciziile privind HSTS diferă de la un domeniu la altul. Un domeniu de produs cu o singură aplicație web este un candidat ușor pentru un max-age lung și pentru preload; un domeniu corporativ cu zeci de subdomenii interne poate fi pregătit pentru HSTS doar pe anumite gazde și fără includeSubDomains. Consemnați decizia și motivele ei pentru fiecare domeniu, ca echipa următoare să știe ce este sigur.

Când cumpărați sau moșteniți un domeniu, verificați dacă este deja în lista preload sau dacă trimite HSTS, înainte de a planifica servicii pe el. Verificatorul de antete HTTP arată antetul curent, iar site-ul de preload arată starea din listă. Să descoperiți că domeniul este în lista preload abia după ce ați construit un serviciu doar pe HTTP pe unul dintre subdomeniile lui este o surpriză care putea fi evitată.

Dacă vreodată trebuie să faceți cale întoarsă, trimiteți max-age=0 prin HTTPS. Browserele care îl primesc uită politica pentru acea gazdă. Vizitatorii care nu revin înainte de expirarea valorii max-age stocate păstrează vechea politică până atunci, ceea ce este încă un motiv să creșteți max-age treptat.

Întrebări frecvente

Surse

• RFC 6797: HTTP Strict Transport Security (HSTS)
• Lista preload HSTS: trimitere și cerințe
• MDN: Strict-Transport-Security
• Documentația nginx: add_header