TLS-protocol. Zorg ervoor dat de ssl- en tls-protocollen zijn ingeschakeld

Hoofdstukken uit het prachtige boek “High Performance Browser Networking” van Ilya Grigorik. De vertaling werd uitgevoerd als onderdeel van het schrijven van een cursuswerk en is daarom zeer gratis, maar zal niettemin nuttig zijn voor degenen die weinig idee hebben wat TLS is en waarvoor het wordt gebruikt.

TLS begrijpen

Nadat het SSL-protocol was gestandaardiseerd door de IETF (Internet Engineering Task Force), werd het omgedoopt tot TLS. Hoewel de namen SSL en TLS door elkaar worden gebruikt, zijn ze dus nog steeds verschillend omdat ze elk een andere versie van het protocol beschrijven.

De eerste vrijgegeven versie van het protocol heette SSL 2.0, maar werd vanwege ontdekte kwetsbaarheden snel vervangen door SSL 3.0. Zoals gezegd is SSL ontwikkeld door Netscape, dus in januari 1999 standaardiseerde de IETF het openlijk onder de naam TLS 1.0. Vervolgens werd in april 2006 TLS 1.1 gepubliceerd, waarmee de oorspronkelijke mogelijkheden van het protocol werden uitgebreid en bekende kwetsbaarheden werden gedicht. De huidige versie van het protocol is momenteel TLS 1.2, uitgebracht in augustus 2008.

Zoals gezegd is TLS ontworpen om via TCP te werken, maar om met datagramprotocollen zoals UDP (User Datagram Protocol) te werken, is er een speciale versie van TLS ontwikkeld genaamd DTLS (Datagram Transport Layer Security).
 

Encryptie, authenticatie en integriteit

• Encryptie – het verbergen van informatie die van de ene computer naar de andere wordt verzonden;
• Authenticatie – controle van het auteurschap van verzonden informatie;
• Integriteit – detectie van informatievervanging door valse informatie.

Als onderdeel van de TLS Handshake-procedure is het ook mogelijk om de identiteit van zowel de client als de server te authenticeren. Zo kan een cliënt er zeker van zijn dat de server die hem de bankrekeninggegevens verstrekt inderdaad een bankserver is. En omgekeerd: de server van het bedrijf kan er zeker van zijn dat de client die er verbinding mee maakt een medewerker van het bedrijf is, en niet een derde partij (dit mechanisme wordt Chain of Trust genoemd en zal in de betreffende sectie worden besproken).

Ten slotte zorgt TLS ervoor dat elk bericht wordt verzonden met een MAC-code (Message Authentication Code), waarvan het aanmaakalgoritme een cryptografische hashfunctie in één richting is (eigenlijk een checksum), waarvan de sleutels bekend zijn bij beide deelnemers aan de communicatie. . Elke keer dat een bericht wordt verzonden, wordt de MAC-waarde gegenereerd, die ook door de ontvanger kan worden gegenereerd. Dit waarborgt de integriteit van de informatie en bescherming tegen vervanging.

Daarom worden alle drie de mechanismen die ten grondslag liggen aan de cryptobeveiliging van het TLS-protocol kort besproken.
 

TLS-handdruk

Laten we elke stap van deze procedure eens nader bekijken:

1. Omdat TLS bovenop TCP werkt, wordt eerst een TCP-verbinding tot stand gebracht tussen de client en de server.
2. Na het installeren van TCP stuurt de client de specificatie in platte tekst (namelijk de protocolversie die hij wil gebruiken, ondersteunde versleutelingsmethoden, enz.) naar de server.
3. De server keurt de versie van het gebruikte protocol goed, selecteert een encryptiemethode uit de aangeboden lijst, voegt zijn certificaat toe en stuurt een antwoord naar de client (desgewenst kan de server ook een clientcertificaat aanvragen).
4. De protocolversie en de coderingsmethode worden op dit punt als goedgekeurd beschouwd, de client controleert het verzonden certificaat en initieert RSA- of Diffie-Hellman-sleuteluitwisseling, afhankelijk van de ingestelde parameters.
5. De server verwerkt het door de client verzonden bericht, controleert de MAC en stuurt het laatste (‘Finished’) bericht versleuteld naar de client.
6. De client decodeert het ontvangen bericht, controleert de MAC en als alles in orde is, wordt de verbinding als tot stand gebracht beschouwd en begint de uitwisseling van applicatiegegevens.

Er is ook een extra uitbreiding op de Handshake-procedure genaamd TLS False Start. Met deze uitbreiding kunnen de client en de server beginnen met het uitwisselen van gecodeerde gegevens zodra de coderingsmethode tot stand is gebracht, waardoor het tot stand brengen van verbindingen met één berichtiteratie wordt verminderd. Dit wordt in meer detail besproken in de paragraaf “TLS False Start”.
 

Sleuteluitwisseling in het TLS-protocol

Momenteel geven alle browsers bij het tot stand brengen van een TLS-verbinding de voorkeur aan een combinatie van het Diffie-Hellman-algoritme en het gebruik van tijdelijke sleutels om de veiligheid van de verbinding te vergroten.

Er moet nogmaals worden opgemerkt dat codering met openbare sleutels alleen wordt gebruikt in de TLS Handshake-procedure tijdens de eerste verbindingsconfiguratie. Na het opzetten van de tunnel komt symmetrische cryptografie in beeld en wordt de communicatie binnen de huidige sessie gecodeerd met de gevestigde symmetrische sleutels. Dit is nodig om de prestaties te verbeteren, aangezien cryptografie met publieke sleutels aanzienlijk meer rekenkracht vereist.
 

Een TLS-sessie hervatten

Sinds de eerste openbare versie van het protocol (SSL 2.0) kan de server een sessie-ID van 32 bytes genereren en verzenden als onderdeel van een TLS Handshake (namelijk het initiële ServerHello-bericht). In dit geval slaat de server uiteraard een cache op met gegenereerde identificatiegegevens en sessieparameters voor elke client. Op zijn beurt slaat de client de verzonden identificatie op en neemt deze op (uiteraard als deze bestaat) in het initiële ClientHello-bericht. Als zowel de client als de server identieke sessie-ID's hebben, vindt het tot stand brengen van een gemeenschappelijke verbinding plaats volgens het vereenvoudigde algoritme dat in de afbeelding wordt weergegeven. Zo niet, dan is de volledige versie van TLS Handshake vereist.

Met de procedure voor het hervatten van de sessie kunt u de fase van het genereren van een symmetrische sleutel overslaan, waardoor de tijd voor het opzetten van de verbinding aanzienlijk wordt verlengd, maar de veiligheid niet wordt aangetast, omdat voorheen ongecompromitteerde gegevens uit de vorige sessie worden gebruikt.

Er is echter een praktische beperking: aangezien de server gegevens over alle open sessies moet opslaan, leidt dit tot een probleem met populaire bronnen die tegelijkertijd door duizenden of miljoenen clients worden opgevraagd.

Om dit probleem te omzeilen, is het ‘Session Ticket’-mechanisme ontwikkeld, waardoor het niet meer nodig is om de gegevens van elke client op de server op te slaan. Als de client bij het initieel opzetten van een verbinding heeft aangegeven deze technologie te ondersteunen, dan stuurt de client tijdens TLS Handshake het zogenaamde Session Ticket - sessieparameters versleuteld met de private sleutel van de server - naar de server. De volgende keer dat de sessie wordt hervat, stuurt de klant zijn bestaande sessieticket samen met ClientHello. Dit elimineert de noodzaak voor de server om gegevens over elke verbinding op te slaan, maar de verbinding is nog steeds veilig omdat het sessieticket is gecodeerd met een sleutel die alleen bekend is bij de server.
 

TLS valse start

Om nog betere prestaties te verkrijgen is de TLS False Start-technologie ontwikkeld, een optionele uitbreiding van het protocol waarmee gegevens kunnen worden verzonden wanneer de TLS Handshake slechts gedeeltelijk is voltooid. Het gedetailleerde TLS False Start-schema wordt weergegeven in de afbeelding:

Het is belangrijk op te merken dat TLS False Start de TLS Handshake-procedure op geen enkele manier verandert. Het is gebaseerd op de veronderstelling dat op het moment dat de client en server al op de hoogte zijn van de verbindingsparameters en symmetrische sleutels, applicatiegegevens al kunnen worden verzonden en alle noodzakelijke controles parallel kunnen worden uitgevoerd. Als gevolg hiervan is de verbinding één iteratie van berichten eerder klaar voor gebruik.
 

TLS Vertrouwensketen

1. Zowel Alice als Bob genereren hun eigen publieke en private sleutels.
2. Alice en Bob wisselen openbare sleutels uit.
3. Alice genereert een bericht, codeert het met haar privésleutel en stuurt het naar Bob.
4. Bob gebruikt de van Alice ontvangen sleutel om het bericht te ontsleutelen en verifieert zo de authenticiteit van het ontvangen bericht.

Laat Alice nu een bericht ontvangen van Charlie, die ze niet kent, maar die beweert bevriend te zijn met Bob. Om dit te bewijzen heeft Charlie vooraf gevraagd om zijn eigen openbare sleutel te ondertekenen met de privésleutel van Bob, en voegt deze handtekening toe aan het bericht aan Alice. Alice controleert eerst de handtekening van Bob op de sleutel van Charlie (ze kan dit doen omdat ze de openbare sleutel van Bob al kent), zorgt ervoor dat Charlie echt de vriend van Bob is, accepteert zijn bericht en voert de reeds bekende integriteitscontrole uit, waarbij ze ervoor zorgt dat het bericht is echt van Charlie:

Wat in de vorige paragraaf is beschreven, is het creëren van een “chain of trust” (of “Chain of trust”, in het Engels).
In het TLS-protocol zijn deze vertrouwensketens gebaseerd op echtheidscertificaten die worden verstrekt door speciale autoriteiten, de zogenaamde certificaatautoriteiten (CA). Certificeringsinstanties voeren controles uit en als het uitgegeven certificaat gecompromitteerd is, wordt het certificaat ingetrokken.

De reeds besproken vertrouwensketen wordt gevormd door de uitgegeven certificaten. De root is het zogenaamde “Root CA-certificaat” - een certificaat ondertekend door een groot centrum, waarvan de geloofwaardigheid onmiskenbaar is. Over het algemeen ziet de vertrouwensketen er ongeveer zo uit:

Uiteraard doen zich gevallen voor waarin een reeds uitgegeven certificaat moet worden ingetrokken of ingetrokken (de private sleutel van een certificaat is bijvoorbeeld gecompromitteerd, of de hele certificeringsprocedure is gecompromitteerd). Om dit te bereiken bevatten echtheidscertificaten speciale instructies om ervoor te zorgen dat ze actueel zijn. Daarom is het bij het opbouwen van een vertrouwensketen noodzakelijk om de relevantie van elk vertrouwensknooppunt te controleren.

Het mechanisme van deze controle is eenvoudig en is gebaseerd op de zogenaamde. “Certificaatintrekkingslijst” (CRL – “Certificaatintrekkingslijst”). Elk van de certificeringsinstanties houdt deze lijst bij. Dit is een eenvoudige lijst met serienummers van ingetrokken certificaten. Iedereen die de authenticiteit van een certificaat wil verifiëren, downloadt dus eenvoudigweg deze lijst en zoekt daarin naar het nummer van het certificaat dat wordt geverifieerd. Als het nummer wordt gevonden, betekent dit dat het certificaat is ingetrokken.

Er is hier uiteraard sprake van enige technische inefficiëntie: om slechts één certificaat te controleren, moet u de hele lijst met intrekkingscertificaten opvragen, wat het werk vertraagt. Om dit tegen te gaan, is een mechanisme ontwikkeld genaamd Online Certificate Status Protocol (OCSP). Hiermee kunt u de certificaatstatus dynamisch controleren. Dit vermindert uiteraard de belasting van de netwerkbandbreedte, maar veroorzaakt tegelijkertijd verschillende problemen:

• CA's moeten de belasting in realtime afhandelen;
• CA's moeten hun beschikbaarheid te allen tijde garanderen;
• Dankzij realtime zoekopdrachten ontvangen certificeringsinstanties informatie over welke sites elke specifieke gebruiker heeft bezocht.

Daarom bespreekt dit artikel alle belangrijke functies van het TLS-protocol voor het beschermen van informatie. Mijn excuses voor enkele grappen in het artikel; dit zijn de kosten van het oorspronkelijke doel van het uitvoeren van de vertaling.

TLS en SSL worden de laatste tijd steeds vaker genoemd, het gebruik van digitale certificaten is relevanter geworden en er zijn zelfs bedrijven verschenen die klaar staan ​​om iedereen gratis digitale certificaten te verstrekken om ervoor te zorgen dat het verkeer tussen bezochte sites en de browser van de klant gecodeerd is. Uiteraard is dit nodig voor de veiligheid, zodat niemand op het netwerk de gegevens kan ontvangen die van de client naar de server en terug worden verzonden. Hoe werkt dit allemaal en hoe gebruik je het? Om dit te begrijpen moeten we misschien beginnen met de theorie en dit vervolgens in de praktijk laten zien. Dus SSL en TLS.

Wat is SSL en wat is TLS?

SSL - Secure Socket Layer, een laag beveiligde sockets. TLS - Transport Layer Security, transportlaagbeveiliging. SSL is een eerder systeem, TLS kwam later en is gebaseerd op de SSL 3.0-specificatie ontwikkeld door Netscape Communications. Deze protocollen hebben echter één taak: een veilige gegevensoverdracht tussen twee computers op internet garanderen. Deze overdracht wordt gebruikt voor verschillende websites, voor e-mail, voor berichtenuitwisseling en nog veel meer. In principe kunt u op deze manier alle informatie doorgeven; daarover hieronder meer.

Een veilige overdracht wordt verzekerd door authenticatie en encryptie van de verzonden informatie. In wezen werken deze protocollen, TLS en SSL, hetzelfde; er zijn geen fundamentele verschillen. TLS kan worden beschouwd als de opvolger van SSL, hoewel ze tegelijkertijd kunnen worden gebruikt, zelfs op dezelfde server. Dergelijke ondersteuning is nodig om te kunnen werken met zowel nieuwe clients (apparaten en browsers) als oudere clients die TLS niet ondersteunen. De volgorde waarin deze protocollen voorkomen, ziet er als volgt uit:

SSL 1.0 - nooit gepubliceerd
SSL 2.0 - februari 1995
SSL 3.0 - 1996
TLS 1.0 - januari 1999
TLS 1.1 - april 2006
TLS 1.2 - augustus 2008

Hoe SSL en TLS werken

Het werkingsprincipe van SSL en TLS is, zoals ik al zei, hetzelfde. Bovenop het TCP/IP-protocol wordt een gecodeerd kanaal tot stand gebracht, waarbinnen gegevens worden overgedragen via het applicatieprotocol - HTTP, FTP, enzovoort. Hier ziet u hoe het grafisch kan worden weergegeven:

Het applicatieprotocol is “verpakt” in TLS/SSL, dat op zijn beurt is verpakt in TCP/IP. In wezen worden applicatieprotocolgegevens verzonden via TCP/IP, maar deze zijn gecodeerd. En alleen de machine die de verbinding tot stand heeft gebracht, kan de verzonden gegevens decoderen. Voor alle anderen die de verzonden pakketten ontvangen, zal deze informatie betekenisloos zijn als ze deze niet kunnen ontsleutelen.

De verbinding wordt in verschillende fasen tot stand gebracht:

1) De client brengt een verbinding met de server tot stand en vraagt ​​om een ​​beveiligde verbinding. Dit kan worden bereikt door een verbinding tot stand te brengen met een poort die in eerste instantie bedoeld is om met SSL/TLS te werken, bijvoorbeeld 443, of door de client bovendien te verzoeken een beveiligde verbinding tot stand te brengen nadat hij een gewone verbinding tot stand heeft gebracht.

