Wat is een TLS-handdruk? | phoenixNAP IT-woordenlijst

Een TLS-handshake (Transport Layer Security) zorgt voor gecodeerde en geauthenticeerde communicatie tussen een client (zoals een webbrowser) en een serverBij de handdruk worden berichten uitgewisseld en worden afspraken gemaakt over cryptografische algoritmen, het verifiëren van de serveridentiteit van de ' (en eventueel die van de cliënt) en het genereren van gedeelde geheime sleutels om volgende te versleutelen gegevensoverdrachtHet vormt de basis voor veilige gegevensuitwisseling en zorgt ervoor dat de verzonden informatie vertrouwelijk en fraudebestendig blijft.

Wat betekent TLS-handshake?

Een TLS-handshake is een reeks stappen die een beveiligde verbinding initieert door de betrokken partijen te valideren, compatibele beveiligingsparameters te selecteren en gedeelde encryptiesleutels te maken. De handshake bepaalt hoe de gegevens worden gecodeerd, verifieert de server's digitale certificaat en stelt het beveiligde kanaal in dat nodig is om data-integriteit en vertrouwelijkheid. Het is een essentieel onderdeel van TLS, een protocol dat is ontworpen om privacy en data security via netwerken.

Wat zijn de componenten van een TLS-handshake?

Hieronder staan de belangrijkste componenten die een TLS-handshake mogelijk maken.

Klant en Server

Bij de handdruk zijn twee hoofdentiteiten betrokken: de cliënt, die de verbinding initieert (bijvoorbeeld een web browser of andere toepassing), en de server, die de resource of service host waartoe de client toegang wil hebben. De client start de handshake door verschillende parameters voor te stellen encryptie en authenticatieEn server reageert met de gekozen opties op basis van ondersteunde configuraties.

Cijfer Suites

Een cipher suite is een verzameling cryptografische algoritmen die worden gebruikt tijdens de handshake en daaropvolgende gegevensoverdrachten. Het omvat het sleuteluitwisselingsalgoritme, de bulkversleutelingscipher, het berichtauthenticatiecodealgoritme en soms het digitale handtekeningalgoritme. De client suggereert een lijst met cipher suites die het ondersteunt en de server selecteert er een die hij herkent en acceptabel acht.

Certificeringen

Certificaten zijn digitale documenten die worden gebruikt om de identiteit van een communicerende partij te bevestigen. In de meeste TLS-verbindingen is de server presenteert een X.509-certificaat, dat is uitgegeven door een vertrouwde certificaat autoriteit (CA). Dit certificaat bindt de server's domein naam aan een openbare sleutel. De client verifieert de certificaatketen om te garanderen dat er niet mee is geknoeid en dat deze is uitgegeven door een legitieme CA.

Openbare en privésleutels

Publieke en privésleutels zijn integraal aan TLS. server bevat een privésleutel die overeenkomt met de openbare sleutel die in het certificaat staat. Tijdens de handshake nemen deze sleutels deel aan asymmetrische cryptografische bewerkingen. Clients gebruiken de openbare sleutel in de server certificaat om een stukje data te versleutelen (zoals het pre-master secret), en alleen de serverDe privésleutel van kan decoderen het.

Sessiesleutels

Zodra de klant en server het eens worden over een set cryptografische parameters, genereren ze symmetrische sessie sleutels. Deze sleutels versleutelen en ontsleutelen berichten tijdens de dataoverdrachtsfase, wat zowel vertrouwelijkheid als prestatievoordelen oplevert. Symmetrische encryptiealgoritmen zijn doorgaans veel sneller dan asymmetrische, wat de reden is dat de handshake asymmetrische methoden gebruikt voor authenticatie en sleuteluitwisseling, en vervolgens terugvalt op symmetrische methoden voor bulkdata-encryptie.

Hoe werkt TLS-handshake?

De TLS-handshake verloopt doorgaans in verschillende stappen die zorgen voor een veilig en geauthenticeerd kanaal. Elke fase heeft een gedefinieerd doel en bestaat uit berichtenuitwisselingen die de encryptieparameters finaliseren en de authenticiteit van de server en eventueel de klant.

