Wat is de belangrijkste functie van het tls-protocol. TLS-protocol

• De verbinding is vertrouwelijk. Symmetrische cryptografie (bijv. DES, RC4, etc.) wordt gebruikt om gegevens te coderen. Encryptiesleutels worden voor elke verbinding afzonderlijk gegenereerd en zijn gebaseerd op een geheime code die is verkregen via een ander protocol (zoals het TLS-gespreksprotocol). Opnameprotocol kan zonder encryptie gebruikt worden.
• De verbinding is betrouwbaar. De procedure voor het verzenden van berichten omvat integriteitscontrole met behulp van MAC-berekening. Hash-functies (bijv. SHA, MD5, etc.) worden gebruikt om de MAC te berekenen. Opnameprotocol kan zonder MAC werken, maar wordt in deze modus alleen gebruikt als een ander protocol gebruikt protocol opnemen als transportmiddel bij het bepalen van beveiligingsparameters.

Opnameprotocol TLS wordt gebruikt om verschillende protocollen in te kapselen hoog niveau. Eén zo'n ingekapselde entiteit, het TLS-gespreksprotocol, stelt de server en de client in staat elkaar te authenticeren en overeenstemming te bereiken over een versleutelingsalgoritme en cryptosleutels voordat de applicatie de eerste byte aan informatie verzendt of ontvangt. Het TLS-gespreksprotocol biedt een veilige verbinding die drie basiseigenschappen heeft.

• De identiteit van de partners kan worden vastgesteld met behulp van asymmetrische cryptografie (bijvoorbeeld RSA, DSS, enz.). Deze authenticatie kan optioneel worden gemaakt, maar is vereist door ten minste, voor een van de partners.
• Het onthullen van de gedeelde geheime code is veilig: dit geheime code is ontoegankelijk voor een aanvaller, zelfs als hij erin slaagt verbinding te maken met de verbinding.
• Het gesprek is beveiligd: een aanvaller kan de verbinding niet wijzigen zonder opgemerkt te worden door de uitwisselingspartners.

Een van de voordelen van TLS is dat het onafhankelijk is van het applicatieprotocol. Protocollen hoogste niveau kan transparant bovenop het TLS-protocol worden geplaatst. De TLS-standaard specificeert echter niet hoe protocollen de beveiliging verbeteren met behulp van TLS; de beslissing over hoe een TLS-gesprek moet worden geïnitialiseerd en hoe authenticatiecertificaten moeten worden geïnterpreteerd, wordt overgelaten aan het oordeel van de ontwikkelaars van de protocollen en programma's die bovenop TLS worden uitgevoerd.

Doelen

De doelstellingen van het TLS-protocol, in volgorde van prioriteit, zijn:

1. Cryptografische beveiliging. TLS moet worden gebruikt om tot stand te komen beveiligde verbinding tussen twee partners.
2. Verenigbaarheid. Onafhankelijke programmeurs moeten met behulp van TLS applicaties kunnen ontwikkelen die met succes cryptografische parameters kunnen uitwisselen zonder kennis van elkaars programma's.
3. Uitbreidbaarheid. TLS zoekt naar een manier om indien nodig nieuwe sleutels en encryptiemethoden in het systeem te integreren. Er zijn hier twee secundaire doelen: het elimineren van de noodzaak om een ​​nieuw protocol te creëren (wat de introductie van nieuwe protocollen met zich mee kan brengen). zwakke punten) en implementatie overbodig maken nieuwe bibliotheek het garanderen van de veiligheid.
4. Relatieve efficiëntie. Cryptografische operaties vereisen grote CPU-capaciteiten, vooral operaties met publieke sleutels staan ​​hierom bekend. Om deze reden heeft het TLS-protocol een optioneel sessiecaching-schema, dat het aantal verbindingen vermindert dat tot stand wordt gebracht met behulp van nieuwe tijdelijke buffers.

Presentatie taal

De presentatie van gegevens in dit document lijkt op de syntaxis van de C-taal en XDR [XDR], maar deze parallellen zijn behoorlijk grof en hebben niets te maken met het TLS-protocol zelf. Deze representaties worden alleen gebruikt om de perceptie van het materiaal te vereenvoudigen.

Een basisdatablok wordt beschouwd als één byte (d.w.z. 8 bits). Multibyte-informatie-elementen zijn een aaneenschakeling van een reeks bytes van links naar rechts en van boven naar beneden. Multibyte-elementen worden als volgt uit de bytestroom opgehaald (met behulp van de C-notatie):

waarde = (byte<< 8*(n-1)) | (байт << 8*(n-2)) | ... | байт;

Deze bytevolgorde voor multibytereeksen is standaard voor netwerken (big endian).

Opmerkingen beginnen met "/*" en eindigen met "*/". Optionele componenten worden gemarkeerd door ze tussen dubbele vierkante haken "" te plaatsen. Objecten van één byte die niet-interpreteerbare gegevens bevatten, hebben een ondoorzichtig type.