2) Bij het tot stand brengen van een verbinding geeft de client een lijst met versleutelingsalgoritmen die hij “kent”. De server controleert de ontvangen lijst met de lijst met algoritmen die de server zelf “kent” en selecteert het meest betrouwbare algoritme, waarna hij de client vertelt welk algoritme hij moet gebruiken

3) De server stuurt de client zijn digitale certificaat, ondertekend door de certificeringsinstantie, en de openbare sleutel van de server.

4) De client kan contact opnemen met de server van de vertrouwde certificeringsinstantie die het servercertificaat heeft ondertekend en controleren of het servercertificaat geldig is. Maar misschien ook niet. Op het besturingssysteem zijn doorgaans al rootcertificaten van certificeringsinstanties geïnstalleerd, waartegen de handtekeningen van servercertificaten bijvoorbeeld door browsers worden geverifieerd.

5) Er wordt een sessiesleutel gegenereerd voor een beveiligde verbinding. Dit gebeurt als volgt:
— De client genereert een willekeurige digitale reeks
— De client codeert het met de openbare sleutel van de server en stuurt het resultaat naar de server
— De server decodeert de ontvangen reeks met behulp van de privésleutel
Aangezien het versleutelingsalgoritme asymmetrisch is, kan alleen de server de reeks ontsleutelen. Bij gebruik van asymmetrische codering worden twee sleutels gebruikt: privé en openbaar. Een bericht dat openbaar wordt verzonden, wordt gecodeerd en een privébericht wordt gedecodeerd. Het is onmogelijk om een ​​bericht te decoderen als je over een publieke sleutel beschikt.

6) Hierdoor wordt een gecodeerde verbinding tot stand gebracht. De gegevens die eroverheen worden verzonden, worden gecodeerd en gedecodeerd totdat de verbinding wordt verbroken.

Root-certificaat

Net hierboven noemde ik het rootcertificaat. Dit is een certificaat van een autorisatiecentrum, waarvan de handtekening bevestigt dat het ondertekende certificaat het certificaat is dat bij de bijbehorende dienst hoort. Het certificaat zelf bevat doorgaans een aantal informatievelden die informatie bevatten over de naam van de server waaraan het certificaat is uitgegeven en de geldigheidsduur van dit certificaat. Als het certificaat is verlopen, wordt het ongeldig verklaard.

Handtekeningverzoek (CSR, certificaatondertekenverzoek)

Om een ​​ondertekend servercertificaat te verkrijgen, moet u een handtekeningverzoek (CSR, Certificate Sign Request) genereren en dit verzoek naar het autorisatiecentrum sturen, dat een ondertekend certificaat retourneert dat rechtstreeks op de server is geïnstalleerd. Hieronder zullen we zien hoe u dit kunt doen; in de praktijk. Eerst wordt een encryptiesleutel gegenereerd en vervolgens wordt op basis van deze sleutel een handtekeningverzoek, een CSR-bestand, gegenereerd.

Klantcertificaat

Er kan een clientcertificaat worden gegenereerd voor zowel apparaat- als gebruikersgebruik. Normaal gesproken worden dergelijke certificaten gebruikt bij tweerichtingsverificatie, waarbij de client verifieert dat de server is wie hij zegt dat hij is, en de server op zijn beurt hetzelfde doet. Deze interactie wordt tweerichtingsauthenticatie of wederzijdse authenticatie genoemd. Tweerichtingsauthenticatie verbetert het beveiligingsniveau vergeleken met eenrichtingsauthenticatie en kan ook dienen als vervanging voor authenticatie met een login en wachtwoord.

Actieketen voor het genereren van certificaten

Laten we eens praktisch bekijken hoe de acties die verband houden met het genereren van certificaten vanaf het allereerste begin en in de praktijk plaatsvinden.

Het eerste dat u moet doen, is een rootcertificaat genereren. Het rootcertificaat is zelfondertekend. En dan worden andere certificaten ondertekend met dit certificaat.

$ openssl genrsa -out root.key 2048 Genereert RSA-privésleutel, 2048 bit lange modulus .......+++ ....... ............... .........+++ e is 65537 (0x10001) $ openssl req -new -key root.key -out root.csr Er wordt u binnenkort gevraagd informatie in te voeren die in uw certificaataanvraag wordt opgenomen . Wat u gaat invoeren, is een zogenaamde Distinguished Name of een DN. Er zijn nogal wat velden, maar u kunt er enkele leeg laten. Voor sommige velden is er een standaardwaarde. Als u "." invoert, blijft het veld leeg. ----- Landnaam (2-lettercode) :RU Staats- of provincienaam (volledige naam) :N.v.t. Plaatsnaam (bijvoorbeeld stad) :Sint-Petersburg Organisatienaam (bijvoorbeeld bedrijf) :Mijn bedrijf Naam van de organisatie-eenheid (bijvoorbeeld sectie) : Algemene naam van de IT-service (bijvoorbeeld FQDN van de server of UW naam) : E-mailadres van het basiscertificaat van mijn bedrijf : [e-mailadres beveiligd] Voer de volgende "extra" attributen in die met uw certificaataanvraag moeten worden meegestuurd. Een uitdagingswachtwoord: Een optionele bedrijfsnaam: Mijn bedrijf $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Handtekening ok subject=/C=RU/ST=N/A/L=Sint-Petersburg/O=Mijn bedrijf/OU=IT Service/CN=Mijn bedrijfsbasiscertificaat/ [e-mailadres beveiligd] Privésleutel verkrijgen

We hebben dus eerst een privésleutel gegenereerd, vervolgens een handtekeningverzoek, en vervolgens ons eigen verzoek met onze sleutel ondertekend en ons eigen digitale certificaat ontvangen, uitgegeven voor 10 jaar. U hoeft geen challenge-wachtwoord in te voeren bij het genereren van een certificaat.

De privésleutel MOET op een veilige plaats worden bewaard; als u deze bezit, kunt u elk certificaat namens u ondertekenen. En het resulterende rootcertificaat kan worden gebruikt om te identificeren dat het certificaat van bijvoorbeeld de server door ons is ondertekend en niet door iemand anders. Dit zijn de acties die autorisatiecentra uitvoeren wanneer zij hun eigen certificaten genereren. Nadat u het rootcertificaat heeft aangemaakt, kunt u beginnen met het genereren van het servercertificaat.

Certificaatinformatie bekijken

De inhoud van het certificaat kunt u als volgt bekijken:

$ openssl x509 -noout -issuer -enddate -in root.pem issuer= /C=RU/ST=N/A/L=Sint-Petersburg/O=Mijn bedrijf/OU=IT Service/CN=Mijn bedrijf rootcertificaat/ [e-mailadres beveiligd] notAfter=22 januari 11:49:41 2025 GMT

Wij zien wie dit certificaat heeft uitgegeven en wanneer de vervaldatum ervan afloopt.

Servercertificaat

Om een ​​certificaat voor de server te ondertekenen, moeten we het volgende doen:

1) Genereer een sleutel
2) Genereer een handtekeningverzoek
3) Stuur het CSR-bestand naar het autorisatiecentrum of onderteken het zelf

Een servercertificaat kan de keten van certificaten bevatten die het servercertificaat ondertekenen, maar kan ook in een apart bestand worden opgeslagen. In principe ziet alles er ongeveer hetzelfde uit als bij het genereren van een rootcertificaat