KlantHallo

De klant begint de handdruk door een ClientHello-bericht te sturen naar de server. Dit bericht bevat de volgende informatie:

Een lijst met ondersteunde cipher suites en TLS-versies.
Een willekeurige waarde (client-random) die later bij het genereren van de sleutel wordt gebruikt.
ondersteunde samendrukking methoden (hoewel compressie grotendeels is verouderd in recente TLS-versies).

ServerHallo

Het server reageert met een ServerHallo bericht. Dit antwoord bevat:

De geselecteerde TLS-versie.
De gekozen cipher suite uit het voorstel van de klant.
Een andere willekeurige waarde (server willekeurig).

Certificaat- en sleuteluitwisseling

Het server stuurt zijn certificaat, dat de server's publieke sleutel samen met de certificaatketen. Daarna de server kan aanvullende sleuteluitwisselingsparameters verzenden als de gekozen cipher suite dit vereist (bijvoorbeeld in Diffie-Hellman of Elliptic Curve Diffie-Hellman-cijfers).

De klant verifieert de server's-certificaat, waarbij wordt gecontroleerd of het geldig is, niet verlopen is en is ondertekend door een vertrouwde CA.

Clientverificatie en Pre-Master Secret

Nadat de klant de server's certificaat genereert het een pre-mastergeheim en versleutelt het met behulp van de server's publieke sleutel. Dit gecodeerde pre-master geheim wordt vervolgens naar de server.

Het server gebruikt zijn privésleutel om het pre-mastergeheim te decoderen, en beide partijen leiden sessiesleutels af van het pre-mastergeheim, de client random en de server willekeurig.

Handshake-finalisatie

Zowel de klant als server “Finished”-berichten naar elkaar sturen, die gecodeerd zijn met de nieuw afgeleide sessiesleutels. Deze berichten verifiëren dat de overeengekomen sleutels correct functioneren en dat er geen manipulatie heeft plaatsgevonden.

Zodra deze berichten succesvol zijn uitgewisseld en geverifieerd, is de handshake voltooid en worden de daaropvolgende communicaties gecodeerd met behulp van de sessiesleutels.

Wanneer vindt een TLS-handshake plaats?

Een TLS-handshake vindt plaats wanneer een client een nieuwe beveiligde verbinding met een server via TLS. Veelvoorkomende scenario's zijn:

Toegang tot een website via HTTPS (HTTP via TLS).
initiëren beveiligde e-mail communicatie (zoals SMTPS, IMAPS of POP3S).
Verbinding maken met beveiligde applicaties die afhankelijk zijn van TLS voor encryptie (bijvoorbeeld VPN-tunnels of veilig filet overdrachten).

De handshake wordt herhaald als er een nieuwe sessie tot stand wordt gebracht of als er een TLS-heronderhandeling wordt geactiveerd om de cryptografische sleutels voor langlopende verbindingen te vernieuwen.

TLS-handshakevoorbeeld

Hieronder vindt u een overzicht van hoe een typische HTTPS-handshake (HTTP over TLS) verloopt tussen een client en een server.

Stap 1: Beveiligde pagina met klantverzoeken

De webbrowser van een gebruiker start een beveiligde verbinding door een ClientHello-bericht naar de server op “example.com.” Het ClientHello-bericht is onderdeel van het TLS Handshake Protocol en bevat verschillende belangrijke stukjes informatie:

Ondersteunde protocolversie(s)De klant stelt een of meer versies van TLS voor (bijv. TLS 1.2, TLS 1.3) die hij kan gebruiken.
Klant willekeurig. Een 32-byte willekeurige waarde gegenereerd door de client, die later wordt gebruikt bij het afleiden van de sleutel.
Sessie-ID of sessieticketAls de client onlangs verbinding heeft gemaakt met hetzelfde server en over een geldig sessieticket of sessie-ID beschikt, kan deze de mogelijkheid bieden om de sessie te hervatten. Hierdoor kunnen bepaalde handshake-stappen worden overgeslagen of ingekort.
Cipher-suites. Deze suites zijn een lijst met cryptografische algoritmen die de client ondersteunt. Elke cipher suite specificeert een sleuteluitwisselingsmechanisme (bijv. RSA, ECDHE), een encryptiealgoritme (bijv. AES) en een berichtauthenticatiecode of authenticatietagalgoritme (bijv. SHA256).
uitbreidingenModerne TLS-implementaties omvatten verschillende extensies zoals server naam aanduiding (SNI), wat aangeeft dat hostname de client probeert te bereiken. Extra extensies kunnen wijzen op ondersteunde elliptische curven, handtekeningalgoritmen en andere parameters die de beveiliging of prestaties verbeteren.

Bij ontvangst van deze ClientHallo, server onderzoekt de voorgestelde cipher suites en TLS-versies om te bepalen of het een van deze ondersteunt. De TLS-handshake gaat alleen door als de server vindt ten minste één compatibele set parameters.

Stap 2: Server Reageert

Na het verwerken van ClientHello, de server antwoordt met een ServerHallo bericht. Er zijn verschillende belangrijke elementen opgenomen:

Gekozen protocolversie. De server selecteert één versie van TLS (bijv. TLS 1.2) die zowel door de client als door de server Ondersteunen.
Server willekeurige. Een andere willekeurige waarde van 32 bytes gegenereerd door de server, gebruikt met de client random om gedeelde sleutels af te leiden.
Cipher suite-selectie. Uit de lijst van de klant, de server kiest een enkele cipher suite die het ondersteunt. Het kan bijvoorbeeld een ECDHE_RSA sleuteluitwisseling, AES_128_GCM encryptie en SHA256 voor berichtauthenticatie kiezen.
Sessie-ID of nieuw sessieticket. Indien de server Ondersteunt het hervatten van sessies; het kan de voorgestelde sessie-ID van de client accepteren of een nieuwe verstrekken.
uitbreidingen. De server bevat relevante uitbreidingsreacties, met vermelding van eventuele specifieke parameters of beperkingen.

Naar aanleiding van de ServerHallo server stuurt doorgaans extra handshake-berichten:

Certificaat. De server verzendt zijn certificaatketen, die zijn eindentiteitscertificaat (het eigenlijke certificaat) bevat server certificaat) en eventuele tussenliggende certificaten die nodig zijn om het te koppelen aan een rootcertificeringsinstantie (CA).
Server sleuteluitwisseling. Afhankelijk van de gekozen cipher suite, de server biedt sleuteluitwisselingsparameters (bijvoorbeeld de tijdelijke openbare Diffie-Hellman-sleutel) die de client zal gebruiken om een gedeeld geheim te genereren.
Certificaataanvraag (optioneel). Indien de server vereist clientauthenticatie, vraagt het in deze fase om een clientcertificaat. Dit komt minder vaak voor bij normaal web browsen, maar komt vaker voor in omgevingen die wederzijdse TLS nodig hebben.

Stap 3: Certificaatvalidatie

De klant onderzoekt de server's certificaat om te garanderen dat de verbinding daadwerkelijk met de beoogde host is en niet met een bedrieger:

CertificaatketenverificatieDe klant controleert of de server's certificaat wordt uitgegeven en ondertekend door een vertrouwde CA. De browser of besturingssysteem onderhoudt een opslag van vertrouwde rootcertificaten. De browser controleert ook tussenliggende certificaten om een geldige vertrouwensketen te vormen tot aan een erkende root-CA.
Vervaldatum en geldigheidDe klant controleert de datums 'Niet voor' en 'Niet na' van het certificaat om te bevestigen dat het certificaat momenteel geldig is.
Domeinnaam matchingDe klant bevestigt dat de domeinnaam die in het certificaat staat (meestal te vinden in het veld Subject Alternative Name) overeenkomt met 'example.com' of het aangevraagde domein.
HerroepingscontroleDe client kan de certificaatintrekkingslijst (CRL) of het online certificaatstatusprotocol (OCSP) gebruiken om te zien of het certificaat of een tussenliggend certificaat is ingetrokken.