Een vector (eendimensionale array) is een stroom van homogene informatie-elementen. De vectorgrootte kan worden gespecificeerd op het moment van documentatie of kan ongespecificeerd blijven totdat het werk begint. In ieder geval bepaalt de lengte het aantal bytes, niet het aantal elementen in de vector. De specificatiesyntaxis voor een nieuw type T" dat een vector met vaste lengte is van type T is TT"[n] ;

Hier neemt T" n bytes in beslag in de informatiestroom, waarbij n een veelvoud is van de grootte van T. De lengte van de vector is niet opgenomen in de gecodeerde stroom.

In het volgende voorbeeld wordt Datum gedefinieerd als drie opeenvolgende bytes die niet door het protocol worden geïnterpreteerd, terwijl Data drie Datumvectoren zijn die uit negen bytes bestaan.

ondoorzichtige datum; /* drie niet-geïnterpreteerde bytes */ Datum Data; /* 3 opeenvolgende vectoren van 3 bytes */

vectoren met variabele lengte worden gedefinieerd door een subbereik van wettelijke lengten op te geven met behulp van de notatie . Bij het coderen gaat de werkelijke lengte vooraf aan de stroom bytes die de vector vormen. De lengte heeft de vorm van een getal en beslaat zoveel bytes als nodig is om de maximaal mogelijke vectorlengte (plafond) te specificeren. Een vector met variabele lengte en een veld met reële lengte gelijk aan nul is een lege vector.

T T" ;

In het volgende voorbeeld is de vereiste vector , die 300 tot 400 bytes van het ondoorzichtige type moet bevatten. Het mag niet leeg zijn. Veld werkelijke lengte neemt twee bytes in beslag, uint16 , genoeg om de waarde 400 weer te geven. Aan de andere kant kan langer maximaal 800 bytes aan gegevens of 400 uint16-elementen vertegenwoordigen, en kan het leeg zijn. De gecodeerde representatie ervan omvat twee bytes van het veld met werkelijke lengte, gevolgd door een vector. De lengte van de gecodeerde vector moet een even veelvoud zijn van de lengte van het enkele element (bijvoorbeeld: Een uint16-vector van 17 bytes zou illegaal zijn).

ondoorzichtig verplicht<300..400>;<0..800>/* lengteveld is 2 bytes, mag niet leeg zijn */ uint16 langer

;

/* 0 - 400 16-bit geheel getal zonder teken */

Het standaard numerieke gegevenstype is een niet-ondertekende byte (uint8). Steeds langere digitale datatypen worden gevormd uit een vaste reeks niet-ondertekende bytes die aan elkaar zijn gekoppeld. De volgende numerieke typen zijn vooraf gedefinieerd.

Al onze argumenten zijn gebaseerd op het feit dat het besturingssysteem Windows XP of hoger is (Vista, 7 of 8), waarop alle benodigde updates en patches zijn geïnstalleerd. Nu is er nog één voorwaarde: we hebben het over de nieuwste versies van browsers, en niet over ‘sferische Ognelis in een vacuüm’.

Schakel dus alle SSL-vakjes uit en vink alle beschikbare TLS-vakjes aan. Als alleen TLS 1.0 beschikbaar is, dan is het zo; er zijn meer actuele versies beschikbaar, het is beter om alleen deze te selecteren en TLS 1.0 uit te schakelen (en wees later niet verrast dat sommige sites niet via HTTPS openen). Klik vervolgens op de knoppen "Toepassen" en "OK".

Het is gemakkelijker met Opera - het geeft ons een echt banket van verschillende protocolversies: Extra/Algemene instellingen/Geavanceerd/Beveiliging/Beveiligingsprotocol. Wat zien we? De hele set, waarvan we de selectievakjes alleen voor TLS 1.1 en TLS 1.2 laten staan, waarna we op de knop "Details" klikken en daar alle regels uitschakelen behalve die die beginnen met "256 bit AES" - ze staan ​​helemaal einde. Aan het begin van de lijst staat een regel “256 bit AES ( Anoniem DH/SHA-256), schakel dit ook uit. Klik op "OK" en verheug u over de veiligheid.

Opera heeft echter één vreemde eigenschap: als TLS 1.0 is ingeschakeld, wordt deze versie van het protocol onmiddellijk gebruikt als het nodig is om een ​​beveiligde verbinding tot stand te brengen, ongeacht of de site recentere versies ondersteunt. Zoals: waarom moeite doen – alles is in orde, alles is beschermd. Als u alleen TLS 1.1 en 1.2 inschakelt, zal de browser eerst proberen de meer geavanceerde versie te gebruiken, en alleen als deze niet door de site wordt ondersteund, zal de browser overschakelen naar versie 1.1.

