Hur man gör HTTPS till den första förfrågan genom ett VPN

En webbläsare som skriver http:// först och landar på https:// efter att en omdirigering redan har skickat en begäran i klartext, och ett VPN ändrar inte på det. Tunneln skyddar benet från klienten till utgångsnoden; den krypterar inte något ovanför transportlagret, så en observatör mellan utgången och ursprunget ser fortfarande klartexthoppet. Att göra HTTPS till den första begäran är en ändring på klientsidan med tre delar: en riktig HTTPS-adress, webbläsarens uppgraderingsläge och webbplatsens egen policy. Stegen nedan är beställningen jag använder, var och en med kontrollen som talar om för dig om det tog.

Steg 1: bekräfta vad den första begäran faktiskt är

Innan du ändrar något, titta på vad webbläsaren skickar. Öppna nätverkspanelen med sidan laddad om från en kall cache och läs den första raden: om schemat är http och statusen är 301 eller 308, är allt efter den raden en andra begäran. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com återger samma sekvens utanför webbläsaren och skriver ut webbadressen du hamnade på.

Två resultat är möjliga och de behöver olika korrigeringar. Om webbplatsen serverar HTTPS på samma värd är korrigeringen att sluta publicera HTTP-formuläret: uppdatera bokmärket, wikilänken, skrivbordsgenvägen och e-postmallen som folk klickar på. Om webbplatsen inte serverar HTTPS alls, kommer ingen webbläsarinställning att skapa den, och det ärliga svaret är att destinationen är problemet. Skriv inte över det andra fallet med ett undantag, eftersom ett certifikatundantag på en kontosida omvandlar ett transportproblem till ett referensproblem. Skriv ner vilket fall du är i innan du trycker på en inställning.

Steg 2: aktivera webbläsarens endast HTTPS-läge

Uppgraderingsläget är den andra delen, och lägena är inte utbytbara. Kontrollera vad din gör innan du aktiverar den: uppgradera tyst, uppgradera med en varning eller vägra att ladda.

I Firefox finns kontrollerna bakom about:config och på sidan med sekretessinställningar, med dom.security.https_only_mode som växel och undantag per plats hanteras från hänglåsmenyn. I Chrome och Edge finns samma idé under Inställningar, Sekretess och säkerhet, Säkerhet, märkt Använd alltid säkra anslutningar. Oavsett etikett, verifiera beteendet mot en värd som bara svarar på port 80, eftersom ett läge som uppgraderar och sedan tyst faller tillbaka inte är det skydd du tror att du aktiverat. Firefox HTTPS-Only-dokumentationen beskriver uppgraderingen, varningen och undantagsbeteendet för den webbläsaren.

Steg 3: fixa resurserna, inte bara adressfältet

När en uppgradering misslyckas, läs det exakta felet istället för adressfältet. En värd utan HTTPS-lyssnare, ett värdnamn som inte matchar certifikatet och en utgången kedja producerar olika meddelanden och tillhör olika ägare. Endast den första är en lucka på serversidan; den andra är vanligtvis ett bokmärke som aldrig uppdaterades; det tredje är ett förnyelseproblem som VPN-anslutningen är irrelevant för.

Lägg inte till ett certifikatundantag på en kontowebbplats eftersom VPN är på. Undantaget inaktiverar kontrollen som skulle ha fångat exakt den avlyssning som ett VPN är tänkt att förhindra.

Den tredje delen finns inne på sidan, och det är den som folk saknar. En sida som laddas över HTTPS kan fortfarande hämta bilder, typsnitt eller skript från en http-URL, och webbläsaren kommer antingen att blockera dem eller nedgradera säkerhetsindikatorn för hela sidan. Inspektera de misslyckade förfrågningarna i nätverkspanelen och fixa resursreferenserna hos deras ägare istället för att anta att adressfältet beskriver varje begäran. På en sida du kör innebär det att du korrigerar de lagrade webbadresserna i CMS eller mallen istället för att skriva om dem i webbläsaren. Om du inte kan ändra källan, spela in det blandade innehållet som ett känt gap, eftersom ett hänglås över en sida som drar klartextresurser är en falsk signal.

Steg 4: vad HSTS lägger till och vad det inte gör

HSTS är en webbplatspolicy snarare än en webbläsarinställning, och det är den enda mekanismen här som överlever en inskriven http:// på en ny profil. När en webbläsare har sett ett Strict-Transport-Security-huvud för en värd, skriver den om senare förfrågningar till https innan de skickas, vilket är exakt den egenskap du vill ha. Det gör ingenting för en värd som webbläsaren aldrig har besökt, och ingenting för ett annat värdnamn som betjänar samma applikation.

Kontrollera vad ursprunget skickar med curl -sSI https://example.com | grep -i strict-transport-security. En saknad header är en serverändring och inte något som en klient kan installera. Om den finns, läs max-age och om includeSubDomains är inställd, eftersom en kort maxålder löper ut mellan besöken och en saknad includeSubDomains lämnar varje underdomän oskyddad. RFC 6797 definierar hur en användaragent tillämpar policyn och vad den får ignorera. Förladdning är ett separat åtagande, så kontrollera status via hstspreload.org API innan du lovar någon att en domän finns på listan.

Verifiering och återställning

Återställning är billigt för klientinställningarna och dyrt för HSTS. Om du stänger av endast HTTPS-läget återställs det tidigare beteendet omedelbart; en lång maxålder gör det inte, och besökare som redan fått den fortsätter att uppgradera tills den går ut.

Så verifiera i ordning innan du kallar det klart. Ladda om från en kall cache och bekräfta att den första begäran i nätverkspanelen är https utan föregående omdirigering. Kontrollera sedan en underdomän, eftersom includeSubDomains är där dessa policyer vanligtvis visar sig vara smalare än vad som antas. Kontrollera sedan en sida som hämtar tillgångar från tredje part, eftersom blandat innehåll är felet som överlever varannan fix.

Om den första begäran fortfarande är http efter allt detta, är klienten inte längre variabeln: länken som folk klickar på är. Sök på platserna du kontrollerar efter http-formen för värdnamnet, uppdatera dem och testa igen med samma omladdning av kall cache. Håll VPN-frågan separat genomgående, eftersom tunneln ändrar vem som kan se begäran och ändrar aldrig om begäran är krypterad. Raden att lägga i biljetten är att den första förfrågan är den som är viktig, och en omdirigering är bara ett kvitto på en förfrågan som redan har skickats.