Als een onderdeel van het validatieproces mislukt, bijvoorbeeld vanwege een ongeldige handtekening, een verlopen certificaat of een domeinnaam die niet overeenkomt, verbreekt de client doorgaans de verbinding of toont hij een waarschuwing aan de gebruiker.

Stap 4: Sleuteluitwisseling en generatie van sessiesleutels

Zodra de klant de serverNadat de client het certificaat van de 's heeft ontvangen (en indien gevraagd eventueel een eigen certificaat heeft verzonden), gaat de client verder met de sleuteluitwisseling:

Sleuteluitwisseling van de klantAls er gebruik wordt gemaakt van een RSA-sleuteluitwisseling, genereert de client een pre-master geheim en versleutelt het met de serveropenbare sleutel (verkregen van de server certificaat). Als er een ECDHE- of DHE-cijfersuite wordt gebruikt, verstrekt de client ook zijn eigen tijdelijke openbare sleutel voor Diffie-Hellman-berekeningen.
Decodering of gedeelde sleutelberekening. De server decodeert het pre-mastergeheim met zijn privésleutel of, in het geval van Diffie-Hellman/ECDHE, combineert hij de geheimen van de client en serveropenbare sleutels van om een gedeeld geheim te berekenen.
Meestergeheim afleidingMet behulp van het pre-mastergeheim (of DH-gedeelde geheim) kunnen de client en server beide leiden een hoofdgeheim af. Deze afleiding omvat ook de client random en server willekeurig. Pseudorandomfuncties (zoals die in TLS 1.2 of de “Handshake Secret” in TLS 1.3) worden gebruikt om sterke cryptografische willekeur te garanderen.
Sessiesleutel aanmakenVanuit het hoofdgeheim, de cliënt en server genereer afzonderlijke symmetrische sleutels voor het versleutelen van uitgaande gegevens, het ontsleutelen van inkomende gegevens en het verifiëren van de integriteit van berichten. Deze sessiesleutels worden doorgaans onderhandeld om ephemeral te zijn (met name in ECDHE-gebaseerde ciphers), wat voorwaartse geheimhouding.

Stap 5: Veilige gegevensoverdracht

Nadat beide partijen de sessiesleutels hebben afgeleid, kunnen de cliënt en server uitwisseling Geëindigd berichten:

Afgeronde berichten. Elke kant berekent een cryptografische hash van alle tot nu toe verzonden handshake-berichten (het handshake-transcript) en versleutelt deze met de nieuw vastgestelde sessiesleutels. Deze 'Finished'-berichten verifiëren dat beide partijen dezelfde handshake-status delen en dat er geen manipulatie heeft plaatsgevonden.
Bevestiging van handdruk. De klant en server bevestigen ontvangst van elkaars Finished-bericht. Als de hashes overeenkomen, geeft dit aan dat de handshake succesvol en veilig is voltooid.
Versleutelde applicatiegegevens. Vervolggegevens, zoals HTML bestanden, afbeeldingen of andere inhoud van de applicatielaag—wordt gecodeerd met de overeengekomen symmetrische sleutel. De codering zorgt voor vertrouwelijkheid, terwijl de cryptografische hachee of MAC (afhankelijk van de cipher suite) zorgt voor integriteit.
Verbindingspersistentie en sessiehervatting. Als een van beide partijen TLS-sessiehervatting ondersteunt, kunnen ze het onderhandelde master secret hergebruiken voor een toekomstige verbinding. Dit vermindert de overhead van het opnieuw uitvoeren van een volledige handshake.

Zodra de handshake-fase is voltooid, worden de browser en server communiceren via een beveiligd kanaal. Browsers tonen doorgaans een slotpictogram of een vergelijkbare indicator in de adresbalk om aan te geven dat de verbinding is gecodeerd en geverifieerd met behulp van TLS.

Waarom zijn TLS-handshakes belangrijk?

Een TLS-handshake biedt een methode voor het tot stand brengen van veilige communicatie in netwerken die gevoelig zijn voor afluisteren of manipulatie.

