HTTP Strict Transport Security eller HSTS (på italiensk rigid sikkerhet for transport av HTTP ) er en prosedyre som implementerer en sikkerhetspolicy for nettkommunikasjon , nødvendig for å beskytte HTTPS -kanalen mot sikkerhetsdegraderingsangrep ( nedgradering ) og svært nyttig for beskyttelse mot øktkapring. HSTS lar webserveren erklære at nettlesere og enhver annen type klient må kommunisere med den utelukkende gjennom sikre tilkoblinger på HTTPS- protokollen og ikke på enkel HTTP[1] . Prosedyren er en IETF Internett-standard , regulert av RFC 6797.
HSTS-policyen [2] indikeres av serveren til brukeragenten ved å spesifisere en bestemt overskrift i HTTP - svarmeldingene , kalt " Strict-Transport-Security" som spesifiserer tidsperioden som klienten må få tilgang til serveren i en nødvendigvis sikker modus.
HSTS er legemliggjørelsen av ett aspekt av Jeff Hodges og Andy Steingruebls designvisjon for å forbedre nettsikkerhet, og presentert i 2010 i deres artikkel fra 2010 med tittelen The Need for Coherent Web Security Policy Framework (s) . [3]
HSTS-spesifikasjonen er basert på Jackson og Barths originale bidrag beskrevet i ForceHTTPS-artikkelen: Protecting High-Security Web Sites from Network Attacks . [4]
Det første originale utkastet til spesifikasjonen ble skrevet av PayPals Jeff Hodges [ 5 ] , Collin Jackson [6] og Adam Barth [7] og publisert 18. september 2009. [8]
Den første spesifikasjonen av HSTS ble offentliggjort 18. desember 2009 og tilsvarte den siste såkalte «community-versjonen», som hadde godt av offentlig tilbakemelding. [9]
Etter godkjenning av IESG 2. oktober 2012 ble HSTS-spesifikasjonen publisert som en RFC Proposed Standard 19. november 2012 i RFC 6797 [10] . Den første originalversjonen av dokumentet ble imidlertid allerede arkivert 17. juni 2010 som Internet-Draft , da tittelen på spesifikasjonen ble endret fra "Strict Transport Security" (STS) til den mer presise "HTTP Strict Transport". Sikkerhet". [11] Likevel har HTTP-headeren definert av spesifikasjonen beholdt navnet "Strict-Transport-Security".
En server implementerer HSTS-policyen hvis den utsteder overskriften i en HTTPS-kommunikasjonsmelding (over HTTP ignoreres disse overskriftene i stedet). [12] For eksempel kan en server sende en header som ber om at hver forespørsel adressert til den i det påfølgende året nødvendigvis må sendes over HTTPS. I dette tilfellet, siden maks-alder- parameteren er uttrykt i sekunder og 31 536 000 sekunder er en god tilnærming til et år, vil overskriften være:
Strict-Transport-Security: max-age=31536000; includeSubDomains;.Når en nettapplikasjon [13] erklærer en HSTS-policy til brukeragenter , oppfører klientene som støtter mekanismen seg som beskrevet nedenfor. [2]
HSTS-policyen bidrar til å beskytte nettapplikasjonsbrukere fra visse passive ( avlytting ) eller aktive angrep: [14] i et mann-i-midten-angrep er det mye vanskeligere å avskjære spørsmål og svar mellom brukeren og applikasjonsnettet når førstnevnte er i HSTS-modus sammenlignet med sistnevnte.
Den viktigste sikkerhetssårbarheten som kan unngås av HSTS er den såkalte man-in-the-middle med SSL-stripping- teknikken , offentlig illustrert for første gang i 2009 av Moxie Marlinspike i sin tale " New Tricks For Defeating SSL I praksis » (Ta i bruk nye triks for å beseire SSL) presentert på BlackHat Federal . [15] [16] Dette angrepet består i å stille om å konvertere en sikker HTTP-tilkobling, støttet av SSL eller TLS , til en klar HTTP-tilkobling: brukeren kan bekrefte at tilkoblingen faktisk ikke er sikker, men han har ingen måte å vite at den bør være. Gitt at flere nettsteder ikke bruker TLS / SSL, er det faktisk ingen måte å forstå, hvis man ikke kjenner på forhånd det spesifikke nettstedet, om usikkerheten til forbindelsen er effekten av et angrep, eller om det er vanlig oppførsel . nettapplikasjon. Videre genererer ikke sikkerhetsregresjonsprosessen noen advarselsmeldinger til brukeren, noe som gjør angrepet diskret i øynene til nesten hvem som helst. Marlinspikes sslstrip-verktøy automatiserer et slikt angrep fullstendig.
HSTS håndterer dette problemet [14] ved å informere nettleseren om at dens tilkoblinger til nettstedet alltid bør bruke TLS / SSL. Siden HSTS-overskriften fortsatt kan tukles med av en angriper ved første besøk av en bruker, prøver Google Chrome , Mozilla Firefox , Internet Explorer og Microsoft Edge å begrense problemet ved å sette inn en foreløpig liste over HSTS-nettsteder. [17] [18] [19] I neste avsnitt Limits vil vi også diskutere hvordan denne løsningen nødvendigvis er utilstrekkelig, gitt at listen ovenfor ikke kan være uttømmende.
HSTS bidrar også til å forhindre tyveri av påloggingsinformasjon til HTTP-informasjonskapselbaserte nettsteder , et angrep som er mulig med lett tilgjengelige verktøy, for eksempel Firesheep . [20]
Siden HSTS har tidsbegrensninger, er protokollen følsom for angrep som innebærer å flytte offerets klokke, for eksempel ved å sende falske NTP -pakker . [21]
I møte med aktive angrep, er tilstedeværelsen av HSTS ikke i stand til å beskytte den første forespørselen til en nettapplikasjon, når den formidles på en usikker protokoll som HTTP i klartekst eller når den relative URI er innhentet på en usikker kanal ... [22] Det samme gjelder den første forespørselen som fremsettes etter utløpet av perioden spesifisert av parameteren max-ageannonsert i HSTS-policyen. Nettsteder bør derfor angi en varighet på flere dager eller flere måneder, avhengig av brukeraktivitet og atferd. Nettleserne Google Chrome , Mozilla Firefox og Internet Explorer / Microsoft Edge adresserer denne protokollbegrensningen ved å implementere en "STS foreløpig liste": en liste over kjente nettsteder som støtter HSTS [17] [18] [19] som distribueres direkte til inne i nettleseren og som får den til å bruke HTTPS også for den første forespørselen. Men, som tidligere nevnt, kan ikke denne listen liste alle nettsteder på Internett. En mulig løsning kan oppnås ved å bruke DNS -poster for å deklarere HSTS-policyen og få tilgang til denne informasjonen med DNSSEC -protokollen , eventuelt ved å bruke sertifikatfingeravtrykk for å sikre deres gyldighet, noe som igjen krever en DNS-oppløsningsklient for å verifisere dette. sist for å unngå problemer i den siste milen med forbindelse . [23]
Selv når den er utstyrt med den "foreløpige STS-listen", er ikke HSTS-mekanismen i alle tilfeller i stand til å beskytte mot angrep som involverer samme sikkerhetsnivå som TLS, som for eksempel BEAST eller CRIME designet av Juliano Rizzo og Thai Duong: vedlikehold av HSTS-policy er irrelevant og irrelevant i møte med denne typen angrep.
For en mer omfattende diskusjon av HSTS-sikkerhet, se RFC 6797 . [24]
Avhengig av den spesifikke implementeringen, lar visse gode fremgangsmåter deg unngå visse sikkerhetstrusler, for eksempel angrep på injeksjon av informasjonskapsler.