Maar de bolvormige Ognelis Firefox zal ons helemaal niet bevallen: Tools/Instellingen/Geavanceerd/Encryptie: het enige wat we kunnen doen is SSL uitschakelen, TLS is alleen beschikbaar in versie 1.0, er is niets aan te doen - we laten het met een vinkje staan.

Vergelijking leert echter het ergste: Chrome en Safari bevatten helemaal geen instellingen voor welk encryptieprotocol ze moeten gebruiken. Voor zover wij weten ondersteunt Safari geen TLS-versies die recenter zijn dan 1.0 in versies voor Windows OS, en aangezien de release van nieuwe versies voor dit besturingssysteem is stopgezet, zal dit ook niet gebeuren.

Chrome ondersteunt, voor zover wij weten, TLS 1.1, maar net als in het geval van Safari kunnen wij het gebruik van SSL niet weigeren. Er is geen manier om TLS 1.0 uit te schakelen in Chrome. Maar bij het daadwerkelijke gebruik van TLS 1.1 is er een grote vraag: het werd eerst ingeschakeld, vervolgens uitgeschakeld vanwege operationele problemen en, voor zover men kan beoordelen, nog niet weer ingeschakeld. Dat wil zeggen, er lijkt ondersteuning te zijn, maar deze lijkt te zijn uitgeschakeld en de gebruiker kan deze op geen enkele manier weer inschakelen. Hetzelfde verhaal geldt voor Firefox: het heeft feitelijk ondersteuning voor TLS 1.1, maar is nog niet beschikbaar voor de gebruiker.

Samenvatting van de bovenstaande multiletter. Wat zijn de algemene gevaren van het gebruik van verouderde versies van encryptieprotocollen? Het feit dat iemand anders toegang krijgt tot uw beveiligde verbinding met de site en toegang krijgt tot alle informatie “daar” en “daar”. Praktisch gezien krijgt hij volledige toegang tot de mailbox. e-mail, rekening in het klant-banksysteem, enz.

Het is onwaarschijnlijk dat u per ongeluk inbreekt in de beveiligde verbinding van iemand anders; we hebben het alleen over kwaadwillige acties. Als de kans op dergelijke acties klein is, of als de informatie die via een beveiligde verbinding wordt verzonden niet bijzonder waardevol is, hoeft u zich geen zorgen te maken en browsers te gebruiken die alleen TLS 1.0 ondersteunen.