$ openssl genrsa -out server.key 2048 Genereert RSA-privésleutel, 2048 bit lange modulus .............. ....... .............................................. . +++ .........................+++ e is 65537 (0x10001) $ openssl req -new -key server.key - out server .csr Er wordt u gevraagd informatie in te voeren die in uw certificaataanvraag zal worden opgenomen. Wat u gaat invoeren, is een zogenaamde Distinguished Name of een DN. Er zijn nogal wat velden, maar u kunt er enkele leeg laten. Voor sommige velden is er een standaardwaarde. Als u "." invoert, blijft het veld leeg. ----- Landnaam (2-lettercode) :RU Staats- of provincienaam (volledige naam) :N.v.t. Plaatsnaam (bijvoorbeeld stad) :Sint-Petersburg Organisatienaam (bijvoorbeeld bedrijf) :Mijn bedrijf Naam van de organisatie-eenheid (bijvoorbeeld sectie) : Algemene naam IT-service (bijvoorbeeld server FQDN of UW naam) : www.mijnbedrijf.com E-mailadres : [e-mailadres beveiligd] Voer de volgende "extra" attributen in die met uw certificaataanvraag moeten worden meegestuurd. Een uitdagingswachtwoord: Een optionele bedrijfsnaam: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server. pem -days 365 Handtekening ok subject=/C=RU/ST=N/A/L=Sint-Petersburg/O=Mijn bedrijf/OU=IT Service/CN=www.mycompany.com/ [e-mailadres beveiligd] CA-privésleutel verkrijgen $ openssl x509 -noout -issuer -subject -enddate -in server.pem issuer= /C=RU/ST=N/A/L=Sint-Petersburg/O=Mijn bedrijf/OU=IT Service/CN =Mijn bedrijfscertificaat/ [e-mailadres beveiligd] subject= /C=RU/ST=N/A/L=Sint-Petersburg/O=Mijn bedrijf/OU=IT Service/CN=www.mijnbedrijf.com/ [e-mailadres beveiligd] notAfter=25 januari 12:22:32 2016 GMT

Zo wordt het servercertificaat ondertekend en weten wij welke organisatie dit certificaat heeft uitgegeven. Na ondertekening kan het voltooide certificaat worden gebruikt voor het beoogde doel, bijvoorbeeld geïnstalleerd op een webserver.

Een SSL/TLS-certificaat installeren op een server met nginx

Om een ​​SSL/TLS-certificaat op de nginx-webserver te installeren, moet u een paar eenvoudige stappen volgen:

1) Kopieer de .key- en .pem-bestanden naar de server. Op verschillende besturingssystemen kunnen certificaten en sleutels in verschillende mappen worden opgeslagen. In Debian is dit bijvoorbeeld de directory /etc/ssl/certs voor certificaten en /etc/ssl/private voor sleutels. Op CentOS is dit /etc/pki/tls/certs en /etc/pki/tls/private

2) Schrijf de benodigde instellingen in het configuratiebestand voor de host. Zo zou het er ongeveer uit moeten zien (slechts een voorbeeld):

Server (luister 443; servernaam www.mijnbedrijf.com; root html; index index.html index.htm; ssl aan; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # SSLv3 wordt niet aanbevolen!!! # Het is hier bijvoorbeeld alleen ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;

3) Start Nginx opnieuw

4) Ga met een browser naar serverpoort 443 - https://www.mycompany.com en controleer de functionaliteit ervan.

Een SSL/TLS-certificaat installeren op een server waarop Apache draait

Het installeren van een SSL/TLS-certificaat op Apache ziet er hetzelfde uit.

1) Kopieer de sleutel- en certificaatbestanden naar de server in de juiste mappen

2) Schakel de SSL-module voor Apache in met het commando “a2enmod ssl” als dit nog niet is ingeschakeld

3) Creëer een virtuele host die naar poort 443 luistert. De configuratie zal er ongeveer zo uitzien:

ServerAdmin [e-mailadres beveiligd] DocumentRoot /var/www Opties FollowSymLinks AllowOverride Geen Opties Indexen FollowSymLinks MultiViews AllowOverride Geen Order toestaan, weigeren toestaan ​​van alles ScriptAlias ​​/cgi-bin/ /usr/lib/cgi-bin/ AllowOverride Geen Opties +ExecCGI -MultiViews +SymLinksIfOwnerMatch Volgorde toestaan, weigeren Toestaan ​​van alles ErrorLog $(APACHE_LOG_DIR)/error.log LogLevel warn CustomLog $(APACHE_LOG_DIR)/ssl_access.log gecombineerd SSLEngine op SSLCertificateFile /etc/ssl/certs/server.pem SSLCertificateKeyFile /etc/ssl/private/server.key # Deze richtlijn voegt een file , met een lijst # van alle certificaten die het servercertificaat hebben ondertekend #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt SSLOptions +StdEnvVars SSLOptions +StdEnvVars BrowserMatch "MSIE" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE" ssl-unclean-shutdown

Tegelijkertijd moet er nog iets anders gebeuren. Zoek in het bestand httpd.conf, of apache2.conf, of ports.conf, afhankelijk van het systeem, het volgende gedeelte van de configuratie:

Luister 443

Als een dergelijke voorwaarde niet bestaat, moet deze worden toegevoegd aan de configuratie. En nog één ding: u moet de regel toevoegen

NaamVirtualHost *:443

Deze regel kan in het httpd.conf-, apache2.conf- of ports.conf-bestand staan

4) Start de Apache-webserver opnieuw op

Een clientcertificaat maken

Een clientcertificaat wordt op vrijwel dezelfde manier gemaakt als een servercertificaat.

$ openssl genrsa -out client.key 2048 Genereert RSA-privésleutel, 2048 bit lange modulus ..............+++ ..... ...................................+++ e is 65537 (0x10001) $ openssl req -new -key client.key -out client.csr U wordt op het punt gevraagd informatie in te voeren die in uw certificaataanvraag zal worden opgenomen. Wat u gaat invoeren, is een zogenaamde Distinguished Name of een DN. Er zijn nogal wat velden, maar u kunt er enkele leeg laten. Voor sommige velden is er een standaardwaarde. Als u "." invoert, blijft het veld leeg. ----- Landnaam (2-lettercode) :RU Staats- of provincienaam (volledige naam) : Sint-Petersburg Plaatsnaam (bijvoorbeeld stad) :^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr Er wordt u gevraagd informatie in te voeren die in uw certificaataanvraag zal worden opgenomen. Wat u gaat invoeren, is een zogenaamde Distinguished Name of een DN. Er zijn nogal wat velden, maar u kunt er enkele leeg laten. Voor sommige velden is er een standaardwaarde. Als u "." invoert, blijft het veld leeg. ----- Landnaam (code van 2 letters) :RU Staats- of provincienaam (volledige naam) :N.v.t. Plaatsnaam (bijvoorbeeld stad) :Sint-Petersburg Organisatienaam (bijvoorbeeld bedrijf) :Mijn bedrijf Naam van de organisatie-eenheid (bijvoorbeeld sectie) : Algemene naam engineering (bijvoorbeeld server FQDN of UW naam) : Ivan Ivanov E-mailadres : [e-mailadres beveiligd] Voer de volgende "extra" attributen in die met uw certificaataanvraag moeten worden meegestuurd. Een uitdagingswachtwoord: Een optionele bedrijfsnaam: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client. pem -days 365 Handtekening ok subject=/C=RU/ST=N/A/L=Sint-Petersburg/O=Mijn bedrijf/OU=Engineering/CN=Ivan Ivanov/ [e-mailadres beveiligd] CA-privésleutel verkrijgen $ openssl x509 -noout -issuer -subject -enddate -in client.pem issuer= /C=RU/ST=N/A/L=Sint-Petersburg/O=Mijn bedrijf/OU=IT Service/CN =Mijn bedrijfscertificaat/ [e-mailadres beveiligd] subject= /C=RU/ST=N/A/L=Sint-Petersburg/O=Mijn bedrijf/OU=Engineering/CN=Ivan Ivanov/ [e-mailadres beveiligd] notAfter=25 januari 13:17:15 2016 GMT

Als u een clientcertificaat in PKCS12-indeling nodig heeft, maakt u dit:

$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Voer het exportwachtwoord in: Verifiëren - Voer het exportwachtwoord in:

