Tls-verbinding. Wat is TLS

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

IN besturingssystemen Windows maakt gebruik van 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.

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, in hun werk gebruiken ze de browser Internet Explorer. In sommige gevallen Mozilla Firefox.

Computernieuws, recensies, computerproblemen oplossen, computerspellen, stuurprogramma's en apparaten en anderen computerprogramma's." title="programma's, stuurprogramma's, problemen met de computer, games" target="_blank">!}

SSL-fout

Bij het uitvoeren van deze werkzaamheden, 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

Dus, wanneer met behulp van Microsoft Internet Explorer, om een ​​website via SSL te bezoeken, wordt de titelbalk weergegeven Zorg ervoor dat SSL-protocollen en tls ingeschakeld. Allereerst is het noodzakelijk ondersteuning mogelijk maken TLS-protocol 1.0 in Internet Explorer.

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" target="_blank">Компьютерная помощь, драйверы, программы, игры!}

Als u een website bezoekt waarop Internet Information Services 4.0 of hoger draait, Internet-installatie De TLS 1.0-ondersteuning van Explorer helpt 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 Toepassen 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.

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" target="_blank">Компьютерная помощь, драйверы, программы, игры!}

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

IN lokale parameters beveiliging, breid het knooppunt 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 daarna van kracht lokale politiek beveiliging wordt opnieuw 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 wordt er gewerkt met elektronische betalingen. Daarom gaan wij naar het Certificatiecentrum voor automatische instellingen bron. 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.

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" target="_blank">Компьютерная помощь, драйверы, программы, игры!}

SSL-TLS instellen

Netwerk instellen

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

DLL-registratie

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

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 essentie 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 oorspronkelijk is ontworpen om met SSL/TLS te werken, bijvoorbeeld 443, of extra verzoek de client brengt een beveiligde verbinding tot stand nadat hij een normale 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 er het meest uit betrouwbaar algoritme en vertelt de client vervolgens 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. Het besturingssysteem is meestal al geïnstalleerd root-certificaten certificeringsinstanties waarmee de handtekeningen van servercertificaten worden geverifieerd, bijvoorbeeld browsers.

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 een symmetrische encryptie Er 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. Met tweerichtingsauthenticatie kunt u het beveiligingsniveau verhogen in vergelijking met eenrichtingsauthenticatie, en kan het 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 U wordt op het punt gevraagd informatie in te voeren die in uw certificaat aanvraag. 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 FQDN van de server of UW naam) : E-mailadres van het basiscertificaat van mijn bedrijf : [e-mailadres beveiligd] Voer alstublieft in het volgende"extra" attributen die moeten worden meegestuurd met uw certificaataanvraag 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

Dus we hebben eerst gegenereerd privé sleutel, vervolgens een handtekeningverzoek, en vervolgens hun eigen verzoek met hun sleutel ondertekenden en hun 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) Registreren noodzakelijke instellingen V configuratiebestand voor de gastheer. 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 Order 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 toe te voegen extra opties naar de virtuele hostsectie:

# Directory met rootcertificaten 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 -Verify 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 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, deze te ondertekenen en 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 bij het bestellen van een certificaat zelf de CSR, waar deze kan worden opgeslagen privé sleutel de klant besluit ook een certificaat uit te geven, wij hebben geen private sleutel nodig en de klant geeft deze op geen enkele wijze aan ons. Natuurlijk, als dit gebeurt op een gewone virtuele, dan zullen beheerders dat doen root-toegang Er is toegang tot de server en tot de sleutels die daar opgeslagen zijn.

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 zelf bezoek (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 aanmelden, weggaan persoonlijke informatie, aankopen doen, transacties, investeringen). 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. Laten we bijvoorbeeld de site https://www.thawte.com/ nemen - een bedrijf dat zich daadwerkelijk bezighoudt met digitale certificaten.
      IN adresbalk de bedrijfsnaam en een groen hangslot worden geschreven. 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 is zelfs praktische voorbeelden=) Alleen begreep ik éé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 worden bezoekers koppig erin gegooid https-protocol
   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.

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 maken client en server afspraken hierover verschillende parameters nodig om een ​​veilige verbinding tot stand te brengen.

Er zijn ook aanvalsvarianten die rechtstreeks op software-implementatie protocol, en niet op zijn algoritme.

TLS-handshake-procedure in detail

Volgens het TLS-protocol wisselen applicaties records uit die de informatie die moet worden verzonden, 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 net tot stand is 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 behulp van 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

Algoritmen asymmetrische encryptie die worden gebruikt om de sessiesleutel te genereren, zijn meestal duur in termen van rekenkracht. Om te voorkomen dat ze worden herhaald wanneer de verbinding wordt hervat, wordt er TLS gemaakt speciaal etiket bij het bevestigen van de verbinding, 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 dezelfde identificatie 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 een andere betekenis in plaats daarvan sessie-id. Voor de klant betekent dit dat de vernieuwde verbinding niet gebruikt kan worden. De server en client moeten dus hetzelfde hoofdgeheim hebben en willekeurige getallen 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 algoritme voor verbindingsvernieuwing 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 heeft vooral belangrijk om FTP via het TLS/SSL-protocol te implementeren, 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

