Sådan fungerer HTTPS — TLS-handshaket forklaret

Sådan fungerer HTTPS — TLS-handshaket forklaret

The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.

How to read this visual

• Læs kolonnen »TLS-handshake« oppefra og ned, derefter kolonnen »Sikker session«: forhandling først, kryptering bagefter.
• Banegruppen »Certifikatudsteder« ligger ikke i beskedernes vej — den er den part, hvis tillid browseren bruger til at bedømme serverens certifikat.
• Beslutningen »Er certifikatet gyldigt og ikke udløbet?« er den eneste forgrening: et gyldigt certifikat fortsætter til nøgleudvekslingen, et ugyldigt ender ved blokeringsadvarslen.

Handshaket

»Browseren forbinder til HTTPS-siden« starter forløbet, og »Browseren sender et ClientHello med de understøttede ciphers« fortæller, hvilke protokolversioner og ciphersuiter browseren kan bruge. »Serveren svarer med sit certifikat og et ServerHello« vælger blandt de muligheder og fremviser sin identitet — et certifikat med offentlig nøgle udstedt til domænet. Det certifikat er hele tillidsankeret i HTTPS.

Hvem går god for serveren

»Browseren kontrollerer certifikatets signatur mod CA'en« ligger i gruppen »Certifikatudsteder«, fordi certifikatet er signeret af en CA, og browseren stoler på CA'ens offentlige nøgle. Beslutningen »Er certifikatet gyldigt og ikke udløbet?« tester derefter de tre reelle kontroller på én gang: signaturen, domænenavnet på certifikatet og certifikatets udløb og tilbagekaldelse. »Nej«-grenen ender ved »Browseren blokerer forbindelsen med en advarsel« — browseren vil hellere fejle lukket end indlæse en uverificeret side.

Den krypterede session

Når certifikatet er betroet, er »Browseren sender en pre-master secret krypteret med serverens offentlige nøgle« den ene besked, kun den rigtige server kan dekryptere. Ud fra den forklarer »Begge sider udleder den samme sessionsnøgle«, at de faktiske data slet ikke krypteres med certifikatets nøgler — certifikatet beskytter nøgleudvekslingen, og en frisk symmetrisk nøgle beskytter samtalen. »HTTP-beskederne krypteres med sessionsnøglen« og »Browser og server udveksler krypterede data« er det, HTTPS består i resten af sideindlæsningen.

Key relationships and takeaways

• HTTPS = HTTP båret over en krypteret TLS-session; krypteringen sker, før nogen HTTP-besked sendes.
• Tilliden kommer fra certifikatudstederen, ikke fra serveren: browseren bedømmer serverens certifikat op mod en CA, den allerede stoler på.
• Certifikatets nøgler bruges én gang til at beskytte nøgleudvekslingen; en frisk sessionsnøgle krypterer de faktiske data.
• Et ugyldigt eller ikke-betroet certifikat stopper forbindelsen — HTTPS fejler lukket i stedet for at sende data ukrypteret.
• Alt det, HTTPS beskytter, rejser over det samme pakkekoblede netværk, som forklaringen om internettet tegner.

When to use this visual

• At forklare et team, hvorfor hængelåsen dukker op, og hvad en certifikatadvarsel faktisk betyder.
• At introducere udviklere til handshaket, før de fejlsøger TLS-problemer, udløbne certifikater eller advarsler om blandet indhold.
• At undervise i tillidsmodellen: hvordan CA-hierarkiet og valideringen af certifikater beskytter mod, at nogen udgiver sig for at være en anden.

Sådan fungerer det

1. Skriv jeres faktiske certifikatudsteder på

   Omdøb gruppen »Certifikatudsteder« til jeres udbyder, og notér certifikattypen — DV, OV eller EV — på certifikatboksen.

2. Tilføj den TLS-version, I kører

   Notér på ClientHello-trinnet de protokolversioner og ciphersuiter, I faktisk slår til, så diagrammet afspejler jeres opsætning og ikke en generisk.

3. Tegn jeres fejlgrene

   Tilføj de faktiske udfald, I har set — et udløbet certifikat, et hostnavn, der ikke passer, et tilbagekaldt certifikat — og lad hver af dem ende i den advarsel eller blokering, den giver.

4. Del handshaket op i den detalje, I har brug for

   Underviser du i TLS 1.3, så fold nøgleudvekslingen ud i dens rigtige beskeder (Key Share, Finished); lærredet er dit at udvide, når du har åbnet det.

Ofte stillede spørgsmål

Hvad er forskellen på HTTP og HTTPS?

HTTPS er HTTP, der kører inde i en krypteret TLS-forbindelse. Forespørgslen og svaret er nøjagtig den samme protokol; det, der ændrer sig, er, at browseren og serveren gennemfører et handshake, der etablerer en krypteret session, før nogen HTTP-besked sendes. Alt det, der sendes — URL, headere, cookies, svarets indhold — kan kun læses af de to ender.

Hvad sker der under TLS-handshaket?

Browseren sender et ClientHello med de protokoller og ciphers, den understøtter; serveren svarer med sit valg og sit certifikat; browseren verificerer certifikatet op mod en betroet certifikatudsteder; og de to sider udveksler en hemmelighed, som begge udleder den samme sessionsnøgle af. Derefter løber HTTP-beskederne krypteret. Forklaringen folder udvekslingen sammen til de fire trin.

Hvorfor har browseren brug for en certifikatudsteder?

Fordi en hvilken som helst server kunne udgive sig for at være et hvilket som helst domæne. Certifikatudstederen (CA) er den tredjepart, der signerer serverens certifikat efter at have verificeret, at domænet tilhører ansøgeren. Browseren leveres med de offentlige nøgler fra betroede CA'er og kan derfor selv verificere signaturen — det er det, der gør en selverklæret identitet til en, nogen går god for.

Hvad betyder en certifikatadvarsel?

Den betyder, at en af kontrollerne i beslutningen »Er certifikatet gyldigt og ikke udløbet?« fejlede — certifikatet er udløbet, dækker et andet domæne, er signeret af en CA, der ikke er betroet, eller er blevet tilbagekaldt. Browseren blokerer forbindelsen i stedet for at fortsætte, fordi sidens identitet ikke kan verificeres.

Redigér dette diagram i QueryChart (FlowJam)

Åbn præcis det lærred med TLS-handshaket, du ser ovenfor, som dit eget diagram, notér de ciphers, I understøtter, og tilpas det til jeres egen certifikatopsætning.

Redigér dette diagram i QueryChart (FlowJam)