Nu kunt u het clientcertificaat gebruiken om met onze server te werken.

Nginx configureren om clientcertificaten te gebruiken

Meestal wordt, zoals ik al zei, eenrichtingsauthenticatie gebruikt, meestal wordt alleen het servercertificaat gecontroleerd. Laten we eens kijken hoe we de nginx-webserver kunnen dwingen het clientcertificaat te verifiëren. Het is noodzakelijk om opties aan het servergedeelte toe te voegen om met clientcertificaten te werken:

# Rootcertificaat(en) waarmee de client is ondertekend ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Mogelijke opties: aan | uit | optioneel | optioneel_no_ca ssl_verify_client optioneel; # Diepte van verificatie van de keten van certificaten waarmee de client is ondertekend ssl_verify_ Depth 2;

Hierna dient u de instellingen of de gehele server opnieuw op te starten en kunt u de werking controleren.

Apache configureren om clientcertificaten te gebruiken

Apache kan ook worden geconfigureerd door extra opties toe te voegen aan de virtuele hostsectie:

# Directory met basiscertificaten voor clientverificatie SSLCARevocationPath /etc/apache2/ssl.crl/ # of bestand met certificaten SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Clientverificatieoptie. Mogelijke opties: # geen, optioneel, vereisen en optioneel_no_ca SSLVerifyClient vereisen # Bekijk de diepte van de handtekeningketen. Standaard 1 SSLVerifyDepth 2

Zoals je kunt zien zijn de mogelijkheden ongeveer hetzelfde als voor nginx, omdat het verificatieproces uniform is georganiseerd.

Luisteren naar certificaatinformatie met behulp van openssl

Om te testen hoe de server met clientcertificaten omgaat, kunt u controleren of de verbinding tot stand is gebracht via TLS/SSL.

Aan de serverkant beginnen we te luisteren op de poort met behulp van openssl:

Openssl s_server -accept 443 -cert server.pem -sleutel server.sleutel -status

Aan de clientzijde hebben we bijvoorbeeld toegang tot de server met culr:

Krul -k https://127.0.0.1:443

In de console aan de serverzijde kunt u het proces van informatie-uitwisseling tussen de server en de client observeren.

U kunt ook de opties -verify [verificatiediepte] en -Verify [verificatiediepte] gebruiken. Bij de optie voor kleine gevallen wordt de klant om een ​​certificaat gevraagd, maar deze hoeft niet te worden verstrekt. Met hoofdletter - Als er geen certificaat wordt verstrekt, zal er een fout optreden. Laten we als volgt beginnen met luisteren aan de serverkant:

Openssl s_server -accept 443 -cert server.pem -key server.key -state -Verifiëren 3

Vanaf de serverzijde ziet de fout er als volgt uit:

140203927217808:fout:140890C7:SSL-routines:SSL3_GET_CLIENT_CERTIFICATE:peer heeft geen certificaat geretourneerd:s3_srvr.c:3287:

Vanaf de klantzijde als volgt:

Curl: (35) fout:14094410:SSL-routines:SSL3_READ_BYTES:sslv3 waarschuwing handshake mislukt

Laten we een certificaat en een domeinnaam toevoegen aan de clientzijde (u kunt de hostnaam voor het adres 127.0.0.1 invoeren in het bestand /etc/hosts om dit te controleren):

Curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

Nu is de verbinding succesvol en kunt u het servercertificaat op de webserver installeren, het clientcertificaat aan de client geven en ermee werken.

Veiligheid

Bij het gebruik van SSL/TLS is een van de belangrijkste methoden de MITM-methode (Man In The Middle). Deze methode is afhankelijk van het gebruik van een servercertificaat en een sleutel op een knooppunt dat naar het verkeer luistert en de informatie ontsleutelt die tussen de server en de client wordt uitgewisseld. Om het luisteren te organiseren, kunt u bijvoorbeeld het programma sslsniff gebruiken. Daarom is het meestal raadzaam om het rootcertificaat en de sleutel op te slaan op een machine die niet met het netwerk is verbonden om te ondertekenen, handtekeningverzoeken op een flashdrive te zetten, te ondertekenen en deze ook weer mee te nemen; En natuurlijk back-ups maken.

Over het algemeen wordt op deze manier gebruik gemaakt van digitale certificaten en de TLS- en SSL-protocollen. Als je vragen/aanvullingen hebt, schrijf het dan in de reacties.

Berichtnavigatie

: 29 reacties

1. cl-service.com

   De klant genereert zelf de CSR bij het bestellen van een certificaat, waarbij de klant ook besluit om de private sleutel op te slaan om een ​​certificaat uit te geven, wij hebben de private sleutel niet nodig en de klant geeft deze op geen enkele manier aan ons; Als dit op een reguliere virtuele server gebeurt, hebben beheerders met root-toegang tot de server uiteraard ook toegang tot de sleutels die daar zijn opgeslagen.

2. Weldoener.

   Het onderwerp borsten komt niet aan bod, omdat de beschreven PKI-technologie niets te maken heeft met de titel van het onderwerp. Tenminste om een ​​goede reden heb ik links naar rfc verstrekt.
   P.S. Er was een grap over een hond en een vlo.

3. Weldoener.

   Het was niet mijn bedoeling om je op welke manier dan ook te beledigen. Ik was op zoek naar informatie over het verschil tussen SSL en TLS in de praktijk en jouw link stond als eerste in Google. Ik was geïntrigeerd door de titel van het onderwerp. Alles is leuk, ga zo door!

4. DrAibolit

   Bedankt voor uw inzichtelijke uitleg over digitale certificering. Ik ben nieuw hier =)
   Ik hoop dat u de volgende vraag kunt verduidelijken.
   Omdat het onderwerp fraude zeer ontwikkeld is in de internetindustrie, zou ik graag willen leren hoe ik de ‘luizen’ kan bepalen van de sites die ik bezoek, op eigen kracht (vooral als er sprake is van contant geld en betalingen, investeringen, enz.) en op basis van dit bepaalt de mate van mijn vertrouwen (ik moet me vaak registreren, persoonlijke gegevens achterlaten, aankopen doen, transacties doen, investeringen doen). Als ik het goed begrijp, kunt u met deze certificering een dergelijke beoordeling maken. Aan de andere kant is het verkrijgen ervan geen probleem en het is zelfs gratis.
   Hoe of met welk programma kun je bepalen of een website een digitaal certificaat heeft? en bij voorkeur de categorie ervan, die wordt toegewezen wanneer een speciale autoriteit SSL DV uitgeeft (het certificaat wordt uitgegeven met verificatie van alleen het domein), SSL OV (met verificatie van de organisatie), EV (met uitgebreide verificatie van de rechtspersoon). Frauduleuze sites zullen hoogstwaarschijnlijk niet gebruik maken van de nieuwste certificeringsoptie.
   Ik zou blij zijn als je me meer manieren vertelt om de betrouwbaarheid van sites te bepalen))

   1. minorin Bericht auteur

      Ik ben nog geen specifiek programma voor deze doeleinden tegengekomen, maar ik kan hierover wel een paar tips geven.
      U kunt bijvoorbeeld Chromium of Google Chrome gebruiken. Laten we bijvoorbeeld de site https://www.thawte.com/ nemen - een bedrijf dat zich daadwerkelijk bezighoudt met digitale certificaten.
      De adresbalk bevat de bedrijfsnaam en een groen hangslot. Dit betekent dat de organisatie geverifieerd is, dit is minimaal SSL OV.
      Als u op het slotje klikt en in het vervolgkeuzevenster ‘Details’ en vervolgens ‘Certificaat bekijken’, kunt u informatie over het certificaat zien. Voor Thawte is het certificaat ondertekend door het volgende certificaat: “thawte Extended Validation SHA256 SSL CA”, en het certificaat voor click.alfabank.ru is ook ondertekend door Thawte, maar met een ander certificaat. Dit is "thawte EV SSL CA - G3", dat wil zeggen dat ze ook de uitgebreide validatie hebben doorstaan.
      Zoiets.