Anders is er geen keus: alleen Opera en alleen TLS 1.2 (TLS 1.1 is slechts een verbetering ten opzichte van TLS 1.0 en neemt gedeeltelijk de beveiligingsproblemen over). Het is echter mogelijk dat onze favoriete sites TLS 1.2 niet ondersteunen :(

Goedemiddag, beste abonnees, ik ben er zeker van dat de overgrote meerderheid van jullie woorden als beveiligings- of encryptiecertificaat of SSL-certificaat heeft gehoord, en ik ben er zeker van dat de meesten van jullie zelfs hun doel kennen Ik zal je er tot in detail over vertellen met persoonlijke voorbeelden, alles is zoals het zou moeten zijn, daarna zul je op subtielere wijze alle veiligheidsgrenzen begrijpen die ons bieden SSL-certificaten Zonder hen is het nu onmogelijk om de moderne IT-wereld voor te stellen, met zijn bankoverschrijvingen, smime-e-mail of online winkels.

Wat zijn SSL en TLS

Secure Socket Layer of ssl is een technologie die is ontworpen om de toegang tot websites betrouwbaarder en veiliger te maken. Met een coderingscertificaat kunt u op betrouwbare wijze het verkeer beschermen dat wordt verzonden tussen de browser van de gebruiker en de webbron (server) waartoe de browser toegang heeft. Dit alles gebeurt met behulp van het https-protocol. Dit gebeurde allemaal nadat de snelle ontwikkeling van internet leidde tot een groot aantal sites en bronnen waarbij de gebruiker persoonlijke, persoonlijke gegevens moet invoeren:

• Wachtwoorden
• Creditcardnummers
• Correspondentie

Het zijn deze gegevens die een prooi zijn voor hackers. Hoeveel spraakmakende gevallen er al zijn gebeurd met de diefstal van persoonlijke informatie en hoeveel er nog meer zullen zijn, het SSL-coderingscertificaat is ontworpen om dit te minimaliseren. SSL-technologie is ontwikkeld door Netscape Communications en introduceerde later Transport Layer Security, of simpelweg TLS, een protocol gebaseerd op de SSL 3.0-specificatie. Zowel Secure Socket Layer als Transport Layer Security zijn ontworpen om de overdracht van gegevens tussen twee knooppunten via internet te garanderen.

SSL en TLS hebben geen fundamentele verschillen in hun werking, ze kunnen zelfs tegelijkertijd op dezelfde server worden gebruikt, dit gebeurt uitsluitend om de werking van nieuwe apparaten en browsers te garanderen, maar ook van verouderde apparaten, waar Transport Layer Beveiliging wordt niet ondersteund.

Als we naar het moderne internet kijken, wordt TLS gebruikt als serverbeveiligingscertificaat en encryptie, weet dit gewoon

Open bijvoorbeeld de Yandex-website, ik doe dit in Google Chrome, er staat een slotpictogram tegenover de adresbalk, klik erop. Hier staat geschreven dat de verbinding met de website beveiligd is en kunt u klikken voor meer details.

we zien meteen het Secure TLS-verbindingspictogram, zoals ik al zei, de meeste internetbronnen zijn gebaseerd op deze technologie. Laten we naar het certificaat zelf kijken. Klik hiervoor op Certificaat bekijken.

In het certificaatinformatieveld zien we het doel ervan:

1. Biedt identificatie vanaf een externe computer
2. Bevestigt de identiteit van uw computer aan de externe computer
3. 1.2.616.1.113527.2.5.1.10.2

Je moet altijd de geschiedenis kennen, hoe encryptie certificaat geëvolueerd en met welke versies het uitkwam. Omdat u dit en het werkingsprincipe kent, zal het gemakkelijker zijn om oplossingen voor problemen te vinden.

• SSL 1.0 > deze versie nooit de mensen heeft bereikt, kunnen de redenen zijn kwetsbaarheid hebben gevonden
• SSL 2.0 > deze versie van het SSL-certificaat werd geïntroduceerd in 1995, rond de millenniumwisseling, en bevatte ook een aantal beveiligingslekken die het bedrijf ertoe brachten Netscape-communicatie om te werken aan de derde versie van het encryptiecertificaat
• SSL 3.0> verving SSL 2.0 in 1996. Dit wonder begon zich te ontwikkelen en in 1999 kochten de grote bedrijven Master Card en Visa een commerciële licentie voor het gebruik ervan. TLS 1.0 verscheen vanaf versie 3.0
• TLS 1.0 > 99, een update voor SSL 3.0 genaamd TLS 1.0 is uitgebracht, nog eens zeven jaar gaan voorbij, het internet ontwikkelt zich en hackers staan ​​niet stil, de volgende versie is uitgebracht.
• TLS 1.1 > 04.2006 is het uitgangspunt, verschillende kritieke verwerkingsfouten zijn gecorrigeerd en bescherming tegen aanvallen is geïntroduceerd, waarbij de aaneenschakelingsmodus van cijfertekstblokken is gemaakt
• TLS 1.2 > verscheen in augustus 2008
• TLS 1.3 > komt eind 2016

Hoe TLS en SSL werken

Laten we begrijpen hoe de SSL- en TLS-protocollen werken. Laten we beginnen met de basis, dat is alles. netwerk apparaten hebben een duidelijk gedefinieerd algoritme om met elkaar te communiceren, het heet OSI, dat is opgedeeld in 7 niveaus. Het heeft een transportlaag die verantwoordelijk is voor de gegevenslevering, maar sindsdien OSI-model dit is een soort utopie, maar nu werkt alles volgens een vereenvoudigd TCP/IP-model, bestaande uit 4 lagen. TCP/IP-stack, nu de standaard voor gegevensoverdracht computernetwerken en het omvat, groot aantal Applicatielaagprotocollen die u bekend zijn:

De lijst kan heel lang worden voortgezet, er zijn meer dan 200 items. Hieronder ziet u een diagram van de netwerklagen.

Voor de duidelijkheid is hier een diagram van de SSL/TLS-stack.

Nu is alles hetzelfde in eenvoudige taal, omdat niet iedereen deze schema's begrijpt en het werkingsprincipe van ssl en tls niet duidelijk is. Wanneer u bijvoorbeeld mijn blogsite opent, krijgt u toegang via het http-toepassingsprotocol; wanneer u deze bezoekt, ziet de server u en brengt gegevens over naar uw computer. Als we ons dit schematisch voorstellen, dan zal het een eenvoudige matroesjkapop zijn, toegepast http-protocol, wordt op de tcp-ip-stack geplaatst.

Als de site een TLS-coderingscertificaat had, zou de protocolpop ingewikkelder zijn en er als volgt uitzien. Hier applicatieprotocol http, wordt in SSL/TLS geplaatst, die op zijn beurt in de TCP/IP-stack wordt geplaatst. Alles is hetzelfde, maar al gecodeerd, en als een hacker deze gegevens onderweg onderschept, ontvangt hij alleen digitaal afval, maar alleen de machine die de verbinding met de site tot stand heeft gebracht, kan de gegevens ontsleutelen.

Stappen om een ​​SSL/TLS-verbinding tot stand te brengen

Hier is nog een mooi en visueel diagram voor het creëren van een beveiligd kanaal.

Een SSL/TLS-verbinding tot stand brengen op netwerkpakketniveau

In de afbeelding geven zwarte pijlen de berichten weer die zijn verzonden in duidelijke tekst De blauwe zijn berichten die zijn ondertekend met een openbare sleutel, en de groene zijn berichten die zijn verzonden met behulp van bulkdata-encryptie en de MAC die de partijen tijdens het onderhandelingsproces zijn overeengekomen.

Welnu, in detail over elke fase van de uitwisseling van netwerkberichten van de SSL/TLS-protocollen.

• 1.KlantHallo> Het ClientHello-pakket biedt een lijst met ondersteunde protocolversies, ondersteunde coderingssuites in volgorde van voorkeur en een lijst met compressie-algoritmen (meestal NULL). Een willekeurige waarde van 32 bytes komt ook van de client, de inhoud ervan geeft de huidige tijdstempel aan, deze zal later worden gebruikt voor een symmetrische sleutel en een sessie-ID, die de waarde nul zal hebben, op voorwaarde dat er geen eerdere sessies waren.
• 2. ServerHallo> ServerHallo-pakket verzonden door de server, dit bericht bevat de geselecteerde optie voor het coderings- en compressie-algoritme. Er zal ook een willekeurige waarde van 32 bytes zijn (huidige tijdstempel), deze wordt ook gebruikt voor symmetrische sleutels. Als de huidige sessie-ID in ServerHello nul is, wordt de sessie-ID gemaakt en geretourneerd. Als het ClientHello-bericht de bij deze server bekende identificatie van de vorige sessie suggereerde, wordt het handshake-protocol uitgevoerd volgens een vereenvoudigd schema. Als de klant dit voorstelde onbekend bij de server sessie-ID, de server retourneert een nieuwe sessie-ID en het handshake-protocol wordt uitgevoerd volgens het volledige schema.
• 3.Certificaat (3)> binnen dit pakket de server verzendt zijn openbare sleutel(X.509-certificaat), komt het overeen met het sleuteluitwisselingsalgoritme in de geselecteerde coderingssuite. Over het algemeen kun je in het protocol zeggen: vraag om een ​​openbare sleutel in de DNS, een record zoals KEY/TLSA RR. Zoals ik hierboven schreef, wordt het bericht met deze sleutel gecodeerd.
• 4. ServerHallo Klaar > De server zegt dat de sessie normaal tot stand is gebracht.
• 5.ClientKeyExchange> De volgende stap is dat de client een pre-mastersleutel verzendt met behulp van willekeurige getallen (of huidige tijdstempels) tussen de server en de client. Deze sleutel(premastersleutel) wordt gecodeerd met de openbare sleutel van de server. Dit bericht kan alleen door de server worden gedecodeerd met behulp van de privésleutel. Nu berekenen beide deelnemers het gedeelde geheim hoofdsleutel sleutel van de premastersleutel.
• 6. ChangeCipherSpec - cliënt> de betekenis van het pakket is om aan te geven dat nu al het verkeer dat van de client komt, zal worden gecodeerd met behulp van het geselecteerde algoritme voor bulkgegevensversleuteling en een MAC zal bevatten die is berekend met behulp van het geselecteerde algoritme.
• 7. Afgewerkte klant> Dit bericht bevat alle berichten die zijn verzonden en ontvangen tijdens het handshake-protocol, behalve het bericht Voltooid. Het wordt gecodeerd met behulp van het bulen gehasht met behulp van het door de partijen overeengekomen MAC-algoritme. Als de server dit bericht (dat alle voorgaande berichten bevat) kan ontsleutelen en verifiëren met behulp van de sessiesleutel die hij onafhankelijk heeft berekend, dan was het gesprek succesvol. Als dit niet het geval is, onderbreekt de server op dit punt de sessie en verzendt een waarschuwingsbericht met enige (mogelijk niet-specifieke) informatie over de fout
• 8. ChangeCipherSpec - server> op de verpakking staat dat nu allemaal uitgaand verkeer Met van deze server, wordt gecodeerd.
• 9. Klaar - server>Dit bericht bevat alle berichten die zijn verzonden en ontvangen tijdens het handshake-protocol, behalve het bericht Voltooid
• 10. Protocol opnemen > Nu worden alle berichten gecodeerd met een SSL-beveiligingscertificaat

Hoe u een SSL-beveiligingscertificaat kunt verkrijgen

Laten we nu begrijpen waar we een coderingscertificaat kunnen krijgen, of hoe we een SSL-beveiligingscertificaat kunnen krijgen. Er zijn natuurlijk verschillende manieren, zowel betaald als gratis.

Gratis manier om een ​​tls-beveiligingscertificaat te verkrijgen

Deze methode omvat het gebruik van een zelfondertekend certificaat; het kan worden gegenereerd op elke webserver met de IIS- of Apache-rol. Als we moderne hosting overwegen, dan in controlepanelen, zoals:

• Directadmin
• ISPmanager
• Cpaneel

Dit is daar standaardfunctionaliteit. Het grootste voordeel van zelfondertekende encryptiecertificaten is dat ze gratis zijn en er kleven veel nadelen aan. Omdat niemand anders dan jij dit certificaat vertrouwt, heb je deze afbeelding waarschijnlijk wel eens gezien in browsers waarin de site klaagt over het beveiligingscertificaat.

Als je een zelfondertekend certificaat hebt dat uitsluitend voor interne doeleinden wordt gebruikt, dan is dit normaal, maar voor openbare projecten zal dit een groot minpunt zijn, omdat niemand het vertrouwt en je verliest groot aantal klanten of gebruikers die een beveiligingscertificaatfout in hun browser zien, zullen deze onmiddellijk sluiten.

Laten we eens kijken hoe u een SSL-beveiligingscertificaat kunt verkrijgen. Hiervoor wordt een verzoek voor het uitgeven van een certificaat gegenereerd, dit wordt een CSR-verzoek (Certificate Signing Request) genoemd. Meestal gebeurt dit bij een speciaal bedrijf in een webformulier, dat u een aantal vragen stelt over uw domein en uw bedrijf. Zodra u alles heeft ingevoerd, maakt de server twee sleutels: privé (gesloten) en openbaar (open). Ik wil u eraan herinneren dat de openbare sleutel niet vertrouwelijk is en daarom in het CSR-verzoek wordt opgenomen. Hier is een voorbeeld van een aanvraag voor een.

Al deze onbegrijpelijke gegevens kunnen eenvoudig worden geïnterpreteerd door speciale CSR Decoder-sites.

Voorbeelden van twee CSR Decoder-sites:

• http://www.sslshopper.com/csr-decoder.html
• http://certlogik.com/decoder/

Samenstelling van een MVO-verzoek

• Algemene naam: domeinnaam, die we beschermen met een dergelijk certificaat
• Organisatie: naam van de organisatie
• Organisatie-eenheid: organisatie-eenheid
• Plaats: stad waar het kantoor van de organisatie is gevestigd
• Staat: regio of staat
• Land: tweeletterige code, land van vestiging
• E-mail: contact-e-mailadres technisch beheerder of ondersteunende diensten

Zodra het is gegenereerd, kunt u beginnen met het aanvragen van een coderingscertificaat. De certificeringsinstantie controleert alle gegevens die u in het CSR-verzoek heeft opgegeven en als alles in orde is, ontvangt u uw SSL-beveiligingscertificaat en kunt u deze gebruiken voor https. Nu vergelijkt uw server automatisch het uitgegeven certificaat met het gegenereerde certificaat privé sleutel, kunt u allemaal client-server-verbindingsverkeer coderen.

Wat is een certificeringsinstantie

Wat is een CA - Certification Authority of certificeringsautoriteit, lees de link aan de linkerkant, daar heb ik het uitgebreid besproken.

Welke gegevens bevat een SSL-certificaat?

Het certificaat slaat de volgende informatie op:

• volledige (unieke) naam van de certificaateigenaar
• de publieke sleutel van de eigenaar
• Datum van uitgifte van het SSL-certificaat
• vervaldatum van het certificaat
• volledige (unieke) naam van de certificeringsinstantie
• digitale handtekening van de uitgever

Welke soorten SSL-encryptiecertificaten zijn er?

Er zijn drie hoofdtypen beveiligingscertificaten:

• Domeinvalidatie - DV > Dit is een coderingscertificaat dat alleen de domeinnaam van de bron bevestigt
• Organisatievalidatie - OV > Dit is een encryptiecertificaat dat de organisatie en het domein verifieert
• Extendet Validation - EV > Dit is een encryptiecertificaat met uitgebreide validatie

Doel van Domeinvalidatie - DV

En dus zijn encryptiecertificaten die alleen het domein van een bron bevestigen de meest voorkomende certificaten op het netwerk; ze worden sneller en automatisch gemaakt. Wanneer u een dergelijk beveiligingscertificaat moet controleren, wordt er een e-mail verzonden met een hyperlink, waarop u klikt en de uitgifte van het certificaat bevestigt. Ik wil er rekening mee houden dat de brief naar u wordt verzonden, maar niet het bevestigde e-mailadres (goedkeurder-e-mailadres) dat is opgegeven bij het bestellen van het coderingscertificaat.

Goedkeurder-e-mail stelt ook eisen, het is logisch dat als u versleutelingscertificaten voor een domein bestelt, dan e-mail moet ervan afkomstig zijn, en niet van mail of rambler, of het moet worden gespecificeerd in whois-domein en nog een vereiste: de naam van het e-mailadres van de goedkeurder moet volgens dit sjabloon zijn:

• webmaster@uwdomein
• postmaster@uw domein
• hostmaster@uwdomein
• beheerder@uw domein
• beheerder@

Meestal gebruik ik de mailbox postmaster@uw domein

Een tls-ssl-certificaat dat een domeinnaam bevestigt, wordt uitgegeven wanneer de CA heeft gevalideerd dat de klant rechten heeft op de domeinnaam; al het andere met betrekking tot de organisatie wordt niet weergegeven in het certificaat.

Doel Organisatievalidatie - OV

TLS-ssl-encryptiecertificaten bevatten de naam van uw organisatie, een particulier kan deze eenvoudigweg niet ontvangen, ze worden verzonden om een ​​individuele ondernemer te registreren. Het duurt 3 tot tien werkdagen, het hangt allemaal af van het certificeringscentrum dat het zal afgeven.

Doel Extendet Validatie - EV

En dus stuurde u CSR een verzoek om een ​​encryptiecertificaat voor uw organisatie uit te geven, CA begint te controleren of de IP-hoorns en -hoeven echt bestaan, zoals bij CSR, en of het in de bestelling gespecificeerde domein erbij hoort.

• Ze kunnen zien of er een organisatie in de internationale Gouden Gids staat, die niet weet wat het is, dan dit telefoongidsen in Amerika. Niet alle CA's controleren op deze manier.
• Ze kijken naar de whois van het domein van uw organisatie; als alle certificeringsinstanties geen woord over uw organisatie in de whois vinden, hebben ze een garantieverklaring van u nodig dat het domein van u is.
• Certificaat van staatsregistratie Eengemaakt staatsregister van individuele ondernemers of een eengemaakt staatsregister van juridische entiteiten
• Zij kunnen uw telefoonnummer verifiëren door bij u een account aan te vragen telefoonmaatschappij, waarin het nummer verschijnt.
• Ze kunnen op dit nummer bellen en de beschikbaarheid van het bedrijf controleren. Ze zullen de persoon die door de beheerder is opgegeven in de bestelling vragen om de telefoon op te nemen, dus zorg ervoor dat de persoon Engels spreekt.

Het encryptiecertificaat zelf wordt uitgebreid Validatie is EV, het duurst en het blijkt het moeilijkst te zijn, door de manier waarop ze een groene balk hebben, heb je het zeker gezien, dit is wanneer je op de site bent adresbalk de bezoeker ziet een groene lijn met de naam van de organisatie. Hier is een voorbeeld van een bankklant van Sberbank.

Uitgebreide encryptiecertificaten (extendet Validation - EV) hebben het grootste vertrouwen en het is logisch dat je meteen ziet dat het bedrijf bestaat en voldoet aan de strenge eisen voor het uitgeven van een certificaat. SSL-certificaten Extendet Validatio worden alleen door CA's uitgegeven als aan twee vereisten wordt voldaan die de organisatie bezit het vereiste domein en dat het zelf in de natuur bestaat. Bij het uitgeven van EV SSL-certificaten zijn er strenge regels die de eisen beschrijven voordat een EV-certificaat wordt uitgegeven

• Moet de juridische, fysieke en operationele activiteiten van de entiteit beoordelen
• Controle van de organisatie en haar documenten
• Domeineigendom, organisatie
• Controleer of de organisatie volledig geautoriseerd is om een ​​EV-certificaat af te geven

SSL-certificaten Extendet Validatio worden in ongeveer 10-14 dagen uitgegeven, geschikt voor zowel non-profitorganisaties als overheidsinstanties.

Soorten SSL-coderingscertificaten

Volgende belangrijke kwestie, zal er zijn welke soorten SSL-TLS-encryptiecertificaten er bestaan, en hun verschillen en kosten.

• Reguliere SSL-certificaten > dit zijn de meest voorkomende certificaten, ze worden automatisch gedaan, om alleen het domein te bevestigen. Ze kosten gemiddeld 18-22 dollar.
• SGC-certificaten > zijn SSL - TLS-certificaten met ondersteuning voor een hoger coderingsniveau. Ze zijn voornamelijk bedoeld voor oudere browsers die alleen 40-56 bit-codering ondersteunen. SGC verhoogt het encryptieniveau met geweld naar 128 bits, wat meerdere malen hoger is. Terwijl XP zijn einde bereikt de afgelopen jaren, binnenkort zijn SGC-encryptiecertificaten niet meer nodig. Dit wonder kost ongeveer 300 honderd dollar per jaar.
• Wildcard-certificaten > Vereist voor subdomeinen van uw hoofddomein. Een eenvoudig voorbeeld is mijn blogsite. Als ik een Wildcard koop, kan ik deze op alle domeinen van het vierde niveau op mijn site plaatsen, *.site. De kosten van Wildcard-coderingscertificaten variëren afhankelijk van het aantal subdomeinen, vanaf 190 dollar.
• SAN-certificaten > Stel dat u één server heeft, maar deze host er meerdere verschillende domeinen, hier kun je een SAN-certificaat aan de server hangen en alle domeinen zullen er gebruik van maken, het kost vanaf 400 dollar per jaar.
• EV-certificaten > over verlengde, alles hebben we hierboven al besproken, ze kosten vanaf 250 dollar per jaar.
• Certificaten die IDN-domeinen ondersteunen

lijst met certificaten die dergelijke ondersteuning bieden, IDN-domeinen:

• Thawte SSL123-certificaat
• Thawte SSL-webserver
• Symantec beveiligde site
• Thawte SGC SuperCerts
• Thawte SSL-webserver-wildcard
• Thawte SSL-webserver met EV
• Symantec Secure Site Pro
• Symantec beveiligde site met EV
• Symantec Secure Site Pro met EV

Handige hulpprogramma's:

1. OpenSSL is het meest gebruikte hulpprogramma voor het genereren van een publieke sleutel (certificaataanvraag) en een private sleutel.
   http://www.openssl.org/
2. CSR Decoder is een hulpprogramma voor het controleren van de CSR en de gegevens die deze bevat. Ik raad aan deze te gebruiken voordat u een certificaat bestelt.
   http://www.sslshopper.com/csr-decoder.html of http://certlogik.com/decoder/
3. DigiCert Certificate Tester - een hulpprogramma waarmee u de geldigheid van het certificaat zelf kunt controleren
   http://www.digicert.com/help/?rid=011592
   http://www.sslshopper.com/ssl-checker.html

In toekomstige artikelen zullen we de CA zelf configureren en in de praktijk gebruik maken van SSL/TLS-encryptiecertificaten.

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 operatiekamers Windows-systemen Er wordt gebruik gemaakt van het CryptoPro CSP-programma: een reeks cryptografische hulpprogramma's voor het genereren van een elektronische handtekening 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.

Hoofdstukken uit het prachtige boek “High Performance Browser Networking” van Ilya Grigorik. De vertaling werd uitgevoerd als onderdeel van het schrijven cursus werk, daarom is het erg gratis, maar toch zal het nuttig zijn voor degenen die weinig idee hebben wat TLS is en waarmee ze het eten.

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 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. Huidige versie Het huidige protocol is TLS 1.2, uitgebracht in augustus 2008.

Zoals gezegd is TLS ontworpen om via TCP te werken, maar het is ontworpen om via datagramprotocollen zoals UDP (User Datagram Protocol) te werken. speciale versie TLS, 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 (Message Authentication Code), waarvan het creatie-algoritme een cryptografische hashfunctie in één richting is (in feite - controlesom), waarvan de sleutels bekend zijn bij beide communicatiedeelnemers. 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 TCP-instellingen, stuurt de client een platte tekstspecificatie naar de server (namelijk de protocolversie die hij wil gebruiken, ondersteunde versleutelingsmethoden, enz.).
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. Protocolversie en coderingsmethode ingeschakeld op dit moment als goedgekeurd worden beschouwd, verifieert de client het verzonden certificaat en initieert RSA- of Diffie-Hellman-sleuteluitwisseling, afhankelijk van de geconfigureerde 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.

Ook beschikbaar extra uitbreiding Handshake-procedure, die TLS False Start wordt genoemd. 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

Op huidige moment, 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 initiële installatie verbindingen. 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

Beginnend vanaf de eerste openbare versie protocol (SSL 2.0) kan de server, als onderdeel van de TLS Handshake (namelijk het initiële ServerHello-bericht), een sessie-ID van 32 bytes genereren en verzenden. 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, wordt setting gemeenschappelijke verbinding vindt plaats volgens het vereenvoudigde algoritme dat in de figuur wordt weergegeven. Zo niet, dan is het verplicht volledige versie TLS-handdruk.

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 ervan niet wordt aangetast, omdat voorheen ongecompromitteerde gegevens uit de vorige sessie worden gebruikt.

Er is echter een praktische beperking: aangezien de server over iedereen gegevens moet opslaan open sessies, dit leidt tot een probleem met populaire bronnen, die tegelijkertijd door duizenden en miljoenen klanten worden aangevraagd.

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 cliënt initiële installatie verbinding aangegeven dat deze deze technologie ondersteunt, stuurt de server tijdens TLS Handshake de client een zogenaamd Session Ticket - sessieparameters gecodeerd met de privésleutel van 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. Gedetailleerd diagram TLS False Start 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, sollicitatiegegevens zijn mogelijk al verzonden, en zo noodzakelijke controles parallel kan worden gedaan. 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. IN algemeen beeld De vertrouwensketen ziet 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 gehele certificeringsprocedure is gecompromitteerd). Voor dit doel bevatten echtheidscertificaten speciale instructies over het controleren van hun relevantie. 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”). Elke certificeringsinstantie heeft dat deze lijst, die een eenvoudige lijst vertegenwoordigt serienummers 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. Uiteraard vermindert dit de belasting doorvoer netwerk, maar geeft tegelijkertijd aanleiding tot 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.