Kako postaviti HSTS bez zaključavanja samih sebe

HSTS je jednostavan dok ne prestane biti

HTTP Strict Transport Security, obično skraćeno HSTS, govori preglednicima: „za ovu web-lokaciju uvijek koristi HTTPS.” Nakon što preglednik primi zaglavlje preko valjane HTTPS veze, pamti pravilo tijekom razdoblja koje odredite.

To je korisno. Sprječava napade spuštanjem protokola, smanjuje slučajne nesigurne zahtjeve i izbjegava neugodan trenutak u kojem korisnik upiše example.com i nakratko dotakne obični HTTP prije preusmjeravanja.

Također je ljepljiv. Ako objavite pogrešnu HSTS politiku, preglednici je mogu nastaviti provoditi dugo nakon što uklonite zaglavlje sa svog poslužitelja. Tako se timovi zaključaju: ne baš iz vlastite administratorske ploče, nego iz korisničkih preglednika, poddomena, staging sustava, naslijeđenih krajnjih točaka i zaboravljenih servisa koji nisu spremni za prisilni HTTPS.

Cilj nije izbjegavati HSTS. Cilj je implementirati ga kao migraciju, a ne kao prekidač.

Što HSTS zaglavlje zapravo radi

Tipično HSTS zaglavlje izgleda ovako:

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

Ima tri važna dijela:

• max-age: koliko dugo, u sekundama, preglednik treba provoditi HTTPS za ovaj host.
• includeSubDomains: primjenjuje li se pravilo i na svaku poddomenu.
• preload: signal da želite uključiti domenu na popise za preload u preglednicima.

Preglednik vjeruje ovom zaglavlju samo kada ga primi preko valjanog HTTPS-a. Ako je certifikat nevaljan, istekao ili se ne podudara, preglednik ne bi trebao prihvatiti novu HSTS politiku iz tog odgovora.

Nakon što je politika pohranjena, budući pokušaji posjeta http://example.com preglednik nadograđuje na https://example.com prije slanja zahtjeva. To je dobitak za privatnost: nesigurni zahtjev nikada ne napušta uređaj.

Scenariji zaključavanja koje treba izbjeći

Većina HSTS kvarova nije uzrokovana glavnom web-lokacijom. Događaju se na rubovima.

1. Zaboravljena poddomena nije spremna za HTTPS

includeSubDomains zvuči uredno, ali je apsolutan. Ako ga postavite na example.com, primjenjuje se na:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• sve ostalo pod tom domenom

Ako bilo koji od tih hostova ne može posluživati valjani HTTPS, korisnici s predmemoriranom HSTS politikom neće im moći pristupiti preko HTTP-a.

2. Certifikat istekne

Bez HSTS-a, korisnici ponekad kliknu kroz upozorenja o certifikatu. To nije dobra sigurnosna praksa, ali se događa.

S HSTS-om moderni preglednici ne dopuštaju jednostavno zaobilaženje pogrešaka certifikata za taj host. To je i poanta. To također znači da obnova certifikata mora biti dosadna, nadzirana i testirana.

3. Staging ili interni alati nalaze se pod produkcijskom domenom

Smještanje internih alata pod *.example.com može postati bolno nakon što nadređena domena počne koristiti includeSubDomains. Ako ti alati koriste samopotpisane certifikate, privatna certifikacijska tijela, stare TLS konfiguracije ili uopće nemaju HTTPS, HSTS će razotkriti prečac.

To je jedan od razloga zašto mnogi timovi drže interne i eksperimentalne sustave pod zasebnom domenom koja ima vlastitu sigurnosnu politiku.

4. Preload se tretira kao rutinska kućica za označavanje

HSTS preload nije samo još jedna direktiva. To znači da vaša domena može biti isporučena unutar preglednika kao isključivo HTTPS prije nego što je bilo koji korisnik posjetio vašu web-lokaciju.

Time se zatvara praznina „prvog posjeta”, ali je mnogo teže poništiti. Uklanjanje s preload popisa može potrajati tjednima ili mjesecima dok ne dođe do korisnika, ovisno o ciklusima izdanja preglednika. Preload je prikladan za stabilne, zrele domene. Nije prikladan za web-lokaciju koja još uvijek otkriva svoj inventar poddomena.

Siguran plan uvođenja