5. Rulan

   Sectie ‘Hoe SSL en TLS werken’, ‘De client genereert een willekeurige digitale reeks.’

   Ik was er zeker van dat de client privé-sessiesleutels genereert en dienovereenkomstig openbare sleutels (die u duidelijk 'digitale reeks' noemde). De publieke sleutel wordt doorgegeven aan de server en de server codeert de pakketten naar de client met de publieke sessiesleutel van de client.

   Gelieve te verduidelijken.

6. Nieuwkomer

   Het artikel is erg handig! Er zijn zelfs praktische voorbeelden =) Maar ik begreep één ding niet: wat is het verschil tussen een rootcertificaat en een servercertificaat? of is het hetzelfde?

7. Vitaly

   Hallo.
   De host bood een dienst aan: SSL voor virtuele servers. Wij hebben er gebruik van gemaakt. Het bleek dat voor het derde niveau, d.w.z.
   http://www.site.ru-certificaat is ongeldig, alleen voor site.ru. Bovendien schakelen bezoekers voortdurend over op het https-protocol, ongeacht of ze naar site.ru of http://www.site.ru gaan. In het tweede geval begint de browser natuurlijk hartverscheurend te vloeken en komt de bezoeker nooit op de site.

Maar voor degenen die de site wel bereikten, begon de site er scheef uit te zien, een deel van het menu verdween en sommige afbeeldingen in de zoekresultaten werden door sommige componenten niet meer weergegeven.

SSL TLS-protocol

Gebruikers van begrotingsorganisaties, en niet alleen begrotingsorganisaties, wier activiteiten rechtstreeks verband houden met financiën, in interactie met financiële organisaties, bijvoorbeeld het ministerie van Financiën, de Schatkist, enz., voeren al hun activiteiten uitsluitend uit met behulp van het beveiligde SSL-protocol. Kortom, ze gebruiken de browser Internet Explorer in hun werk. In sommige gevallen Mozilla Firefox." target="_blank">!}

Computernieuws, recensies, oplossingen voor problemen met de computer, computerspellen, stuurprogramma's en apparaten en andere computerprogramma's." title="programma's, stuurprogramma's, problemen met de computer, spellen

SSL-fout Bij het uitvoeren van deze handelingen, en bij werkzaamheden in het algemeen, wordt de meeste aandacht besteed aan het beveiligingssysteem: certificaten, elektronische handtekeningen. Voor de bediening wordt de huidige versie van de CryptoPro-software gebruikt. Met betrekking tot problemen met SSL- en TLS-protocollen , Als SSL-fout

verscheen, is er hoogstwaarschijnlijk geen ondersteuning voor dit protocol.

TLS-fout TLS-fout

in veel gevallen kan het ook duiden op een gebrek aan protocolondersteuning. Maar... laten we eens kijken wat we in dit geval kunnen doen.

Ondersteuning voor SSL- en TLS-protocollen Wanneer u dus Microsoft Internet Explorer gebruikt om een ​​SSL-beveiligde website te bezoeken, wordt de titelbalk weergegeven Zorg ervoor dat de ssl- en tls-protocollen zijn ingeschakeld . Allereerst is het noodzakelijk schakel TLS 1.0-protocolondersteuning in

Gebruikers van begrotingsorganisaties, en niet alleen begrotingsorganisaties, wier activiteiten rechtstreeks verband houden met financiën, in interactie met financiële organisaties, bijvoorbeeld het ministerie van Financiën, de Schatkist, enz., voeren al hun activiteiten uitsluitend uit met behulp van het beveiligde SSL-protocol. Kortom, ze gebruiken de browser Internet Explorer in hun werk. In sommige gevallen Mozilla Firefox." target="_blank">Компьютерная помощь, драйверы, программы, игры!}

in Internet Explorer.

Als u een website bezoekt waarop Internet Information Services 4.0 of hoger wordt uitgevoerd, helpt het configureren van Internet Explorer ter ondersteuning van TLS 1.0 uw verbinding te beveiligen. Uiteraard op voorwaarde dat de externe webserver die u probeert te gebruiken dit protocol ondersteunt. Om dit in het menu te doen Dienst team selecteren.

Internetopties Op het tabblad Aanvullend in sectie Veiligheid

Zorg ervoor dat de volgende selectievakjes zijn ingeschakeld:
Gebruik SSL 2.0
Gebruik SSL 3.0

Gebruik TLS 1.0 Klik op de knop en dan OK . Start uw browser opnieuw .

Probeer de website opnieuw te bezoeken nadat u TLS 1.0 hebt ingeschakeld.

Systeembeveiligingsbeleid

Als ze nog voorkomen fouten met SSL en TLS Als u SSL nog steeds niet kunt gebruiken, ondersteunt de externe webserver waarschijnlijk TLS 1.0 niet. In dit geval is het noodzakelijk systeembeleid uitschakelen, waarvoor FIPS-compatibele algoritmen vereist zijn.

Gebruikers van begrotingsorganisaties, en niet alleen begrotingsorganisaties, wier activiteiten rechtstreeks verband houden met financiën, in interactie met financiële organisaties, bijvoorbeeld het ministerie van Financiën, de Schatkist, enz., voeren al hun activiteiten uitsluitend uit met behulp van het beveiligde SSL-protocol. Kortom, ze gebruiken de browser Internet Explorer in hun werk. In sommige gevallen Mozilla Firefox." target="_blank">Компьютерная помощь, драйверы, программы, игры!}

Om dit te doen, in Bedieningspanelen selecteren Administratie en dubbelklik vervolgens Lokaal veiligheidsbeleid.

Vouw in Lokale beveiligingsinstellingen uit Lokaal beleid en klik vervolgens op de knop Beveiligingsinstellingen.

Dubbelklik volgens het beleid aan de rechterkant van het venster Systeemcryptografie: gebruik FIPS-compatibele algoritmen voor codering, hashing en ondertekening en klik vervolgens op de knop Gehandicapt .

Aandacht! De wijziging wordt van kracht nadat het lokale beveiligingsbeleid opnieuw is toegepast. Dat is zet het aan En herstart uw browser .

CryptoPro TLS SSL

Update CryptoPro

Vervolgens is een van de opties om het probleem op te lossen het updaten van CryptoPro en het instellen van de bron. In dit geval is dat het werken met elektronische betalingen. Daarom gaan we naar het Certificeringscentrum om de bron automatisch te configureren. We selecteren elektronische handelsplatforms als hulpmiddel.

Na het starten van de automatische werkplekinrichting blijft er alleen nog wat over wacht tot de procedure is voltooid, waarna browser opnieuw laden. Als u een bronadres moet invoeren of selecteren, selecteert u het adres dat u nodig heeft. Mogelijk moet u uw computer ook opnieuw opstarten nadat de installatie is voltooid.

Gebruikers van begrotingsorganisaties, en niet alleen begrotingsorganisaties, wier activiteiten rechtstreeks verband houden met financiën, in interactie met financiële organisaties, bijvoorbeeld het ministerie van Financiën, de Schatkist, enz., voeren al hun activiteiten uitsluitend uit met behulp van het beveiligde SSL-protocol. Kortom, ze gebruiken de browser Internet Explorer in hun werk. In sommige gevallen Mozilla Firefox." target="_blank">Компьютерная помощь, драйверы, программы, игры!}

SSL-TLS instellen

Netwerk instellen

Een andere optie zou kunnen zijn NetBIOS via TCP/IP uitschakelen- gelegen in de verbindingseigenschappen.

DLL-registratie

Start de opdrachtprompt als beheerder en voer de opdracht in regsvr32 cpcng. Voor een 64-bits besturingssysteem moet u dezelfde regsvr32 gebruiken als in syswow64.

