SSL ( Eng. Secure Sockets Layer - nivån av säkra sockets ) är ett kryptografiskt protokoll som innebär en säkrare anslutning. Den använder asymmetrisk kryptografi för att autentisera utbytesnycklar, symmetrisk kryptering för att bevara konfidentialitet, meddelandeautentiseringskoder för meddelandeintegritet. Protokollet användes flitigt för snabbmeddelanden och röst över IP ( Voice over IP - VoIP ) i applikationer som e- post , Internetfax, etc. 2014 rapporterade den amerikanska regeringen om en sårbarhet i den nuvarande versionen av protokollet [1] . SSL bör fasas ut till förmån för TLS (se CVE-2014-3566).
SSL utvecklades ursprungligen av Netscape Communications för att lägga till HTTPS-protokollet i deras Netscape Navigator -webbläsare . Därefter, på basis av SSL 3.0-protokollet, utvecklades och antogs RFC-standarden , som fick namnet TLS .
SSL-protokollet ger säker kommunikation genom följande två element:
SSL använder asymmetrisk kryptografi för att autentisera utbytesnycklar, ett symmetriskt chiffer för att upprätthålla konfidentialitet och meddelandeautentiseringskoder för meddelandeintegritet.
SSL-protokollet tillhandahåller en "säker kanal" som har tre huvudegenskaper:
Fördelen med SSL är att det är oberoende av applikationsprotokollet. Applikationsprotokoll ( HTTP , FTP , TELNET , etc.) kan arbeta ovanpå SSL-protokollet på ett helt transparent sätt, det vill säga SSL kan förhandla om krypteringsalgoritmen och sessionsnyckeln och autentisera servern innan applikationen tar emot eller sänder meddelandets första byte.
SSL-protokollet utvecklades ursprungligen av Netscape Communications . Version 1.0 släpptes aldrig för allmänheten. Version 2.0 släpptes i februari 1995, men innehöll många säkerhetsbrister som ledde till utvecklingen av SSL version 3.0 [2] . SSL version 3.0, släppt 1996, var grunden för skapandet av TLS 1.0, en Internet Engineering Task Force ( IETF ) protokollstandard som först definierades i RFC 2246 i januari 1999. Visa , Master Card , American Express och många andra organisationer har licens att använda SSL-protokollet för kommersiella ändamål på Internet. Således är SSL utbyggbart i enlighet med projektet för att stödja framåt- och bakåtkompatibilitet och förhandling mellan anslutningar i ett peer-to-peer-nätverk. Från och med mars 2011, enligt RFC 6176, får TLS-klienter inte använda SSL 2.0-protokollet när de begär en anslutning till en server, och servrar måste avvisa sådana förfrågningar.
TLS 1.0 definierades först i RFC 2246 i januari 1999 som en uppdatering till SSL 3.0. Som det står i RFC är "skillnaderna mellan det här protokollet och SSL 3.0 inte kritiska, men de är betydande för uppkomsten av inkompatibiliteter mellan TLS 1.0 och SSL 3.0." TLS 1.0 inkluderar metoder för att implementera en TLS till SSL 3.0-anslutning skulle försvaga säkerheten.
TLS 1.1 introducerades i RFC 4346 i april 2006 [3] . Detta var en uppdatering till TLS version 1.0. Viktiga ändringar i den här versionen inkluderar:
TLS 1.2 tillkännagavs i RFC 5246 i augusti 2008. Den är baserad på den tidigare föreslagna versionen av TLS 1.1.
TLS 1.3 erkändes som en standard i RFC 8446 i augusti 2018.
SSL använder en miljö med flera lager för att säkerställa säkerheten för informationsutbytet. Kommunikationskonfidentialitet är närvarande på grund av att en säker anslutning är öppen endast för riktade användare.
SSL-protokollet sitter mellan två protokoll: protokollet som klientprogrammet använder (HTTP, FTP, LDAP, TELNET, etc.) och TCP/IP-transportprotokollet. SSL skyddar data genom att fungera som ett filter för båda sidor och skickar den vidare till transportlagret [4] [5] .
Driften av protokollet kan delas in i två nivåer:
Det första lagret består i sin tur av tre underprotokoll:
Anslutningshandskakningsprotokollet används för att förhandla sessionsdata mellan klienten och servern. Sessionsdata inkluderar:
Anslutningshandskakningsprotokollet producerar en datautbyteskedja, som i sin tur påbörjar autentiseringen av parterna och kommer överens om kryptering, hashning och komprimering. Nästa steg är autentiseringen av deltagare, som också utförs av anslutningsbekräftelseprotokollet.
Förändringsprotokollet för chifferparameter används för att ändra nyckeldata (nyckelmaterial) - information som används för att skapa krypteringsnycklar. Protokollet består av bara ett meddelande, där servern säger att avsändaren vill ändra nyckeluppsättningen.
Varningsprotokollet innehåller ett meddelande som indikerar för parterna en förändring i status eller ett möjligt fel. Vanligtvis skickas en varning när anslutningen stängs och ett ogiltigt meddelande tas emot, meddelandet kan inte dekrypteras eller användaren avbryter operationen.
SSL-protokollet använder certifikat för att verifiera att en offentlig nyckel tillhör dess verkliga ägare. Sätt att få ett SSL-certifikat:
Självsignerat certifikat - ett certifikat skapat av användaren själv - i detta fall är certifikatutfärdaren densamma som ägaren av certifikatet. Ett "tomt" certifikat är ett certifikat som innehåller fiktiv information som används som tillfälligt för att sätta upp SSL och verifiera dess funktionalitet i en given miljö.
Bland SSL-certifikat finns domänvaliderade certifikat och utökade valideringscertifikat . Den senare associerar ett domännamn med en verklig person eller enhet.
Det finns fyra huvudnyckelgenereringsalgoritmer: RSA , Fixed Diffie-Hellman, Ephemeral Diffie-Hellman, Anonymous Diffie-Hellman
rsaNär en privat RSA-nyckel "försvinner" får kryptoanalytikern som tar emot den möjlighet att dekryptera alla inspelade tidigare meddelanden och framtida meddelanden. Implementeringen av nyckelutbytet i RSA är envägs: all nödvändig information för att bilda en symmetrisk nyckel, som skapas under handskakningsstadiet, skickas till servern och krypteras med serverns publika nyckel. Att avslöja den privata nyckeln gör det möjligt att ta reda på den symmetriska nyckeln för denna session.
Diffie-HellmanDen fasta Diffie-Hellman- mekanismen använder en permanent publik nyckel, som är registrerad i servercertifikatet. Detta innebär också att klienten vid varje ny anslutning tillhandahåller sin del av nyckeln. Efter nyckelutbytet bildas en ny symmetrisk nyckel för att utbyta information för den aktuella sessionen. Genom att avslöja serverns privata nyckel kan kryptoanalytikern dekryptera tidigare inspelade meddelanden såväl som alla framtida meddelanden. Detta möjliggörs av själva mekanismen. Eftersom kryptoanalytikern känner till serverns privata nyckel kommer han att kunna ta reda på den symmetriska nyckeln för varje session, och inte ens det faktum att nyckelgenereringsmekanismen är tvåvägs kommer inte att hjälpa.
Den anonyma Diffie-Hellman- mekanismen ger inga garantier för integritet, eftersom informationen överförs okrypterad.
Det enda alternativet som garanterar säkerheten för tidigare och framtida meddelanden är Ephemeral Diffie-Hellman . Skillnaden jämfört med de tidigare diskuterade metoderna är att med varje ny anslutning genereras en engångsnyckel av servern och klienten. Således, även om kryptoanalytikern får den aktuella privata nyckeln, kommer han att kunna dekryptera endast den aktuella sessionen, men inte tidigare eller framtida sessioner.
Det finns två huvudsakliga sätt att kryptera data: symmetrisk kryptering (delad hemlig nyckel) och asymmetrisk kryptering (offentlig/privat nyckelpar).
SSL använder både asymmetrisk och symmetrisk kryptografi.
Kärnan i asymmetrisk kryptering är att ett par nycklar används. En av nycklarna kallas offentlig (som regel publiceras den i själva ägarens certifikat), och den andra nyckeln kallas privat - den hålls hemlig. Båda nycklarna används i par: den offentliga nyckeln används för att kryptera data och den privata nyckeln används för att dekryptera den. Denna relation låter dig göra två viktiga saker.
RSA är en av de mest använda asymmetriska krypteringsalgoritmerna.
Med symmetrisk kryptering används samma nyckel för att både kryptera och dekryptera data. Om parterna vill utbyta krypterade meddelanden på ett säkert sätt måste båda parter ha samma symmetriska nycklar. Denna typ av kryptering används för stora mängder data (eftersom symmetrisk kryptering är snabbare). Vanligt använda algoritmer är DES , 3-DES , RC2 , RC4 och AES .
SSL-protokollet använder offentlig nyckelkryptering för ömsesidig autentisering av klienten och servern (med digital signaturteknik), samt för att generera en sessionsnyckel, som i sin tur används av snabbare symmetriska kryptografialgoritmer för att kryptera en stor mängd data .
Hashvärdet är en meddelandeidentifierare, dess storlek är mindre än storleken på det ursprungliga meddelandet. De mest kända hashalgoritmerna är MD5 (Message Digest 5) som producerar ett 128-bitars hashvärde, SHA-1 (Secure Hash Algorithm) som producerar ett 160-bitars hashvärde, SHA-2 och SHA-3 . Resultatet av hashalgoritmen är ett värde som används för att kontrollera dataöverföringens integritet.
Protokollet på inspelningslagernivån tar emot krypterad data från klientprogrammet och överför den till transportlagret. Inspelningsprotokollet tar data, delar upp den i block och utför kryptering (dekryptering) av data. Samtidigt används aktivt den information som överenskommits vid bekräftelsen av uppgifterna.
SSL-protokollet tillåter symmetrisk nyckelkryptering med antingen blockchiffer eller strömchiffer . Blockchiffer används ofta i praktiken. Funktionsprincipen för ett blockchiffer är att mappa ett block av klartext till samma block av chiffertext. Detta chiffer kan representeras som en tabell som innehåller 2 128 rader, varje rad innehåller ett klartextblock M och dess motsvarande chiffertextblock C. En liknande tabell finns för varje nyckel.
Kryptering kan representeras som en funktion
C = E ( Nyckel , M ), där M är den ursprungliga datan, Nyckeln är krypteringsnyckeln, C är den krypterade datan.
Som regel är blocken små (vanligtvis 16 byte), så frågan uppstår: hur krypterar man ett långt meddelande?
Det första läget för sådan kryptering kallas ECB (Electronic Codebook) eller enkelt ersättningsläge. Dess kärna är att vi delar upp det ursprungliga meddelandet i block (för samma 16 byte) och krypterar varje block separat. Det här läget används dock sällan på grund av problemet med att bevara källtextens statistiska egenskaper: 2 identiska block av klartext efter kryptering kommer att förvandlas till två identiska block av chiffertext.
För att lösa detta problem utvecklades ett andra läge - CBC (Cipher-block chaining). I detta fall XOReds varje nytt chiffertextblock med det föregående krypteringsresultatet. Det första blocket XORed med någon initieringsvektor (initieringsvektor, IV). Men all ovanstående teori är utvecklad för ett stort objekt, medan SSL, som är ett kryptografiskt protokoll, måste kryptera en serie paket. I en sådan situation finns det två sätt att tillämpa CBC:
Vid design av applikationer implementeras SSL "under" alla andra applikationslagerprotokoll som HTTP , FTP , SMTP , NNTP och XMPP , vilket ger "transparens" för dess användning. Historiskt sett har SSL främst använts med tillförlitliga transportprotokoll såsom Transmission Control Protocol (TCP). Det har dock också implementerats med datagramtransportprotokoll som User Datagram Protocol (UDP) och Datagram Control Protocol (DCCP), vars användning har standardiserats, vilket ger upphov till termen Datagram Transport Layer Security (DTLS).
Den frekventa användningen av SSL-protokollet har lett till bildandet av HTTPS -protokollet (Hypertext Transfer Protocol Secure), som stöder kryptering. Data som överförs över HTTPS- protokollet "packas" i det kryptografiska SSL- eller TLS -protokollet , vilket säkerställer skyddet av dessa data. Denna skyddsmetod används flitigt i webbvärlden för applikationer där anslutningssäkerhet är viktigt, såsom betalningssystem. Till skillnad från HTTP har HTTPS som standard TCP- port 443.
Webbplatsstöd för protokollet [6]| Protokollversion | Säkerhet | Webbplatssupport |
|---|---|---|
| SSL 2.0 | Inte | 4,9 % |
| SSL 3.0 | Inte | 16,6 % |
| TLS 1.0 | Kanske | 94,7 % |
| TLS 1.1 | Ja | 82,6 % |
| TLS 1.2 | 85,5 % |
Från och med början av 2017 är alla större webbläsare som stöder SSL/TLS:
Webbläsare som stöder SSL/TLS| Webbläsare | Plattformar | TLS 1.0 | TLS 1.1 | TLS 1.2 | TLS 1.3 |
|---|---|---|---|---|---|
| Chrome 1-21 | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Ja | Inte | Inte | Inte |
| Chrome 29-53 | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10) | Ja [7] | Ja [7] | Ja [8] | Inte |
| Chrome 58+ | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10) | Ja | Ja | Ja | Ja |
| Firefox 1-27 | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Ja [9] | Nej [10] | Nej [11] | Inte |
| Firefox 27-53 | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Ja | Ja | Ja | Inte |
| Firefox 54+ | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Ja | Ja | Ja | Ja |
| IE6 | Windows XP) | Ja | Inte | Inte | Inte |
| IE 7 - 8 | Windows (XP, Vista) | Ja | Inte | Inte | Inte |
| IE 8 - 9 | Windows 7 | Ja | Ja | Ja | Inte |
| IE9 | Windows Vista | Ja | Inte | Inte | Inte |
| IE 10+ | Windows (7, 8) | Ja | Ja | Ja | Inte |
| Kant 12-15 | Windows 10 | Ja | Ja | Ja | Inte |
| Opera 5-7 | Linux, Mac OS X, Windows | Ja [12] | Inte | Inte | Inte |
| Opera 8-9 | Linux, Mac OS X, Windows | Ja | Ja [13] | Inte | Inte |
| Opera 10+ | Linux, Mac OS X, Windows | Ja | Ja | Ja | Inte |
| Opera 44+ | Linux, Mac OS X, Windows | Ja | Ja | Ja | Ja |
| Safari 4 | Mac OS X, Windows (XP, Vista, 7), iOS 4.0 | Ja | Inte | Inte | Inte |
| Safari 5 | Mac OS X, Windows (XP, Vista, 7) | Ja | Inte | Inte | Inte |
| Safari 7-10 | iOS 5.0- | Ja | Ja | Ja | Inte |
Specifikationer:
Inledningsvis utvecklades SSL-baserade virtuella privata nätverk ( VPN ) som en kompletterande och alternativ fjärråtkomstteknologi baserad på IPsec VPN. Faktorer som tillräcklig tillförlitlighet och låg kostnad gjorde dock denna teknik attraktiv för VPN-organisationer. SSL används också flitigt i e-post.
Den vanligaste implementeringen av SSL är det kryptografiska paketet OpenSSL med öppen källkod , baserat på SSLeay skrivet av Eric Young. Den senaste versionen av OpenSSL stöder SSLv3. Paketet är utformat för att skapa och hantera olika typer av certifikat . Den innehåller också ett bibliotek för SSL-stöd av olika program. Biblioteket används till exempel av SSL-modulen i den gemensamma Apache HTTP -servern .
All data i SSL skickas i form av poster (records) - objekt som består av en header och en viss mängd data. Varje posthuvud innehåller 2 eller 3 bytes längdkod. Om den mest signifikanta biten i den första byten av postlängdskoden är 1, så har posten ingen utfyllnad och den totala rubriklängden är 2 byte, annars innehåller posten en utfyllnad och den totala rubriklängden är 3 byte. I fallet med en lång (3 byte) rubrik har den näst mest signifikanta biten i den första byten en speciell betydelse. Om det är lika med 0 - posten är informativ, om den är lika med 1 - är posten en säkerhetsflykt. Postlängdskoden inkluderar inte antalet rubrikbyte. För en 2-byte header beräknas dess längd enligt följande:
RECORD-LENGTH = ((byte[0] & 0x7F) << 8) | byte[1];
Här är byte[0] den första mottagna byten och byte[1] är den andra mottagna byten.
För en 3-byte header beräknas postlängden enligt följande:
RECORD-LENGTH = ((byte[0] & 0x3F) <<8) | byte[1];
IS-ESCAPE = (byte[0] & 0x40) !=0;
PADDING = byte[2];
PADDING - värdet anger antalet byte som lagts till av avsändaren till den ursprungliga posten. Utfyllnadsdata används för att göra postlängden till en multipel av chifferblockstorleken. Avsändaren lägger till PADDING efter den givna datan och krypterar sedan allt eftersom längden på denna array är en multipel av blockstorleken för chifferet som används. Eftersom mängden överförd data är känd, kan meddelandehuvudet bildas med hänsyn till mängden PADDING . Mottagaren av meddelandet dekrypterar hela datafältet och får den ursprungliga informationen och beräknar sedan det sanna värdet av RECORD-LENGTH , medan PADDING tas bort från "data"-fältet.
SSL-postdatadelen består av tre komponenter:
MAC-DATA - meddelandeautentiseringskod
MAC-SIZE - funktion av algoritmen som används för att beräkna hashsumman
ACTUAL-DATA - faktiskt överförd data eller meddelandedatafält
PADDING-DATA - PADDING data (med blockkryptering)
MAC-DATA = HASH [ HEMLIGT , AKTUELL DATA , UPPFYLLNINGSDATA , SEKVENSNUMMER ]
Här skickas SECRET till hashfunktionen först, följt av ACTUAL-DATA och PADDING-DATA , följt av SEQUENCE-NUMBER , ett sekvensnummer.
Värdet på SECRET beror på vem som skickar meddelandet. Om klienten gör det är SECRET lika med CLIENT-WRITE-KEY . Om klienten tar emot meddelandet är SECRET lika med CLIENT-READ-KEY .
Sekvensnumret är en 32-bitars kod som skickas till hashfunktionen som 4 byte med hjälp av nätverksordningen från hög till låg. Sekvensnumret är räknaren för servern eller klienten. För varje sändningsriktning används ett par räknare - för avsändaren och för mottagaren; varje gång ett meddelande skickas ökar räknaren med 1.
Mottagaren av meddelandet använder det förväntade sekvensnummervärdet för att skicka MAC (hashtypen bestäms av parametern CIPHER-CHOICE ). Det beräknade MAC-DATA- värdet måste matcha det överförda värdet. Om jämförelsen misslyckas anses meddelandet vara korrupt, vilket resulterar i ett fel som gör att anslutningen stängs.
Den sista matchningskontrollen utförs när ett blockchiffer används. Mängden data i meddelandet ( RECORD-LENGTH ) måste vara en multipel av chifferblockets storlek. Om detta villkor inte uppfylls anses meddelandet vara korrupt, vilket resulterar i en frånkoppling.
För en 2-byte header är den maximala meddelandelängden 32767 byte, för en 3-byte header är den 16383 byte. SSL-konversationsprotokollmeddelanden måste motsvara enskilda SSL-protokollposter, och programprotokollmeddelanden kan uppta flera SSL-poster.
SSL-konversationsprotokollet innehåller 2 huvudfaser.
Fas 1Den första fasen används för att upprätta en konfidentiell kommunikationskanal.
Denna fas initierar anslutningen när båda kamraterna utbyter "hej"-meddelanden. Klienten skickar ett KLIENT-HEJ- meddelande . Servern tar emot detta meddelande, bearbetar det och skickar tillbaka ett SERVER-HEJ- meddelande .
Vid det här laget har både servern och klienten tillräckligt med information för att veta om en ny huvudnyckel behövs. Om nyckeln inte behövs går servern och klienten till fas 2.
När en ny huvudnyckel behöver skapas innehåller serverns SERVER-HEJ- meddelande redan tillräckligt med data för att klienten ska kunna generera en huvudnyckel . Dessa data inkluderar serverns signerade certifikat, en lista med baschiffer och ett anslutnings-ID (ett slumptal som genereras av servern och som används under hela sessionen). Efter att klienten genererat en huvudnyckel skickar den ett CLIENT-MASTER-KEY- meddelande till servern eller ett felmeddelande när klienten och servern inte kan komma överens om ett baschiffer.
Efter att ha fastställt huvudnyckeln skickar servern ett SERVERVERIFY- meddelande till klienten som autentiserar servern.
Fas 2 kallas för autentiseringsfasen. Eftersom servern redan är autentiserad i den första fasen, autentiseras klienten i den andra fasen. Servern skickar en begäran till klienten och om klienten har den nödvändiga informationen skickar den ett positivt svar, om inte, ett felmeddelande. När en peer har autentiserat en annan peer, skickar den ett färdigt meddelande . I fallet med en klient innehåller CLIENT-FINISHED-meddelandet en krypterad form av CONNECTION-ID som servern måste verifiera. Om verifieringen misslyckades skickar servern ett ERROR- meddelande .
När en av peers har skickat ett färdigt meddelande måste den acceptera meddelanden tills den får ett färdigt meddelande från den andra peeren, och först när både peers har skickat och tagit emot färdiga meddelanden kommer SSL-konversationsprotokollet att avslutas. Från detta ögonblick börjar applikationsprotokollet att fungera.
Nedan finns flera alternativ för att utbyta meddelanden inom SSL-konversationsprotokollet. Klienten är C , servern är S. "{smth}nyckel" betyder att "smth" är krypterad med en nyckel.
I avsaknad av ett sessions-ID| klient-hej | C®S: | utmaning, chiffer_specifikationer |
| server-hej | S ® C: | anslutnings-id, server_certifikat, chifferspecifikationer |
| klient-huvudnyckel | C®S: | {master_key}server_public_key |
| klient-finish | C®S: | {connection-id}client_write_key |
| server-verifiera | S ® C: | {challenge}server_skrivnyckel |
| server-finish | S ® C: | {new_session_id}server_skrivnyckel |
| klient-hej | C®S: | challenge, session_id, cipher_specs |
| server-hej | S ® C: | anslutnings-id, session_id_hit |
| klient-finish | C®S: | {connection-id}client_write_key |
| server-verifiera | S ® C: | {challenge}server_skrivnyckel |
| server-finish | S ® C: | {session_id}server_skrivnyckel |
| klient-hej | C®S: | challenge, session_id, cipher_specs |
| server-hej | S ® C: | anslutnings-id, session_id_hit |
| klient-finish | C®S: | {connection-id}client_write_key |
| server-verifiera | S ® C: | {challenge}server_skrivnyckel |
| Begär-certifikat | S ® C: | {auth_type ,challenge'}server_skrivnyckel |
| kundcertifikat | C®S: | {cert_type,client_cert,response_data}client_write_key |
| server-finish | S ® C: | {new_session_id}server_skrivnyckel |
SSL stöder tre typer av autentisering:
Om servern är autentiserad måste dess certifieringsmeddelande tillhandahålla rätt certifieringskedja som leder till en acceptabel CA. Enkelt uttryckt måste den autentiserade servern tillhandahålla ett giltigt certifikat till klienten. Varje part ansvarar för att verifiera att den andra partens certifikat ännu inte har löpt ut eller återkallats. Närhelst servern autentiserar är kanalen resistent (säker) mot ett försök att fånga upp data mellan webbservern och webbläsaren, men en helt anonym session är i sig själv sårbar för en sådan attack. Den anonyma servern kan inte autentisera klienten. Huvudsyftet med nyckelutbytesprocessen är att skapa en klienthemlighet (pre_master_secret) som endast är känd för klienten och servern. Hemligheten (pre_master_secret) används för att skapa den delade hemligheten (master_secret). Den delade hemligheten behövs för att skapa ett meddelande för att verifiera certifikatet, krypteringsnycklar, MAC -hemlighet (meddelandeautentiseringskod) och färdigt meddelande. Genom att skicka det färdiga meddelandet anger parterna att de känner till den korrekta hemligheten (pre_master_secret).
En helt anonym session kan upprättas genom att använda RSA- eller Diffie-Hellman-algoritmen för att generera utbytesnycklarna. Vid användning av RSA krypterar klienten hemligheten (pre_master_secret) med den publika nyckeln för den ocertifierade servern. Klienten lär sig den publika nyckeln från nyckelutbytesmeddelandet från servern. Resultatet skickas i ett nyckelutbytesmeddelande från klienten. Eftersom interceptorn inte känner till serverns privata nyckel kommer det att vara omöjligt för den att dekryptera hemligheten (pre_master_secret). När du använder Diffie-Hellman-algoritmen finns serverns publika parametrar i ett nyckelutbytesmeddelande från servern och skickas till klienten i ett nyckelutbytesmeddelande. En interceptor som inte känner till de privata värdena kommer inte att kunna hitta hemligheten (pre_master_secret).
I det här fallet kan nyckelutbyte och serverautentisering kombineras. Den publika nyckeln kan också finnas i serverns certifikat, eller så kan en temporär RSA -nyckel användas , som skickas i nyckelutbytesmeddelandet från servern. När en tillfällig RSA-nyckel används, signeras utbytesmeddelandena av serverns RSA- eller DSS-certifikat (???). Signaturen innehåller det aktuella värdet för meddelandet Client_Hello.random, så gamla signaturer och gamla temporära nycklar kan inte upprepas. Servern kan bara använda den tillfälliga RSA-nyckeln en gång för att skapa en session. Efter att ha verifierat serverns certifikat, krypterar klienten hemligheten (pre_master_secret) med hjälp av serverns publika nyckel. Efter framgångsrik avkodning av hemligheten (pre_master_secret) genereras ett "färdigt" meddelande, vilket visar för servern att den känner till den privata nyckel som motsvarar serverns certifikat.
När RSA används för nyckelutbyte, används klientcertifikatverifieringsmeddelandet för att autentisera klienten. Klienten signerar värdet som beräknats från master_secret och alla föregående handskakningsprotokollmeddelanden. Dessa handskakningsmeddelanden innehåller ett servercertifikat som matchar serverns signatur med ett Server_Hello.random-meddelande som matchar signaturen för det aktuella handskakningsmeddelandet (???).
I det här fallet kan servern också stödja en parameterspecifik Diffie-Hellman-algoritm, eller kan använda nyckelutbytesmeddelanden från servern för att skicka en uppsättning temporära parametrar signerade med DSS- eller RSA-certifikat. Tillfälliga parametrar hashas med ett hello.random-meddelande före signering för att förhindra att en angripare upprepar gamla parametrar. I båda fallen kan klienten kontrollera certifikatet eller signaturen för att säkerställa att parametrarna tillhör servern.
Om klienten har ett certifikat som innehåller parametrarna för Diffie-Hellman- algoritmen innehåller certifikatet även den information som krävs för att slutföra nyckelutbytet. I det här fallet måste klienten och servern generera samma Diffie-Hellman-resultat (pre_master_secret) varje gång de upprättar en anslutning. För att förhindra att hemligheten (pre_master_secret) lagras i datorns minne längre än nödvändigt, bör hemligheten konverteras till den delade hemligheten (master_secret) så snabbt som möjligt. Klientinställningarna måste vara kompatibla med de som stöds av servern för att nyckelutbytet ska fungera.
Record Layer-protokollet är ett lagerprotokoll. På varje nivå innehåller meddelanden fält för längd, beskrivning och validering. Skrivprotokollet tar emot meddelanden som ska överföras, fragmenterar data till hanterbara block, komprimerar data intelligent med hjälp av en MAC (meddelandeautentiseringskod), krypterar och överför resultatet. Den dekrypterar mottagna data, kontrollerar, packar upp, samlar in och levererar till högre nivåer av klienten.
Det finns fyra inspelningsprotokoll:
Om en SSL-implementering tar emot en posttyp som den inte känner till, ignoreras den posten helt enkelt. Alla protokoll som skapas för att användas tillsammans med SSL måste vara väl genomtänkta eftersom det kommer att behöva hantera attacker på det. Observera att på grund av postens typ och längd är protokollet inte skyddat av kryptering. Försiktighet bör iakttas för att minimera trafiken.
En SSL-klient och server kommer överens om att upprätta en anslutning med hjälp av en handskakningsprocedur. Under handskakningen kommer klienten och servern överens om olika parametrar som ska användas för att säkra anslutningen:
Detta avslutar handskakningen och startar en säker anslutning, som krypteras och dekrypteras med nyckeldata. Om något av ovanstående misslyckas, har SSL-handskakningen misslyckats och anslutningen skapas inte.
Det finns ett protokoll för ändring av krypteringsparameter för att signalera övergången till krypteringsläge. Protokollet innehåller ett enda meddelande som är krypterat och komprimerat på den för närvarande etablerade anslutningen. Meddelandet består av endast en bit med värdet 1.
struct { enum { change_cipher_spec ( 1 ), ( 255 ) } typ ; } ChangeCipherSpec ;Ett chifferändringsmeddelande skickas av klienten och servern för att meddela den mottagande parten att efterföljande skrivningar kommer att skyddas enligt den nyligen förhandlade CipherSpec och nycklar. Acceptans av detta meddelande får mottagaren att instruera skrivskiktet att omedelbart kopiera det väntande lästillståndet till det aktuella lästillståndet. Omedelbart efter att ha skickat detta meddelande måste avsändaren instruera skrivlagret att ändra återskrivningsläget till det aktuella skrivläget. Chifferändringsmeddelandet skickas under handskakningen, efter att säkerhetsparametrarna har överförts, men innan det "färdiga" meddelandet skickas.
En av de typer av validering som stöds i skriv-SSL-protokollet är larmprotokollet. Larmmeddelandet förmedlar de svårigheter som uppstått i meddelandet och en beskrivning av larmet. Ett larmmeddelande om kritisk nivå avslutar anslutningen omedelbart. I det här fallet kan andra anslutningar som motsvarar sessionen fortsätta, men sessionsidentifieraren måste ogiltigförklaras. Liksom andra meddelanden krypteras och komprimeras larmmeddelandet så snart det aktuella anslutningstillståndet indikeras.
Dataapplikationsmeddelandet fungerar på rekordnivå. Den är fragmenterad, komprimerad och krypterad baserat på anslutningens aktuella tillstånd. Meddelanden anses vara transparenta för postlagret.
Det finns ett antal attacker som kan göras mot SSL-protokollet. SSL är dock resistent mot dessa attacker, förutsatt att användaren endast använder betrodda servrar för att bearbeta information. SSL 2.0 är sårbart i vissa situationer [23] :
SSL 2.0 är inaktiverat som standard i webbläsare som börjar med Internet Explorer 7 [24] , Mozilla Firefox 2 [25] , Opera 9.5 [26] och Safari .
Den 14 oktober 2014 identifierades en sårbarhet CVE-2014-3566, kallad POODLE (Padding Oracle On Downgraded Legacy Encryption). Denna sårbarhet tillåter en angripare att utföra en Man-in-the-Middle- attack på en anslutning krypterad med SSL 3.0. POODLE-sårbarheten är en sårbarhet i protokollet och inte i någon av dess implementeringar, så alla anslutningar krypterade med SSL v3 påverkas av den.
Det finns andra svagheter i SSL 3.0. Till exempel beror hälften av huvudnyckeln som ställs in helt på MD5-hashfunktionen, som inte är kollisionsbeständig och därför inte anses säker [27] .
Denna typ av attack utförs när angriparen har en uppfattning om vilken typ av meddelanden som skickas.
En kryptoanalytiker kan bilda en databas där nycklarna är krypterade klartextsträngar. Baserat på den skapade databasen kan du bestämma sessionsnyckeln som motsvarar ett specifikt datablock.
I allmänhet är sådana attacker möjliga för SSL. Men SSL försöker motverka dessa attacker genom att använda stora sessionsnycklar - klienten genererar en nyckel som är längre än tillåtet av exportrestriktioner, varav en del skickas till servern i klartext, och resten kombineras med den hemliga delen för att få en tillräckligt lång nyckel (till exempel 128 bitar, som krävs av RC4). Sättet att blockera klartextattacker är att göra mängden text som krävs oacceptabelt stor. Varje bit som läggs till längden på sessionsnyckeln fördubblar storleken på ordboken. Att använda en sessionsnyckel på 128 bitar gör storleken på ordboken långt bortom moderna tekniska möjligheter (lösningen skulle kräva ett antal atomer som inte finns i hela universum). Ett annat sätt som SSL kan motverka denna attack är genom att använda maximala möjliga nyckellängder (i icke-export-fallet). Konsekvensen av detta är att den enklaste och billigaste attackmetoden är en frontal attack av nyckeln, men för en 128-bitars nyckel kan kostnaden för att avslöja den anses vara oändlig.
Reflection AttackAngriparen registrerar kommunikationssessionen mellan servern och klienten. Senare försöker den upprätta en anslutning till servern genom att spela upp klientens inspelade meddelanden. Men SSL stöter bort denna attack med en speciell unik anslutningsidentifierare (IC). Naturligtvis, teoretiskt sett, kan en tredje part inte förutsäga IS eftersom det är baserat på en uppsättning slumpmässiga händelser. En angripare med stora resurser kan dock logga ett stort antal sessioner och försöka plocka upp den "rätta" sessionen baserat på det meddelande som servern skickade i Server_Hello- meddelandet . Men SSL -nonces är minst 128 bitar långa, vilket innebär att en angripare måste skriva 264 nonces för att få 50 % chans att gissa. Men 2 64 är ett tillräckligt stort antal för att göra dessa attacker meningslösa.
HandskakningsprotokollattackEn angripare kan försöka påverka handskakningsutbytet så att parterna väljer olika krypteringsalgoritmer, och inte de de brukar välja. Eftersom många implementeringar stöder exporterad kryptering, och vissa till och med stöder 0-kryptering eller MAC, är dessa attacker av stort intresse.
För en sådan attack måste en angripare snabbt förfalska ett eller flera handskakningsmeddelanden. Om detta händer kommer klienten och servern att beräkna olika hashvärden för handskakningsmeddelandet. Som ett resultat kommer parterna inte att acceptera " färdiga " meddelanden från varandra . Utan att känna till hemligheten kommer angriparen inte att kunna fixa det färdiga meddelandet , så attacken kan upptäckas.
Hacka SSL-anslutningar inuti datacentretDen mest ökända incidenten med masshackning av information skyddad av SSL-protokoll utfördes av FBI-agenter som använde Carnivore och NarusInsight- system , vilket ledde till en stämningsansökan på uppdrag av människorättsorganisationen Electronic Frontier Foundation mot AT&T, som installerade dessa komplex för att knäcka kryptografiskt skyddad information.
Trots det stora offentliga protesterna i USA av detta fall och utredningen på nivån av representanthusets konstitutionella kommitté, förekom ingen teknisk hackning av SSL-protokollet av FBI- agenter . Carnivore och NarusInsight installerades i själva datacentret , där det fanns servrar som utförde SSL-anslutningar med fjärrklienter. NarusInsight återställde helt krypterad information genom att inte lyssna på en SSL-anslutning, utan på intern trafik mellan applikationsservrar inom själva datacentret, efter att data som tagits emot via SSL dekrypterades av servern själv, som tog emot den från externa användare.
Denna incident visade dock att SSL inte kan vara ett tillförlitligt medel för kryptografiskt skydd av serverdata på Internet, eftersom specialtjänster kan installera lyssningssystem som NarusInsight eller SORM-2 [28] i datacentret. Alla typer av kryptografi, som innebär att nycklarna till chiffrerna finns på mottagarservern i datacentret, hackas automatiskt av underrättelsetjänstens sniffers genom att injicera dem i mottagaren själv. Vidare är uppgifterna helt rekonstruerade enligt de förfaranden som för närvarande är reglerade och lagstiftningsakter, såsom " Patriot Act ". Dessutom förbjuder dessa lagstiftningsakter, upp till åtal av datacenterägare, borttagning av underrättelsetjänstsniffare från den interna delen av mottagarservrarna. Med dessa system på plats kan SSL endast säkra en anslutning mellan två användare på Internet, inte en SSL-anslutning till en extern webbplats.
BEAST attackDen 23 september 2011 demonstrerade de thailändska forskarna Duong och Giuliano Rizzo, med hjälp av en Java-applet, ett "proof of concept" som heter Beast ("Browser Exploit Against SSL/TLS") som indikerar en sårbarhet i TLS 1.0 [29] [30] . Tidigare var denna sårbarhet, som ursprungligen upptäcktes av Phillip Rogaway [31] 2002, praktiskt taget omöjlig för någon att demonstrera. TLS 1.1-sårbarheten rapporterades 2006.
Attacken bygger på flera antaganden, men som det visade sig är det fullt möjligt att genomföra dem. Först måste kryptoanalytikern kunna fånga upp trafiken som överförs av webbläsaren . För det andra är det nödvändigt att på något sätt tvinga användaren att överföra data över samma säkra kommunikationskanal . Låt en säker anslutning upprättas mellan Bob ( B ) och Alice ( A ) datorer. Låt oss anta att det i-te blocket i meddelandet som kom till oss innehåller hemlig information (till exempel ett lösenord).
Ci = E ( Nyckel , Mi xor C i -1 ), där Ci är det krypterade blocket, Mi är den hemliga texten
Låt oss anta att lösenordet A är P . Vi kan kontrollera om vårt antagande är korrekt:
Så vi kunde fånga upp initieringsvektorn, som används för att kryptera det första blocket i nästa meddelande, men detta är också det sista blocket i det föregående meddelandet (i krypterad form) - IV . Vi fångade också C i-1 . Med hjälp av denna data bildar vi ett meddelande så att det första blocket blir lika med följande:
M 1 = C i-1 x eller IV x eller P
Om kryptoanalytikern kan överföra meddelandet över samma säkra kanal, kommer det första blocket i det nya meddelandet att se ut så här:
C 1 = E ( Key , M 1 xor IV ) = E ( Key , ( C i-1 xor IV xor P ) xor P ) xor IV ) = E ( Key , ( C i-1 xor P )) = C i
Det visar sig att om P = M , så kommer det första krypterade blocket i det nya meddelandet Ci att vara lika med det tidigare avlyssnade Ci .
I praktiken uppstår ett problem: block M är 16 byte långt, även om vi känner till alla utom två byte behöver vi 2 15 försök för att gissa resten. Tänk om vi inte vet någonting?
Därav slutsatsen att denna praxis kan fungera om kryptoanalytikern har ett begränsat antal antaganden om värdet av M , eller snarare det mesta av innehållet i detta block. Nästa antagande är att kryptoanalytikern kan kontrollera platsen för data i blocket, till exempel att veta att lösenordet är n tecken långt. Genom att veta detta ordnar kryptoanalytikern lösenordet på ett sådant sätt att endast 1 tecken kommer in i det första blocket, och det återstående (n-1) i nästa - det vill säga de första 15 byten innehåller känd data. Och för att gissa 1 karaktär behöver en angripare i värsta fall 256 försök.
Sårbarheten var känd mycket tidigare, men utvecklarna av verktyget är de första som lyckades implementera alla villkor för denna attack. Nämligen:
Här är en lista över olika tekniker och webbläsarplugin som kan utföra agentinjektion i offrets webbläsare: Javascript XMLHttpRequest API, HTML5 WebSocket API, Flash URLRequest API, Java Applet URLConnection API och Silverlight WebClient API.
RC4 attack2013 hölls en konferens i Singapore där professor Dan Bernstein presenterade en ny teknik för att knäcka SSL/TLS-protokoll med hjälp av RC4-chifferet, vilket föreslogs 2011 som ett försvar mot BEAST. En sårbarhet som hittades i RC4 är relaterad till bristen på slumpmässighet i bitströmmen som förvrängde meddelandet. Efter att ha kört igenom samma meddelande många gånger, avslöjades ett tillräckligt antal upprepade mönster för att återställa den ursprungliga texten. För en attack måste en enorm mängd data köras genom chifferet. I den presenterade implementeringen tog hackningen upp till 32 timmar, men möjligheten att optimera processen var inte utesluten. Men denna attack är svår att genomföra i praktiken. Skaparna hävdar att 256 chiffertexter behövs för att återställa 80 byte av 256 .
Avslöjande chifferSom du vet beror SSL på olika kryptografiska parametrar. RSA offentlig nyckelkryptering krävs för nyckelöverföring och server-/klientautentisering. Däremot används olika kryptografiska algoritmer som ett chiffer. Således, om en framgångsrik attack på dessa algoritmer utförs, kan SSL inte längre anses vara säker. En attack på vissa kommunikationssessioner görs genom att spela in sessionen och sedan, med tiden, väljs sessionsnyckeln eller RSA-nyckeln.
Man-i-mitten-attackÄven känd som MitM (Man-in-the-Middle) attack. Det involverar deltagande av tre parter: servern, klienten och angriparen däremellan. I den här situationen kan en angripare fånga upp alla meddelanden som följer i båda riktningarna och ersätta dem. Angriparen verkar vara servern till klienten och klienten till servern. I fallet med Diffie-Hellman-nyckelutbyte är denna attack effektiv, eftersom integriteten hos den mottagna informationen och dess källa inte kan verifieras. En sådan attack är dock inte möjlig med SSL-protokollet [32] eftersom certifikat som autentiserats av en certifikatutfärdare [33] används för att autentisera källan (vanligtvis servern) .
Attacken kommer att lyckas om:
Denna typ av attack kan hittas i stora organisationer som använder Microsoft Forefront TMG- brandväggen eller Blue Coat Proxy SG proxyserver . I det här fallet befinner sig "inkräktaren" i utkanten av organisationens nätverk och ersätter det ursprungliga certifikatet med sitt eget. Denna attack blir möjlig på grund av möjligheten att ange själva proxyservern som en betrodd certifieringsmyndighet (antingen som en rot eller som ett underordnat företagsrot). Vanligtvis är en sådan implementeringsprocedur transparent för användaren på grund av företagets användares arbete i Active Directory-miljön. Detta verktyg kan användas både för att kontrollera den överförda informationen och för att stjäla personlig data som överförs med hjälp av en säker HTTPS-anslutning.
Den mest kontroversiella frågan är användarens medvetenhet om möjligheten till dataavlyssning, eftersom i fallet med en rotcertifikatsubstitution kommer inga säkerhetsmeddelanden att visas och användaren förväntar sig att de överförda data är konfidentiella.
Dessutom, när du använder Forefront TMG som en SSL-proxy, finns det möjlighet till en andra MitM-attack på internetsidan, eftersom det ursprungliga certifikatet inte kommer att överföras till användaren, och Forefront TMG kan konfigureras för att acceptera och sedan ersätta sig själv. -signerade eller återkallade certifikat. För att skydda mot en sådan attack är det nödvändigt att helt förbjuda att arbeta med webbservrar vars certifikat innehåller några fel, vilket säkerligen kommer att leda till oförmågan att arbeta med HTTPS-protokollet med många webbplatser.
Blue Coat Proxy SG är skyddad från den andra MitM-attacken: systemet låter dig konfigurera policyn så att i fallet med ett opålitligt webbservercertifikat utfärdar systemet också ett certifikat som inte är signerat av en betrodd kedja utan av ett tillfälligt jag -signerade en.
THC-SSL-DOSDen 24 oktober 2011 släppte The Hacker's Choice (THC) verktyget THC-SSL-DOS, som kan användas för att utföra DoS-attacker på SSL-servrar. Det här verktyget utnyttjar en sårbarhet i SSL-omförhandlingsfunktionen, som ursprungligen utformades för att göra SSL säkrare. Revalidering tillåter servern att skapa en ny privat nyckel över en befintlig SSL-anslutning. Den här funktionen är aktiverad som standard på de flesta servrar. Att upprätta en säker anslutning, samt att utföra SSL-revalidering, kräver flera gånger mer resurser på serversidan än på klientsidan, det vill säga om klienten skickar många SSL-revalideringsförfrågningar, dränerar detta serverns systemresurser.
Enligt en THC-deltagare kräver en framgångsrik attack en bärbar dator med verktyget installerat och internetåtkomst. Programmet publicerades i allmänhetens egendom, eftersom dess motsvarighet dök upp på nätverket för några månader sedan. Dessutom, enligt utvecklarna, kan en attack utföras även om servern inte stöder förlängningsfunktionen, även om detta kommer att kräva att attackmetoden ändras. I det här fallet etableras många TCP-anslutningar för den nya SSL-handskakningen, men fler bots behövs för en effektiv attack.
Som ett försvar rekommenderar vissa mjukvaruutvecklare att ställa in specifika regler för att avsluta en anslutning med en klient som utför en förlängningsoperation mer än ett visst antal gånger per sekund.
2009, vid en Black Hat-konferens i Washington DC, demonstrerade Moxie Marlinspike, en oberoende hackare, ett nytt verktyg , SSLstrip, som kan extrahera viktig information genom att lura användare att tro att de är på en säker sida när de inte är det. Detta kan uppnås genom att konvertera normalt SSL-säkrade sidor till sina osäkra motsvarigheter, vilket lurar både servern och klienten. Verktyget fungerar eftersom många webbplatser som använder SSL-skydd har en osäker hemsida. De krypterar endast de avsnitt där viktig information överförs. Och när användaren klickar på auktoriseringssidan, ersätter verktyget webbplatsens svar genom att ändra https till http. SSLstrip använder följande tekniker: för det första distribueras en proxyserver på det lokala nätverket som har ett giltigt certifikat - härifrån fortsätter användaren att se https i adressfältet, för det andra används en teknik för att skapa långa webbadresser som innehåller falska '/ ' i adressfältet - detta är nödvändigt för att undvika teckenkonvertering av webbläsare. För att bevisa att systemet fungerade körde Moxxi SSLstrip på en server som betjänade Tor-nätverket och på 24 timmar fiskade han upp 254 lösenord från användare av Yahoo , Gmail , Ticketmaster, PayPal och LinkedIn .
I SSL-protokollet är felhanteringen väldigt enkel. När ett fel upptäcks skickar den som upptäckte det ett meddelande om det till sin partner. Allvarliga fel kräver att servern och klienten stänger anslutningen [35] . SSL-protokollet definierar följande fel:
| Grundläggande TCP / IP-protokoll efter lager av OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliserad | |
| nätverk | |
| Transport | |
| session | |
| Representation | |
| Applicerad | |
| Annat ansökt | |
| Lista över TCP- och UDP-portar | |
| Internetsäkerhetsmekanismer _ | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Kryptering och trafikfiltrering _ |
| ||||||||||||||
| Autentisering | |||||||||||||||
| Datorskydd |
| ||||||||||||||
| IP-telefonisäkerhet |
| ||||||||||||||
| Anonymisering av trafiken | |||||||||||||||
| Trådlös säkerhet | |||||||||||||||