Korak 1: Provjerite svaki hostname koji kontrolirate

Prije postavljanja includeSubDomains, popišite svaki hostname pod domenom. DNS zapisi su početak, ali ne i cijela priča. Provjerite CDN konfiguracije, hosting nadzorne ploče, hostnameove povezane s e-poštom, stare marketinške alate, spremnike za pohranu i internu dokumentaciju.

Za svaki hostname odgovorite:

• Poslužuje li HTTP, HTTPS ili oboje?
• Je li HTTPS certifikat valjan i automatski se obnavlja?
• Preusmjerava li HTTP na HTTPS uredno?
• Treba li biti javan?
• Je li još potreban?

Ako vaš tim već ima navike debugiranja produkcijskih zaglavlja, ovo se prirodno uklapa uz provjere preusmjeravanja i zaglavlja. Taj smo tijek rada obradili u malom skupu alata za debugiranje preusmjeravanja i HTTP zaglavlja u produkciji.

Korak 2: Popravite HTTPS prije dodavanja HSTS-a

HSTS ne čini pokvarenu HTTPS konfiguraciju sigurnom. Samo čini HTTPS obveznim.

Prije nego što ga omogućite, provjerite:

• TLS certifikati pokrivaju ispravne hostnameove.
• Certifikati se automatski obnavljaju.
• HTTP preusmjerava na HTTPS jednim čistim skokom gdje je to moguće.
• Preusmjeravanja kanonskog hosta dosljedna su, primjerice s ne-www na www, ili obrnuto.
• Aplikacijski resursi ne ovise o nesigurnim http:// URL-ovima.

Miješani sadržaj rjeđi je nego prije, ali se i dalje pojavljuje u starim CMS temama, analitičkim isječcima, ugrađenim medijima i tvrdo kodiranim putanjama do slika.

Korak 3: Počnite s vrlo kratkim max-age

Nemojte početi s jednom godinom. Počnite s pet minuta:

Strict-Transport-Security: max-age=300

Primijenite to samo na hostname koji testirate, obično na kanonsku produkcijsku web-lokaciju. Zasad izostavite includeSubDomains.

Zatim testirajte u stvarnim preglednicima i naredbenim zahtjevima:

curl -I https://example.com

Trebali biste vidjeti točno jedno Strict-Transport-Security zaglavlje. Duplicirana HSTS zaglavlja iz aplikacijskog poslužitelja i CDN-a čest su izvor zabune. Preglednici uglavnom primjenjuju efektivnu politiku, ali ljudi koji debugiraju incident ne trebaju dvosmislenost.

Korak 4: Postupno povećavajte

Ako se ništa ne pokvari, povećavajte trajanje u fazama:

Strict-Transport-Security: max-age=86400

Zatim:

Strict-Transport-Security: max-age=604800

Zatim možda:

Strict-Transport-Security: max-age=2592000

Praktičan raspored je:

• 5 minuta
• 1 dan
• 1 tjedan
• 1 mjesec
• 6 mjeseci ili 1 godina

Nema nagrade za žurbu. Cijela poanta postupnog uvođenja jest dati vašem nadzoru, sandučiću podrške i rubnim slučajevima dovoljno vremena da vam pokažu što je kontrolni popis propustio.

Korak 5: Dodajte includeSubDomains tek nakon stvarne provjere

Kada je svaka javna poddomena spremna za HTTPS, možete razmotriti:

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

Ovo je trenutak za konzervativnost. Ako jedna naslijeđena usluga još treba HTTP, nemojte dodavati includeSubDomains na nadređenu domenu. Ili migrirajte tu uslugu, premjestite je na drugu domenu ili prihvatite da vaša HSTS politika zasad mora ostati uža.

Sigurnosna zaglavlja trebaju odražavati stvarnost. Ne bi se trebala koristiti kao motivacijski plakati za infrastrukturu za koju se nadate da ćete je imati kasnije.

Korak 6: Tretirajte preload kao zaseban projekt

Razmotrite preload samo kada vrijedi sve sljedeće:

• Domena i sve poddomene podržavaju valjani HTTPS.
• HTTP preusmjerava na HTTPS.
• HSTS zaglavlje koristi max-age od najmanje 31536000 sekundi.
• Zaglavlje uključuje includeSubDomains.
• Zaglavlje uključuje preload.
• Sigurni ste da vam nigdje pod domenom neće trebati obični HTTP.