Volgens de vereisten van de Russische wetgeving wordt alleen het gebruik van TLS-verbindingen erkend die zijn opgezet volgens de Russische cryptografische algoritmen GOST 28147-89, GOST R 34.10-94, GOST R 34.11-94 en GOST R 34.10-2001. Daarom, als u sites moet gebruiken die codering gebruiken volgens GOST-algoritmen, moet u het CryptoPro CSP-programma installeren.

Windows-besturingssystemen gebruiken het CryptoPro CSP-programma - een reeks cryptografische hulpprogramma's voor het genereren van elektronische handtekeningen en het werken met certificaten

Om CryptoPro CSP te installeren, gebruikt u het materiaal van de officiële website:

• CryptoPro CSP-distributie
• Een pakket met instructies voor het installeren en gebruiken van CryptoPro CSP

Na installatie van CryptoPro CSP controleert de browser de aanwezigheid en functionaliteit van dit programma.

Sites die GOST TLS-codering aanvragen

Als een site om GOST TLS-codering vraagt, controleert de browser of het CryptoPro CSP-programma is geïnstalleerd. Als het programma is geïnstalleerd, wordt de besturing ernaar overgedragen.

Voorbeelden van sites die om encryptie vragen: www.gosuslugi.ru, sites op het domein .gov.ru, .kamgov.ru, .nalog.ru.

Als de site niet op de lijst staat, wordt om aanvullende bevestiging gevraagd. Als u de site vertrouwt en de verbinding moet tot stand worden gebracht met behulp van GOST TLS-codering, klikt u op de knop Doorgaan.

Opmerking. Sites vereisen mogelijk de installatie van certificaten. Instructies voor het installeren van certificaten bevinden zich meestal op de sites die erom vragen.

Ondersteuning voor CryptoPro CSP-browser in- en uitschakelen

Standaard ondersteunt de browser CryptoPro CSP. Wij raden u aan dit te controleren.

Beschrijving

Met TLS kunnen client-serverapplicaties via een netwerk communiceren op een manier die afluisteren en ongeautoriseerde toegang voorkomt.

Omdat de meeste communicatieprotocollen met of zonder TLS (of SSL) kunnen worden gebruikt, moet u bij het tot stand brengen van een verbinding expliciet aan de server doorgeven of de client TLS wil installeren. Dit kan worden bereikt door een uniform poortnummer te gebruiken waarop de verbinding altijd tot stand wordt gebracht met behulp van TLS (zoals poort 443 voor HTTPS), of door een willekeurige poort te gebruiken en een speciaal commando naar de server aan de clientzijde te sturen om de verbinding te schakelen. naar TLS met behulp van speciale mechanismenprotocollen (zoals STARTTLS voor e-mailprotocollen). Zodra de client en de server hebben ingestemd met het gebruik van TLS, moeten ze een beveiligde verbinding tot stand brengen. Dit gebeurt via een handshake-procedure. Secure Socket-lagen). Tijdens dit proces komen de client en de server verschillende parameters overeen die nodig zijn om een ​​veilige verbinding tot stand te brengen.

Er zijn ook aanvalsvarianten die rechtstreeks gebaseerd zijn op de software-implementatie van het protocol, en niet op het algoritme ervan.

TLS-handshake-procedure in detail

Volgens het TLS-protocol wisselen applicaties records uit die de informatie die moet worden overgedragen, inkapselen (in zichzelf opslaan). Elk van de vermeldingen kan worden gecomprimeerd, opgevuld, gecodeerd of geïdentificeerd door een MAC (Message Authentication Code), afhankelijk van de huidige verbindingsstatus (protocolstatus). Elk TLS-item bevat de volgende velden: inhoudstype (definieert het inhoudstype van het item), een veld dat de pakketlengte aangeeft, en een veld dat de versie van het TLS-protocol aangeeft.

Wanneer de verbinding voor het eerst tot stand wordt gebracht, vindt de interactie plaats met behulp van het TLS-handshakeprotocol, inhoudstype dat is 22.

Eenvoudige handdruk in TLS

1. Onderhandelingsfase:
   • De klant stuurt een bericht KlantHallo
   • De server reageert met een bericht ServerHallo
   • De server verzendt een bericht Certificaat
   • De server verzendt een bericht Server Hallo Klaar
   • De klant reageert met een bericht ClientKeyExchange, die de openbare sleutel van PreMasterSecret bevat (deze PreMasterSecret wordt gecodeerd met behulp van de openbare sleutel van het servercertificaat.) of niets (hangt opnieuw af van het coderingsalgoritme);
   • PreMasterGeheim
2. De klant stuurt een bericht WijzigCipherSpec
   • De klant stuurt een bericht Afgerond
3. De server verzendt WijzigCipherSpec

Handdruk met clientauthenticatie

Dit voorbeeld demonstreert volledige clientauthenticatie (naast serverauthenticatie zoals in het vorige voorbeeld) door certificaten uit te wisselen tussen de server en de client.

1. Onderhandelingsfase:
   • De klant stuurt een bericht KlantHallo, met vermelding van de nieuwste versie van het ondersteunde TLS-protocol, een willekeurig getal en een lijst met ondersteunde versleutelings- en compressiemethoden die geschikt zijn om met TLS te werken;
   • De server reageert met een bericht ServerHallo, met daarin: de door de server geselecteerde protocolversie, een willekeurig getal verzonden door de client, een geschikt versleutelings- en compressie-algoritme uit de door de client verstrekte lijst;
   • De server verzendt een bericht Certificaat, dat het digitale certificaat van de server bevat (afhankelijk van het versleutelingsalgoritme kan deze stap worden overgeslagen);
   • De server verzendt een bericht CertificaatAanvraag, dat een clientcertificaatverzoek voor wederzijdse authenticatie bevat;
   • [Het punt voor het verkrijgen en verifiëren van het clientcertificaat ontbreekt] ;
   • De server verzendt een bericht Server Hallo Klaar, waarmee het einde van de handdruk wordt geïdentificeerd;
   • De klant reageert met een bericht ClientKeyExchange, die de openbare sleutel PreMasterSecret of niets bevat (opnieuw afhankelijk van het versleutelingsalgoritme);
   • Client en server met sleutel PreMasterGeheim en willekeurig gegenereerde getallen, wordt een gedeelde geheime sleutel berekend. Alle andere sleutelinformatie wordt afgeleid van de gedeelde geheime sleutel (en door de client en server gegenereerde willekeurige waarden);
2. De klant stuurt een bericht WijzigCipherSpec, wat aangeeft dat alle daaropvolgende informatie wordt gecodeerd met behulp van het algoritme dat is vastgesteld tijdens het handshake-proces, met behulp van een gedeelde geheime sleutel. Dit zijn berichten op recordniveau en zijn daarom van het type 20 in plaats van 22;
   • De klant stuurt een bericht Afgerond, die de hash en MAC bevat die zijn gegenereerd op basis van eerdere handshake-berichten;
   • De server probeert het Finished-bericht van de client te decoderen en de hash en MAC te controleren. Als het decoderings- of verificatieproces mislukt, wordt de handshake als mislukt beschouwd en moet de verbinding worden verbroken.
3. De server verzendt WijzigCipherSpec en het gecodeerde bericht is voltooid, en op zijn beurt voert de client ook decodering en verificatie uit.

Vanaf dit moment wordt de communicatiebevestiging als voltooid beschouwd en is het protocol tot stand gebracht. Alle volgende pakketinhoud wordt geleverd met type 23 en alle gegevens worden gecodeerd.

Een TLS-verbinding hervatten