Hierin huidige versie De volgende algoritmen zijn beschikbaar in het protocol:

• Om sleutels uit te wisselen en de authenticiteit ervan te verifiëren, worden combinaties van algoritmen gebruikt: RSA ( asymmetrisch cijfer), Diffie-Hellman ( veilige uitwisseling sleutels), 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 gemaakt worden 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;
     • Beschikbaarheid aanvullende vereisten Naar software over 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;
     • Werk in de bovenste laag van het netwerkprotocol en codeer gegevens boven de netwerkprotocollaag.
   • Gebreken:
     • Complexiteit van de implementatie;
     • Aanvullende eisen voor netwerkapparatuur (routers etc.);
     • Er zijn er veel diverse implementaties niet altijd goed met elkaar omgaan.
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).

De SMTP-sessie tussen de server en de client is standaard niet gecodeerd. Hierdoor is het mogelijk om pakketten te onderscheppen en te ontvangen vertrouwelijke informatie verzonden in leesbare tekst (tenzij andere versleutelingsmethoden worden gebruikt).

Het gebruik van het TLS-protocol zal ons helpen deze situatie te corrigeren, wat ervoor zorgt dat:

1. Vertrouwelijkheid (Interactie tussen client en server vindt gecodeerd plaats
sessie);

2. Integriteit (het is onmogelijk om ongemerkt een sessie te infiltreren; datacorruptie wordt onmiddellijk gedetecteerd);

