En nettleser som skriver inn http:// først og lander på https:// etter at en omdirigering allerede har sendt én forespørsel i klartekst, og en VPN endrer ikke på det. Tunnelen beskytter benet fra klienten til utgangsnoden; den krypterer ikke noe over transportlaget, så en observatør mellom utgangen og origo ser fortsatt klarteksthoppet. Å gjøre HTTPS til den første forespørselen er en endring på klientsiden med tre deler: en ekte HTTPS-adresse, nettleserens oppgraderingsmodus og nettstedets egen policy. Trinnene nedenfor er rekkefølgen jeg bruker, hver med sjekken som forteller deg om det tok.

Trinn 1: Bekreft hva den første forespørselen faktisk er

Før du endrer noe, se på hva nettleseren sender. Åpne nettverkspanelet med siden lastet på nytt fra en kald cache og les den første raden: hvis skjemaet er http og statusen er 301 eller 308, er alt etter den raden en andre forespørsel. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com gjengir den samme sekvensen utenfor nettleseren og skriver ut URL-en du havnet på.

To utfall er mulige, og de trenger forskjellige rettelser. Hvis nettstedet betjener HTTPS på samme vert, er løsningen å slutte å publisere HTTP-skjemaet: oppdater bokmerket, wiki-lenken, snarveien på skrivebordet og e-postmalen folk klikker på. Hvis nettstedet ikke betjener HTTPS i det hele tatt, vil ingen nettleserinnstillinger opprette det, og det ærlige svaret er at destinasjonen er problemet. Ikke skriv over den andre saken med unntak, fordi et sertifikatunntak på en kontoside konverterer et transportproblem til et legitimasjonsproblem. Skriv ned hvilken sak du er i før du trykker på en innstilling.

Trinn 2: Slå på nettleserens bare HTTPS-modus

Oppgraderingsmodusen er den andre delen, og modusene kan ikke byttes ut. Sjekk hva din gjør før du aktiverer den: oppgrader stille, oppgrader med en advarsel, eller nekt å laste.

I Firefox ligger kontrollene bak about:config og på siden for personverninnstillinger, med dom.security.https_only_mode som bryter og unntak per nettsted administrert fra hengelåsmenyen. I Chrome og Edge er den samme ideen under Innstillinger, Personvern og sikkerhet, Sikkerhet, merket Bruk alltid sikre tilkoblinger. Uansett etikett, verifiser oppførselen mot en vert som bare svarer på port 80, fordi en modus som oppgraderer og deretter stille faller tilbake ikke er beskyttelsen du tror du har aktivert. Firefox HTTPS-Only-dokumentasjonen spesifiserer oppgraderingen, advarselen og unntaksatferden for den nettleseren.

Trinn 3: fiks ressursene, ikke bare adressefeltet

Når en oppgradering mislykkes, les den nøyaktige feilen i stedet for adressefeltet. En vert uten HTTPS-lytter, et vertsnavn som ikke samsvarer med sertifikatet og en utløpt kjede produserer forskjellige meldinger og tilhører forskjellige eiere. Bare den første er et gap på serversiden; den andre er vanligvis et bokmerke som aldri ble oppdatert; den tredje er et fornyelsesproblem som VPN-tilkoblingen er irrelevant for.

Ikke legg til et sertifikatunntak på et kontonettsted fordi VPN er på. Unntaket deaktiverer sjekken som ville ha fanget opp nøyaktig den avlyttingen en VPN er ment å forhindre.

Den tredje delen er inne på siden, og det er den folk savner. En side som lastes over HTTPS kan fortsatt trekke bilder, fonter eller skript fra en http URL, og nettleseren vil enten blokkere dem eller nedgradere sikkerhetsindikatoren for hele siden. Inspiser de mislykkede forespørslene i nettverkspanelet og fiks ressursreferansene hos eieren i stedet for å anta at adresselinjen beskriver hver forespørsel. På et nettsted du kjører, betyr det å korrigere de lagrede URL-ene i CMS eller malen i stedet for å omskrive dem i nettleseren. Hvis du ikke kan endre kilden, ta opp det blandede innholdet som et kjent gap, fordi en hengelås over en side som henter rentekstressurser er et falskt signal.

Trinn 4: hva HSTS legger til, og hva det ikke gjør

HSTS er en nettstedspolicy i stedet for en nettleserpreferanse, og det er den eneste mekanismen her som overlever en skrevet http:// på en ny profil. Når en nettleser har sett en Strict-Transport-Security-overskrift for en vert, omskriver den senere forespørsler til https før den sender dem, som er akkurat den egenskapen du ønsker. Det gjør ingenting for en vert nettleseren aldri har besøkt, og ingenting for et annet vertsnavn som betjener samme applikasjon.

Sjekk hva opprinnelsen sender med curl -sSI https://example.com | grep -i strict-transport-security. En manglende overskrift er en serverendring og ikke noe en klient kan installere. Hvis den er tilstede, les max-age og om includeSubDomains er satt, fordi en kort maks-alder utløper mellom besøk og et manglende includeSubDomains lar hvert underdomene være ubeskyttet. RFC 6797 definerer hvordan en brukeragent bruker policyen og hva den kan ignorere. Forhåndsinnlasting er en egen forpliktelse, så sjekk status gjennom hstspreload.org API før du lover noen at et domene er på listen.

Bekreftelse og tilbakeføring

Rulling er billig for klientinnstillingene og dyrt for HSTS. Hvis du slår av kun HTTPS-modus, gjenopprettes forrige virkemåte umiddelbart; en lang maksalder gjør det ikke, og besøkende som allerede har mottatt den fortsetter å oppgradere til den utløper.

Så bekreft i rekkefølge før du kaller det ferdig. Last inn på nytt fra en kald cache og bekreft at den første forespørselen i nettverkspanelet er https uten noen foregående omdirigering. Sjekk deretter et underdomene, fordi includeSubDomains er der disse retningslinjene vanligvis viser seg å være smalere enn antatt. Sjekk deretter én side som henter tredjepartsressurser, siden blandet innhold er feilen som overlever annenhver reparasjon.

Hvis den første forespørselen fortsatt er http etter alt dette, er ikke klienten lenger variabelen: koblingen folk klikker på er. Søk på stedene du kontrollerer etter http-formen til vertsnavnet, oppdater dem og test på nytt med den samme kald-cache-innlastingen. Hold VPN-spørsmålet atskilt hele veien, fordi tunnelen endrer hvem som kan se forespørselen og endrer aldri om forespørselen er kryptert. Linjen for å sette inn billetten er at den første forespørselen er den som betyr noe, og en omdirigering er bare en kvittering for en allerede sendt forespørsel.

Relaterte artikler