Een succesvolle handdruk brengt verschillende voordelen met zich mee:

authenticatieDe klant is verzekerd van de serveridentiteit van 's, voorkomen man-in-the-middle-aanvallen.
VertrouwelijkheidAl het verkeer dat volgt op de handshake wordt gecodeerd, zodat onbevoegden de gegevens niet kunnen lezen.
Data-integriteitBerichtauthenticatie zorgt ervoor dat verzonden gegevens tijdens de overdracht niet zijn gewijzigd.

Het handshakeproces creëert, door gebruik te maken van cryptografische algoritmen en certificaten, een robuuste vertrouwenslaag die informatie tijdens de overdracht beschermt.

Wat als een TLS-handshake mislukt?

Een mislukte TLS-handshake resulteert in het onvermogen om een veilige verbinding te maken. De verbinding wordt vaak beëindigd en gebruikers kunnen foutmeldingen tegenkomen zoals "SSL / TLS handshake mislukt” of “Kan geen beveiligde verbinding tot stand brengen.”

Er is sprake van een mislukking als problemen zoals incompatibele TLS-versies, ongeldige certificaten, verlopen certificaten of onjuiste systeemklokken een succesvolle onderhandeling verhinderen.

Hoe herstel ik een TLS-handshake?

Systeembeheerders en eindgebruikers kunnen handshake-fouten oplossen door de grondoorzaken aan te pakken:

Geldige certificaten bijwerken of installeren. U moet verlopen of ongeldige certificaten vervangen. Hostingproviders en beheerders moeten ervoor zorgen dat certificaten worden ondertekend door vertrouwde CA's en up-to-date blijven.
Controleer de configuratie en ondersteunde protocollen. Ervoor zorgen dat zowel de klant als server dezelfde TLS-versies en cipher suites ondersteunen is cruciaal. Het uitschakelen van oude protocollen zoals SSLv3 of TLS 1.0 elimineert bekende kwetsbaarheden en voorkomt handshake-fouten die verband houden met verouderde encryptiemethoden.
Synchroniseer systeemklokken. Nauwkeurige systeemklokken zijn belangrijk voor het valideren van de verval- en geldigheidstijden van certificaten. A server of een client met een verkeerde tijdsinstelling kan anderszins geldige certificaten weigeren.
Verifieer CA-truststores. Het besturingssysteem of de applicatie van de client houdt een lijst bij van vertrouwde CA's. Verifiëren dat de relevante root- of tussenliggende CA aanwezig is en niet is ingetrokken, helpt handshakefouten te voorkomen.
Inspecteren server configuratie. Verkeerd geconfigureerd servers (bijvoorbeeld onjuiste cipher suite-prioriteiten of onvolledige certificaatketens) leiden vaak tot handshake-problemen. server Met behulp van logboeken en configuraties kunt u de mismatch opsporen en snel oplossen.

Wat is het verschil tussen SSL- en TLS-handshake?

De term “SSL-handshake” verwijst naar het handshake-proces dat wordt gebruikt door de beveiligde sockets layer (SSL) protocol, dat een eerdere standaard was voor het versleutelen en beveiligen van gegevens. De TLS-handshake is de moderne evolutie van SSL, die sterkere beveiligingsmaatregelen en bijgewerkte cryptografische algoritmen biedt.

Hoewel de workflows vergelijkbaar zijn, introduceerde TLS verbeteringen ten opzichte van SSL, waaronder verbeterde cipher suites, betere certificaatafhandeling en robuustere cryptografische mechanismen. SSL is verouderd vanwege bekende kwetsbaarheden en de meeste moderne systemen gebruiken TLS voor veilige communicatie.

In veel referenties wordt nog steeds "SSL" gebruikt om de veilige handshake te beschrijven, zelfs wanneer TLS onder de motorkap wordt gebruikt, maar de nauwkeurigere term in huidige implementaties is "TLS-handshake". Het kernprincipe blijft hetzelfde: een handshake-proces onderhandelt over beveiligingsparameters, wisselt certificaten uit en stelt gedeelde sleutels vast voor gecodeerde communicatie.