3. Authenticatievertrouwen (De client en server kunnen certificaten uitwisselen die zijn gecertificeerd door een certificeringsinstantie (CA).

Hoe TLS werkt

Het TLS-protocol codeert alleen de verbinding tussen twee hosts. Een sessie waarbij dit protocol wordt gebruikt, verloopt als volgt:

1. De client brengt een verbinding tot stand met de server.

2. Hosts beginnen met communiceren via het SMTP-protocol.

3. De server stelt met behulp van het trefwoord STARTTLS voor om TLS te gebruiken binnen SMTP-interacties.

4. Als de client TLS kan gebruiken, reageert deze op de server met het trefwoord STARTTLS.

5. Het openbare certificaat van de server wordt ondertekend met de privésleutel en naar de client verzonden.

6. De client verifieert de authenticiteit van het servercertificaat door de handtekening van de certificeringsinstantie te controleren met de openbare handtekening van de certificeringsinstantie die deze in de rootstore heeft staan.

7. De client controleert het servercertificaat aan de hand van de string die het bevat Algemene naam domeinnaam server.

8. De client en server schakelen de gegevenscoderingsmodus in.

9. Hosts wisselen gegevens uit.

10. De sessie eindigt.

Laten we beginnen met het maken van certificaten voor de mailserver server.mijndomein.ru , waarop Postfix optreedt als MTA en Dovecot de MDA-rol vervult.

Een nieuw certificaat maken is eenvoudig: voer gewoon het script uit en voer een paar opdrachten uit.

Laten we twee bestanden genereren: de geheime sleutel van de server en een met de opdracht:

# openssl req -nodes -newkey rsa:2048 -keyout server.key -out server.csr

waarbij server de servernaam is (in dit geval kan dit van alles zijn)

Vul de velden in (door op “Enter” te drukken blijft de standaardwaarde behouden):

Landnaam (2-lettercode): RU
Naam staat of provincie (volledige naam): Orenburg
Plaatsnaam (bijvoorbeeld stad): Orsk
Organisatienaam (bijvoorbeeld bedrijf): MijnBedrijf
Naam van de organisatie-eenheid (bijvoorbeeld sectie): HET
Algemene naam (bijvoorbeeld UW naam): server.mijndomein.ru
E-mailadres: postmaster @mijndomein.ru
Een uitdagingswachtwoord:
Een optionele bedrijfsnaam:

Het is erg belangrijk om dit in het veld aan te geven Algemene naam volledig gekwalificeerde hostnaam (FQDN) die overeenkomt met DNS-records van MX- ​​en A-typen

We maken van de mogelijkheid gebruik om gratis COMODO-certificaten met een geldigheidsduur van 90 dagen te verkrijgen op de FreeSSL.su-service. Deze certificaten worden gemakkelijk herkend door alle browsers en e-mailclients.

Vul op de hoofdpagina alle vereiste velden in, selecteer in de kolom “Selecteer de te gebruiken software” de optie “Overig”. In het veld MVO voer de inhoud van het eerder gegenereerde bestand in server.csr .

Na het versturen en bevestigen van de aanvraag ontvangen wij een archief certs.zip , met de volgende bestanden:

1. AddTrustExternalCARoot.crt;
2. server_mijndomein_ru.crt;
3. ComodoUTNSGCCA.crt;
4. EssentieelSSLCA_2.crt;
5. UTNAddTrustSGCCA.crt

Het server_mijndomein_ru.crt-bestand is het vereiste certificaat. Wat moeten we doen met de resterende bestanden? Laten we dit doen: combineer hun inhoud in één bestand ca.txt (vertrouwd CA-certificaat C.A. ) in de volgende volgorde:

1. EssentieelSSLCA_2.crt
2. ComodoUTNSGCCA.crt
3. UTNAddTrustSGCCA.crt
4. AddTrustExternalCARoot.crt

Ontvangen bestand ca.txt We zullen verder gebruiken:

Laten we onze mailserver configureren. Om dit te doen, brengen we wijzigingen aan in de configuraties duiventil En achtervoegsel .

Voor duiventil:

duiventil.conf:

protocollen = pop3 imap imaps pop3s

protocol pop3 (
luister = *:110
ssl_luisteren = *:995
...........
}

protocol imap (
luister = *:143
ssl_luisteren = *:993
...........
}

uitschakelen_plaintext_auth = nee # We verbieden inloggen op de open manier niet
ssl = ja # SSL-ondersteuning inschakelen
ssl_cert_file = /etc/ssl/certs/dovecot.pem # certificaatbestand,
# stel er machtigingen voor in: root:root 0444
ssl_key_file = /etc/ssl/private/dovecot.pem # serversleutel,
# het wordt aanbevolen om de machtigingen in te stellen: root:root 0400

ssl_verify_client_cert = ja # controleer de geldigheid van clientcertificaten
ssl_parameters_regenerate = 1 # regenereert parameters elk uur
# (waarde "0" schakelt regeneratie uit)
ssl_cipher_list = ALL:!LOW:!SSLv2 # SSL-codering
verbose_ssl = ja # log ssl-fouten in het logbestand

Om te krijgen ssl_cert_bestand moet u de inhoud van de bestanden samenvoegen server_mijndomein_ru.crt En ca.txt , hernoem het resulterende bestand naar dovecot.pem. In de rol ssl_sleutel_bestand het hernoemde geheime serversleutelbestand verschijnt server.sleutel , eerder gegenereerd.

Voor postfix:

hoofd.cf

Smtp_use_tls = ja # gebruik TLS als de externe server TLS-ondersteuning rapporteert
smtpd_use_tls = ja # informeer klanten over TLS-ondersteuning
smtpd_tls_auth_only = nee # gebruik SMTP-authenticatie voor meer dan alleen TLS-verbindingen
smtp_tls_note_starttls_offer = ja # log servernamen,
# geeft een STARTTLS-bericht uit waarvoor TLS-ondersteuning niet is ingeschakeld

smtpd_tls_CAfile = /etc/ssl/ca.txt # vertrouwd certificaat
smtpd_tls_key_file = /etc/ssl/smtpd.key # privésleutel van de server
smtpd_tls_cert_file = /etc/ssl/smtpd.crt # servercertificaat

smtpd_tls_loglevel = 2 # breedsprakigheid van TLS-activiteitsberichten
smtpd_tls_received_header = ja # verzoek om berichtkoppen met informatie
# over de protocolversie en het versleutelingsalgoritme
smtpd_tls_session_cache_timeout = 3600s # tijd dat de gegevens in de cache staan
# TLS-sessies worden als actueel beschouwd
tls_random_source = dev:/dev/urandom # naam van het pseudo-willekeurige nummergenerator-apparaat (PRNG)

Om Postfix TLS-verbindingen op een speciale poort (465/SMTPS, niet 25/SMTP) te laten accepteren, moet in het bestand meester.cf je moet de regels verwijderen:

meester.cf

Smtps inet n - n - - smtpd
-o smtpd_tls_wrappermode=ja
-o smtpd_sasl_auth_enable=ja
-o smtpd_client_restrictions=permit_sasl_authenticated,weigeren

Start postfix en duiventil opnieuw, controleer de logs.

Vergeet niet te openen vereiste poorten in de firewall: 993 (imaps), 995 (pop3s), 465 (smtps)

Onze mailserver is klaar om mee te werken TLS !

Naar e-mailclients de nieuwe servermogelijkheden correct zou kunnen gebruiken, moet u de protocolinstellingen instellen FQDN server, zoals deze is opgegeven tijdens de sleutel en het verzoek, en selecteer het beveiligingstype voor de verbinding SSL/TLS en gerelateerd havens.

Aan het einde van de geldigheidsduur van 90 dagen van de certificaten moet u dezelfde procedure volgen en met hetzelfde bestand een aanvraag indienen server.csr , dus u moet een kopie ervan op een veilige plaats bewaren. Het hele updateproces duurt niet meer dan 10 minuten!