Zaglavlje spremno za preload izgleda ovako:

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

Slanje na preload popis dugoročna je obveza. Ako je web-lokacija kampanjski microsite, privremena domena proizvoda ili domena s nejasnim granicama vlasništva, preskočite to.

Primjeri konfiguracije

Nginx

Koristite always kako bi se zaglavlje slalo i na odgovorima s pogreškama:

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

Nakon što je uvođenje stabilno:

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

Apache

S omogućenim mod_headers:

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

Kasnije:

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

CDN ili edge platforma

Ako vaš CDN postavlja zaglavlja odgovora, radije upravljajte HSTS-om na jednom mjestu. Nemojte postavljati jednu politiku na izvoru, a drugu na rubu, osim ako za to nemate vrlo jasan razlog.

Također provjerite primjenjuje li CDN zaglavlja na preusmjeravanja, predmemorirane pogreške i prilagođene stranice pogrešaka. Produkcijska web-lokacija nije samo njezin odgovor 200 OK.

Kako sigurno poništiti HSTS

Ako trebate onemogućiti HSTS, pošaljite:

Strict-Transport-Security: max-age=0

Ali postoji kvaka: preglednik mora uspješno doći do web-lokacije preko valjanog HTTPS-a kako bi primio to zaglavlje. Ako je sam HTTPS pokvaren, korisnici s predmemoriranom HSTS politikom ne mogu dohvatiti uputu koja bi je očistila.

Zato je uobičajen redoslijed oporavka:

1. Vratite valjani HTTPS.
2. Poslužite Strict-Transport-Security: max-age=0.
3. Držite ga dovoljno dugo da ga povratni korisnici prime.
4. Uklonite ili zamijenite zaglavlje nakon što je incident riješen.

Ako je domena na preload popisu, posluživanje max-age=0 nije dovoljno za nove profile preglednika. Također morate zatražiti uklanjanje s preload popisa i pričekati da se ta promjena isporuči kroz ažuriranja preglednika.

Kontrolni popis za testiranje prije isporuke

Upotrijebite ovaj kontrolni popis prije povećanja max-age ili dodavanja includeSubDomains:

• Kanonski HTTPS URL vraća valjani certifikat.
• HTTP preusmjerava na HTTPS.
• Postoji samo jedno HSTS zaglavlje.
• Zaglavlje se pojavljuje na preusmjeravanjima i odgovorima s pogreškama gdje je prikladno.
• Sve javne poddomene imaju valjani HTTPS.
• Obnova certifikata se nadzire.
• Nijedan kritični interni sustav ne ovisi o HTTP-u pod istom nadređenom domenom.
• O preloadu se izričito razgovaralo, nije dodan iz navike.

Lighthouse u nekim kontekstima također može označiti nedostajuća ili slaba sigurnosna zaglavlja, ali ne bi trebao biti vaša jedina metoda provjere. Ako ga koristite kao dio šire revizije, čitajte nalaze kao signale, a ne kao presude; isti pristup vrijedi kada čitate Lighthouse izvješće bez panike.

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

💡 Isprobajte ovo: Prije i nakon svake HSTS promjene provjerite Strict-Transport-Security odgovor pomoću Get Headers kako biste potvrdili da su max-age, includeSubDomains i preload onakvi kakve očekujete.

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

Argument za privatnost HSTS-a

HSTS se često opisuje kao sigurnosno zaglavlje, i to jest. Ima i korist za privatnost: smanjuje mogućnost da prvi korisnikov zahtjev procuri preko običnog HTTP-a na nepouzdanoj mreži.

To je važno na Wi-Fi mrežama u zračnim lukama, hotelskim mrežama, korporativnim mrežama za goste i svugdje gdje bi se korisnikov promet mogao promatrati ili mijenjati. Obični HTTP zahtjev može otkriti hostname, putanju, kolačiće bez oznake Secure i druge detalje zahtjeva. HTTPS nije magija, ali njegovo dosljedno nametanje uklanja cijelu klasu izbježnog curenja.

Najbolje HSTS implementacije su nezanimljive. Uvode se polako, poduprte su pouzdanim certifikatima i dovoljno su dosadne da ih nitko ne primijeti. To je upravo ono što želite od zaglavlja čiji način kvara može biti dramatičan.