Asymmetrische versleutelingsalgoritmen die worden gebruikt om de sessiesleutel te genereren, zijn doorgaans duur in termen van rekenkracht. Om herhaling te voorkomen wanneer de verbinding wordt hervat, maakt TLS tijdens handshake een speciale snelkoppeling die wordt gebruikt om de verbinding te hervatten. In dit geval voegt de cliënt tijdens een normale communicatiebevestiging iets toe aan het bericht KlantHallo vorige sessie-ID sessie-id. Klant bindt ID sessie-id met het IP-adres van de server en de TCP-poort, zodat u bij het verbinden met de server alle parameters van de vorige verbinding kunt gebruiken. De server komt overeen met de vorige sessie-ID sessie-id met verbindingsparameters, zoals het gebruikte versleutelingsalgoritme en het hoofdgeheim. Beide partijen moeten hetzelfde hoofdgeheim hebben, anders komt de verbinding niet tot stand. Dit verhindert het gebruik sessie-id cryptanalyticus om ongeautoriseerde toegang te verkrijgen. Willekeurige nummerreeksen in berichten KlantHallo En ServerHallo kunt u garanderen dat de gegenereerde sessiesleutel anders zal zijn dan de sessiesleutel tijdens de vorige verbinding. De RFC noemt dit type handdruk afgekort.

1. Onderhandelingsfase:
   • De klant stuurt een bericht KlantHallo, met vermelding van de nieuwste versie van het ondersteunde TLS-protocol, een willekeurig getal en een lijst met ondersteunde versleutelings- en compressiemethoden die geschikt zijn om met TLS te werken; De vorige verbindings-ID wordt ook aan het bericht toegevoegd. sessie-id.
   • De server reageert met een bericht ServerHallo, met daarin: de door de server geselecteerde protocolversie, een willekeurig getal verzonden door de client, een geschikt versleutelings- en compressie-algoritme uit de door de client verstrekte lijst. Als de server de sessie-ID herkent sessie-id ServerHallo zelfde identiteitsbewijs sessie-id. Dit is een signaal voor de cliënt dat het hervatten van de vorige sessie kan worden gebruikt. Als de server de sessie-ID niet herkent sessie-id, waarna hij iets aan het bericht toevoegt ServerHallo in plaats daarvan een andere betekenis sessie-id. Voor de klant betekent dit dat de vernieuwde verbinding niet gebruikt kan worden. De server en client moeten dus hetzelfde hoofdgeheim en dezelfde willekeurige getallen hebben om een ​​sessiesleutel te genereren;
2. De klant stuurt een bericht WijzigCipherSpec, wat aangeeft dat alle daaropvolgende informatie wordt gecodeerd met de gedeelde geheime sleutel die is vastgesteld tijdens het handshake-proces. Dit zijn berichten op recordniveau en zijn daarom van het type 20 in plaats van 22;
3. De klant stuurt een bericht WijzigCipherSpec, wat aangeeft dat alle daaropvolgende informatie wordt gecodeerd met behulp van het algoritme dat is vastgesteld tijdens het handshake-proces, met behulp van een gedeelde geheime sleutel. Dit zijn berichten op recordniveau en zijn daarom van het type 20 in plaats van 22;
   • De klant stuurt een bericht Afgerond, die de hash en MAC bevat die zijn gegenereerd op basis van eerdere handshake-berichten;
   • De server probeert het Finished-bericht van de client te decoderen en de hash en MAC te controleren. Als het decoderings- of verificatieproces mislukt, wordt de handshake als mislukt beschouwd en moet de verbinding worden verbroken;
4. De server verzendt WijzigCipherSpec en het gecodeerde bericht is voltooid, en op zijn beurt voert de client ook decodering en verificatie uit.

Vanaf dit moment wordt de communicatiebevestiging als voltooid beschouwd en is het protocol tot stand gebracht. Alle volgende pakketinhoud wordt geleverd met type 23 en alle gegevens worden gecodeerd.

Naast de prestatievoordelen kan het worden gebruikt om eenmalige aanmelding te implementeren, omdat gegarandeerd wordt dat de oorspronkelijke sessie en elke hervatte sessie door dezelfde client worden geïnitieerd (RFC 5077). Dit is vooral belangrijk bij het implementeren van FTP via TLS/SSL, dat anders kwetsbaar zou zijn voor een man-in-the-middle-aanval waarbij een aanvaller de gegevensinhoud zou kunnen onderscheppen wanneer er opnieuw verbinding wordt gemaakt.

Algoritmen gebruikt in TLS

De volgende algoritmen zijn beschikbaar in deze huidige versie van het protocol:

• Om sleutels uit te wisselen en hun authenticiteit te verifiëren, worden combinaties van algoritmen gebruikt: RSA (asymmetrische codering), Diffie-Hellman (veilige sleuteluitwisseling), DSA (algoritme voor digitale handtekeningen) en Fortezza-technologie-algoritmen;
• Voor symmetrische encryptie: RC2, RC4, IDEA, DES, Triple DES of AES;

Afhankelijk van de protocolversie kunnen algoritmen worden aangevuld.

Vergelijking met analogen

Eén toepassing van een TLS-verbinding is het verbinden van hosts in een virtueel particulier netwerk. Naast TLS kan er ook gebruik worden gemaakt van een set IPSec-protocollen en een SSH-verbinding. Elk van deze benaderingen voor het implementeren van een virtueel particulier netwerk heeft zijn eigen voor- en nadelen. .

1. TLS/SSL
   • Voordelen:
     • Onzichtbaar voor protocollen op een hoger niveau;
     • Populair gebruik in internetverbindingen en e-commercetoepassingen;
     • Gebrek aan permanente verbinding tussen server en client;
     • TCP/IP zoals e-mail, programmeertools, enz.
   • Gebreken:
     • UDP en ICMP;
     • De noodzaak om de verbindingsstatus te controleren;
     • Er zijn aanvullende softwarevereisten voor TLS-ondersteuning.
2. IPsec
   • Voordelen:
     • De veiligheid en betrouwbaarheid van de gegevensbescherming van het protocol zijn getest en bewezen sinds het protocol als internetstandaard werd aangenomen;
     • Werken in de bovenste laag van het netwerkprotocol en het coderen van gegevens boven de netwerkprotocollaag.
   • Gebreken:
     • Complexiteit van de implementatie;
     • Aanvullende eisen voor netwerkapparatuur (routers etc.);
     • Er zijn veel verschillende implementaties die niet altijd correct met elkaar samenwerken.
3. SSH
   • Voordelen:
     • Hiermee kunt u een tunnel creëren voor toepassingen die TCP/IP gebruiken, zoals e-mail, programmeertools, enz.;
     • De beveiligingslaag is onzichtbaar voor de gebruiker.
   • Gebreken:
     • Moeilijk te gebruiken op netwerken met een groot aantal gateways, zoals routers of firewalls;
     • Onvermogen om te gebruiken met UDP- en ICMP-protocollen.

Zie ook

Koppelingen

1. T. Dierks, E. Rescorla Het Transport Layer Security (TLS) Protocol, versie 1.2 (augustus 2008). Gearchiveerd van het origineel op 9 februari 2012.
2. Het SSL-protocol: versie 3.0 Netscape's definitieve SSL 3.0-concept (18 november 1996)
3. "SSL/TLS gedetailleerd". Microsoft TechNet. Bijgewerkt op 31 juli 2003.
4. Dan Goodin . Het register(19 september 2011). Gearchiveerd
5. Eric Rescorla De TLS-heronderhandelingsaanval begrijpen. Opgeleid giswerk(5 november 2009). Gearchiveerd van het origineel op 9 februari 2012. Teruggevonden op 7 december 2011.
6. McMillan, Robert. Security Pro zegt dat nieuwe SSL-aanval veel sites kan treffen PC-wereld(20 november 2009). Ontvangen op 7 december 2011.
7. SSL_CTX_set_options SECURE_RENEGOTIATION . OpenSSL-documenten(25 februari 2010). Gearchiveerd van het origineel op 9 februari 2012. Teruggevonden op 7 december 2010.
8. GnuTLS 2.10.0 uitgebracht. GnuTLS-release-opmerkingen(25 juni 2010). Gearchiveerd van het origineel op 9 februari 2012. Teruggevonden op 7 december 2011.
9. NSS 3.12.6 releaseopmerkingen. NSS-releaseopmerkingen(3 maart 2010). Ontvangen 24 juli 2011.
10. Verscheidene IE SSL-kwetsbaarheid. Opgeleid giswerk(10 augustus 2002).