Nätverk och protokoll

HTTPS

HTTP skiktad ovanpå TLS för att tillhandahålla kryptering och autentisering under överföring.

Var du ser detta: Syns i paketfångster, nätverksdiagram, brandväggsregler samt system- och nätverksloggar.

Vad det är

HTTPS betyder HTTP över TLS. Webbläsaren upprättar först en TLS-session med servern och skickar sedan normala HTTP-förfrågningar inuti den krypterade tunneln. Till applikationen ser det fortfarande ut som HTTP.

Nyckelpunkter
  • Lägger till konfidentialitet och integritet till webbtrafik på opålitliga nätverk.
  • Beror på korrekt certifikatvalidering och värdnamnskontroller.
  • Gör inte en sårbar webbapp säker, den skyddar bara data under överföring.

Hur det fungerar i stora drag

  1. Klienten löser värdnamnet och öppnar sedan en anslutning till serverns HTTPS-port.
  2. En TLS handskakning inträffar: servern presenterar ett certifikat, klienten validerar det och värdnamnet, och båda sidor härleder delade nycklar.
  3. När handskakningen är klar krypteras alla HTTP byte i TLS-poster.
  4. Klienten skickar en HTTP-förfrågan och får ett HTTP-svar, precis som med HTTP, men mellanhänder kan inte läsa eller ändra nyttolasten utan att avsluta TLS.
  5. Moderna inställningar förhandlar fram protokollversioner som HTTP/2 med ALPN under handskakningen TLS.
  6. Anslutningar kan återanvändas och sessioner kan återupptas för att påskynda senare besök.
  7. Säkerhetsrubriker som HSTS kan tvinga framtida anslutningar att använda HTTPS och minska nedgraderingsrisken.

Konkret exempel

På offentlig WiFi kan en angripare läsa och ändra HTTP-trafik. Med HTTPS ser angriparen fortfarande att du anslutit till en banks IP, men kan inte läsa dina lösenord eller byta sidinnehåll utan att utlösa certifikatfel.

Varför det är viktigt

Vanlig HTTP exponerar allt för nätverket, inklusive cookies och referenser, och tillåter aktiva angripare att ändra svar. HTTPS finns för att göra webben säker att använda på delade nätverk och på det offentliga internet.

Säkerhetsperspektiv

  • Säkerheten för HTTPS vilar på certifikatutfärdande och validering. Automatisera förnyelser och övervaka felutfärdade certifikat.
  • Använd moderna TLS-konfigurationer och inaktivera äldre versioner där det är möjligt.
  • Om du avslutar TLS, skydda det interna nätverket också. Annars skapar du en okrypterad lucka i din miljö.

Vanliga fallgropar

  • Behandla certifikatvarningar som ignorerbara. De indikerar ofta avlyssning eller felkonfiguration.
  • Blandat innehåll: att ladda några resurser över HTTP motverkar säkerhetslöftet.
  • TLS uppsägning vid en lastbalanserare kan dölja den verkliga klienten IP och ändra förtroendegränser.
  • Förutsatt att kryptering döljer metadata. DNS, IP adresser, och ibland kan SNI fortfarande avslöja var du ansluter.
  • Att tro att HTTPS ersätter applikationssäkerhet. Det förhindrar inte XSS, SQL-injektion eller trasig autentiseringslogik.

FÖRDJUPNING

Hela stacken: namn till innehåll

När du laddar en HTTPS-webbplats samarbetar flera lager. Först mappar DNS värdnamnet till en IP-adress. Sedan upprättar klienten en TCP-anslutning till servern, vanligtvis till port 443. Därefter körs TLS-handskakningen för att autentisera servern och härleda krypteringsnycklar. Först efter att TLS har upprättats skickar klienten förfrågan om HTTP.

Denna skiktning är anledningen till att du kan diagnostisera fel stegvis. Ett DNS-fel betyder att du aldrig fick ett IP. Ett TCP-fel betyder att du inte kunde nå värden och porten. Ett TLS-fel betyder att serveridentiteten eller den kryptografiska förhandlingen misslyckades. Ett HTTP-fel betyder att den säkra kanalen finns men programmet returnerade ett fel eller oväntat innehåll.

I paketfångst ser HTTPS ut som en TLS-handskakning följt av krypterad applikationsdata. Du kan vanligtvis se servernamnet via SNI under handskakningen, men du kan inte se webbadresser, rubriker eller kroppar efter att krypteringen har börjat.

Serverautentisering och certifikatvalidering

Den definierande egenskapen för HTTPS är autentisering. Webbläsaren krypterar inte bara. Den kontrollerar att servercertifikatet matchar värdnamnet i URL:en och kedjor till en betrodd rotcertifikatutfärdare. Om dessa kontroller misslyckas varnar webbläsaren dig eftersom enbart kryptering utan identitet inte skulle stoppa människor i mitten av attacker.

Certifikatkedjor är vanliga felpunkter. En server måste presentera rätt mellancertifikat. Certifikatet får inte löpa ut eller återkallas av policy. Värdnamnet måste matcha, inklusive underdomänregler. Felkonfigurationer här kan göra att en webbplats fungerar i en webbläsare men misslyckas i en annan beroende på trust butiksdetaljer.

Moderna distributioner använder också funktioner som OCSP-häftning, loggar för certifikattransparens och automatisk förnyelse. Dessa minskar risken för tysta kompromisser, men de lägger till rörliga delar som kan gå sönder om de inte övervakas.

Webbläsarsäkerhetspolicyer som kör på HTTPS

När en webbplats är HTTPS möjliggör webbläsare starkare skydd. Säkra cookies kan markeras så att de bara skickas över HTTPS. Regler för blandat innehåll blockerar eller varnar när en HTTPS-sida försöker ladda skript över vanligt HTTP eftersom det skulle återinföra manipuleringsrisker.

HSTS är en annan nyckelpolicy. Den säger åt webbläsaren att alltid använda HTTPS för en domän, även om användaren skriver HTTP. Detta förhindrar nedgraderingsattacker där en angripare försöker hålla dig på en osäker version av webbplatsen.

Ur säkerhetsteknisk synvinkel är HTTPS baslinjen. Många moderna webb APIs och funktioner är begränsade till säkra sammanhang, vilket i huvudsak är en synonym för att visas över HTTPS.

Prestanda i den verkliga världen

HTTPS ökar handskakningskostnaden, men moderna TLS har minskat den. TLS 1.3 slutförs vanligtvis på en tur och retur, och ett återupptagande av sessionen kan minska antalet återkommande besök ytterligare. Återanvändning av anslutning innebär att kostnaden skrivs av på många förfrågningar.

CDN:er avslutar ofta TLS vid kanten, vilket förkortar sökvägen och förbättrar latensen. Den säkra anslutningen från din webbläsare slutar vid CDN, och CDN ansluter sedan till ursprunget med sina egna säkerhetsinställningar. Detta är fortfarande säkert, men det ändras var certifikaten finns och där loggar och kontroller gäller.

Om en webbplats känns långsam, mät om fördröjningen är i DNS, TCP, TLS eller serverns svar. Många människor skyller på TLS för långsamhet när det verkliga problemet är serverns bearbetningstid eller ett överbelastat nätverk.