SSL ( Eng. Secure Sockets Layer - niveauet af sikre sockets ) er en kryptografisk protokol , der indebærer en mere sikker forbindelse. Den bruger asymmetrisk kryptografi til at autentificere udvekslingsnøgler, symmetrisk kryptering for at bevare fortroligheden, meddelelsesgodkendelseskoder for meddelelsesintegritet. Protokollen blev meget brugt til instant messaging og voice over IP ( Voice over IP - VoIP ) i applikationer som e- mail , internetfax osv. I 2014 rapporterede den amerikanske regering om en sårbarhed i den nuværende version af protokollen [1] . SSL bør udfases til fordel for TLS (se CVE-2014-3566).
SSL blev oprindeligt udviklet af Netscape Communications for at tilføje HTTPS-protokollen til deres Netscape Navigator -webbrowser . Efterfølgende blev RFC-standarden udviklet og vedtaget på basis af SSL 3.0-protokollen, som fik navnet TLS .
SSL-protokollen giver sikker kommunikation gennem følgende to elementer:
SSL bruger asymmetrisk kryptografi til at autentificere udvekslingsnøgler, en symmetrisk chiffer til at opretholde fortrolighed og meddelelsesgodkendelseskoder for meddelelsesintegritet.
SSL-protokollen giver en "sikker kanal", der har tre hovedegenskaber:
Fordelen ved SSL er, at den er uafhængig af applikationsprotokollen. Applikationsprotokoller ( HTTP , FTP , TELNET osv.) kan arbejde oven på SSL-protokollen på en fuldstændig gennemsigtig måde, det vil sige, at SSL kan forhandle krypteringsalgoritmen og sessionsnøglen og autentificere serveren, før applikationen modtager eller transmitterer første byte af meddelelsen.
SSL-protokollen blev oprindeligt udviklet af Netscape Communications . Version 1.0 blev aldrig frigivet til offentligheden. Version 2.0 blev udgivet i februar 1995, men indeholdt mange sikkerhedsfejl, der førte til udviklingen af SSL version 3.0 [2] . SSL version 3.0, udgivet i 1996, var grundlaget for skabelsen af TLS 1.0, en Internet Engineering Task Force ( IETF ) protokolstandard, der først blev defineret i RFC 2246 i januar 1999. Visa , Master Card , American Express og mange andre organisationer har licens til at bruge SSL-protokollen til kommercielle formål på internettet. SSL kan således udvides i overensstemmelse med projektet for at understøtte frem- og bagudkompatibilitet og forhandling mellem forbindelser i et peer-to-peer-netværk. Fra marts 2011 må TLS-klienter ifølge RFC 6176 ikke bruge SSL 2.0-protokollen, når de anmoder om en forbindelse til en server, og servere skal afvise sådanne anmodninger.
TLS 1.0 blev først defineret i RFC 2246 i januar 1999 som en opdatering til SSL 3.0. Som angivet i RFC, "er forskellene mellem denne protokol og SSL 3.0 ikke kritiske, men de er væsentlige for forekomsten af inkompatibiliteter mellem TLS 1.0 og SSL 3.0." TLS 1.0 inkluderer midler, hvorved implementering af en TLS til SSL 3.0-forbindelse ville svække sikkerheden.
TLS 1.1 blev introduceret i RFC 4346 i april 2006 [3] . Dette var en opdatering til TLS version 1.0. Væsentlige ændringer i denne version omfatter:
TLS 1.2 blev annonceret i RFC 5246 i august 2008. Den er baseret på den tidligere foreslåede version af TLS 1.1.
TLS 1.3 blev anerkendt som en standard i RFC 8446 i august 2018.
SSL bruger et flerlagsmiljø for at sikre sikkerheden ved udveksling af information. Kommunikationsfortrolighed er til stede på grund af det faktum, at en sikker forbindelse kun er åben for målrettede brugere.
SSL-protokollen sidder mellem to protokoller: den protokol, som klientprogrammet bruger (HTTP, FTP, LDAP, TELNET osv.) og TCP/IP-transportprotokollen. SSL beskytter data ved at fungere som et filter for begge sider og sender dem videre til transportlaget [4] [5] .
Driften af protokollen kan opdeles i to niveauer:
Det første lag består til gengæld af tre underprotokoller:
Forbindelseshåndtryksprotokollen bruges til at forhandle sessionsdata mellem klienten og serveren. Sessionsdata inkluderer:
Forbindelseshåndtryksprotokollen producerer en dataudvekslingskæde, som igen begynder autentificeringen af parterne og aftaler kryptering, hashing og komprimering. Det næste trin er autentificeringen af deltagere, som også udføres af forbindelsesbekræftelsesprotokollen.
Cifferparameterændringsprotokollen bruges til at ændre nøgledataene (nøglemateriale) - information, der bruges til at skabe krypteringsnøgler. Protokollen består kun af én besked, hvor serveren siger, at afsenderen ønsker at ændre nøglesættet.
Advarselsprotokollen indeholder en meddelelse, der viser parterne en ændring i status eller en mulig fejl. Typisk sendes en advarsel, når forbindelsen er lukket og en ugyldig besked modtages, beskeden kan ikke dekrypteres, eller brugeren annullerer handlingen.
SSL-protokollen bruger certifikater til at bekræfte, at en offentlig nøgle tilhører dens rigtige ejer. Måder at få et SSL-certifikat på:
Selvsigneret certifikat - et certifikat oprettet af brugeren selv - i dette tilfælde er udstederen af certifikatet den samme som ejeren af certifikatet. Et "tomt" certifikat er et certifikat, der indeholder fiktiv information, der bruges som en midlertidig til at opsætte SSL og verificere dets funktionalitet i et givet miljø.
Blandt SSL - certifikater er der domænevaliderede certifikater og udvidede valideringscertifikater . Sidstnævnte forbinder et domænenavn med en virkelig person eller enhed.
Der er 4 hovednøglegenereringsalgoritmer: RSA , Fixed Diffie-Hellman, Ephemeral Diffie-Hellman, Anonymous Diffie-Hellman
rsaNår en privat RSA-nøgle er "tabt", får den kryptoanalytiker, der modtager den, mulighed for at dekryptere alle optagede tidligere beskeder og fremtidige beskeder. Implementeringen af nøgleudvekslingen i RSA er envejs: al den nødvendige information til at danne en symmetrisk nøgle, som oprettes under håndtryksfasen, sendes til serveren og krypteres med serverens offentlige nøgle. Afsløring af den private nøgle gør det muligt at finde ud af den symmetriske nøgle til denne session.
Diffie-HellmanDen faste Diffie-Hellman- mekanisme bruger en permanent offentlig nøgle, som er registreret i servercertifikatet. Det betyder også, at klienten ved hver ny forbindelse giver sin del af nøglen. Efter nøgleudvekslingen dannes en ny symmetrisk nøgle til at udveksle information for den aktuelle session. Ved at afsløre serverens private nøgle, kan kryptoanalytikeren dekryptere tidligere optagede beskeder såvel som alle fremtidige beskeder. Dette er muliggjort af selve mekanismen. Da kryptoanalytikeren kender serverens private nøgle, vil han være i stand til at finde ud af den symmetriske nøgle for hver session, og selv det faktum, at nøglegenereringsmekanismen er to-vejs, vil ikke hjælpe.
Den anonyme Diffie-Hellman- mekanisme giver ingen garantier for privatlivets fred, da dataene transmitteres ukrypteret.
Den eneste mulighed, der garanterer sikkerheden for tidligere og fremtidige beskeder, er Ephemeral Diffie-Hellman . Forskellen i forhold til de tidligere omtalte metoder er, at der med hver ny forbindelse genereres en engangsnøgle af serveren og klienten. Således, selvom kryptanalytikeren får den aktuelle private nøgle, vil han kun være i stand til at dekryptere den aktuelle session, men ikke tidligere eller fremtidige sessioner.
Der er to hovedmåder at kryptere data på: symmetrisk kryptering (delt hemmelig nøgle) og asymmetrisk kryptering (offentlig/privat nøglepar).
SSL bruger både asymmetrisk og symmetrisk kryptografi.
Essensen af asymmetrisk kryptering er, at der bruges et par nøgler. En af nøglerne kaldes offentlig (som regel offentliggøres den i selve ejerens certifikat), og den anden nøgle kaldes privat - den holdes hemmelig. Begge nøgler bruges i par: den offentlige nøgle bruges til at kryptere dataene, og den private nøgle bruges til at dekryptere dem. Dette forhold giver dig mulighed for at gøre to vigtige ting.
RSA er en af de mest udbredte asymmetriske krypteringsalgoritmer.
Med symmetrisk kryptering bruges den samme nøgle til både at kryptere og dekryptere data. Hvis parterne ønsker at udveksle krypterede beskeder på en sikker måde, skal begge parter have de samme symmetriske nøgler. Denne type kryptering bruges til store mængder data (fordi symmetrisk kryptering er hurtigere). Almindeligt anvendte algoritmer er DES , 3-DES , RC2 , RC4 og AES .
SSL-protokollen bruger offentlig nøglekryptering til gensidig autentificering af klienten og serveren (ved hjælp af digital signaturteknologi), samt til at generere en sessionsnøgle, som igen bruges af hurtigere symmetriske kryptografialgoritmer til at kryptere en stor mængde data .
Hashværdien er en meddelelsesidentifikator, dens størrelse er mindre end størrelsen af den originale meddelelse. De mest berømte hash-algoritmer er MD5 (Message Digest 5), som producerer en 128-bit hashværdi, SHA-1 (Secure Hash Algorithm), som producerer en 160-bit hashværdi, SHA-2 og SHA-3 . Resultatet af hashing-algoritmen er en værdi, der bruges til at kontrollere integriteten af dataoverførslen.
Protokollen på optagelagsniveau modtager krypterede data fra klientprogrammet og overfører dem til transportlaget. Optagelsesprotokollen tager dataene, opdeler dem i blokke og udfører kryptering (dekryptering) af dataene. Samtidig bruges de oplysninger, der blev aftalt under bekræftelsen af dataene, aktivt.
SSL-protokollen tillader symmetrisk nøglekryptering ved hjælp af enten blokcifre eller stream -kryptering . Blokcifre er almindeligt anvendt i praksis. Funktionsprincippet for en blokchiffer er at kortlægge en blok af klartekst til den samme blok af chiffertekst. Denne chiffer kan repræsenteres som en tabel indeholdende 2.128 linjer, hver linje indeholder en almindelig tekstblok M og dens tilsvarende chiffertekstblok C. En lignende tabel findes for hver nøgle.
Kryptering kan repræsenteres som en funktion
C = E ( Nøgle , M ), hvor M er de originale data, Nøgle er krypteringsnøglen, C er de krypterede data.
Som regel er blokke små (normalt 16 bytes), så spørgsmålet opstår: hvordan krypterer man en lang besked?
Den første tilstand for sådan kryptering kaldes ECB (Electronic Codebook) eller simpel erstatningstilstand. Dens essens er, at vi opdeler den originale besked i blokke (for de samme 16 bytes) og krypterer hver blok separat. Denne tilstand bruges dog sjældent på grund af problemet med at bevare de statistiske træk ved kildeteksten: 2 identiske blokke med almindelig tekst efter kryptering vil blive til to identiske blokke med chiffertekst.
For at løse dette problem blev en anden tilstand udviklet - CBC (Cipher-block chaining). I dette tilfælde XOR-behandles hver ny chiffertekstblok med det tidligere krypteringsresultat. Den første blok XOR-behandles med en eller anden initialiseringsvektor (initialiseringsvektor, IV). Al ovenstående teori er dog udviklet til ét stort objekt, mens SSL, som er en kryptografisk protokol, skal kryptere en række pakker. I en sådan situation er der to måder at anvende CBC på:
Ved design af applikationer implementeres SSL "under" enhver anden applikationslagsprotokol, såsom HTTP , FTP , SMTP , NNTP og XMPP , hvilket giver "gennemsigtighed" til dens brug. Historisk set er SSL primært blevet brugt med pålidelige transportprotokoller såsom Transmission Control Protocol (TCP). Det er dog også blevet implementeret med datagramtransportprotokoller såsom User Datagram Protocol (UDP) og Datagram Control Protocol (DCCP), hvis anvendelse er blevet standardiseret, hvilket giver anledning til begrebet Datagram Transport Layer Security (DTLS).
Den hyppige brug af SSL-protokollen har ført til dannelsen af HTTPS -protokollen (Hypertext Transfer Protocol Secure), som understøtter kryptering. Data, der transmitteres over HTTPS -protokollen , "pakkes" ind i den kryptografiske SSL- eller TLS -protokol , og sikrer derved beskyttelsen af disse data. Denne beskyttelsesmetode er meget brugt i webverdenen til applikationer, hvor forbindelsessikkerhed er vigtig, såsom betalingssystemer. I modsætning til HTTP er HTTPS som standard TCP -port 443.
Webstedssupport til protokollen [6]| Protokol version | Sikkerhed | Hjemmeside support |
|---|---|---|
| SSL 2.0 | Ikke | 4,9 % |
| SSL 3.0 | Ikke | 16,6 % |
| TLS 1.0 | Måske | 94,7 % |
| TLS 1.1 | Ja | 82,6 % |
| TLS 1.2 | 85,5 % |
Fra begyndelsen af 2017 er alle større webbrowsere, der understøtter SSL/TLS:
Browsere, der understøtter SSL/TLS| Browser | Platforme | 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 | Ikke | Ikke | Ikke |
| Chrome 29-53 | Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8,10) | Ja [7] | Ja [7] | Ja [8] | Ikke |
| 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] | Ikke |
| Firefox 27-53 | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Ja | Ja | Ja | Ikke |
| Firefox 54+ | Linux, Mac OS X, Windows (XP, Vista, 7, 8) | Ja | Ja | Ja | Ja |
| IE6 | Windows (XP) | Ja | Ikke | Ikke | Ikke |
| IE 7 - 8 | Windows (XP, Vista) | Ja | Ikke | Ikke | Ikke |
| IE 8 - 9 | Windows 7 | Ja | Ja | Ja | Ikke |
| IE9 | Windows Vista | Ja | Ikke | Ikke | Ikke |
| IE 10+ | Windows (7, 8) | Ja | Ja | Ja | Ikke |
| Kant 12-15 | Windows 10 | Ja | Ja | Ja | Ikke |
| Opera 5-7 | Linux, Mac OS X, Windows | Ja [12] | Ikke | Ikke | Ikke |
| Opera 8-9 | Linux, Mac OS X, Windows | Ja | Ja [13] | Ikke | Ikke |
| Opera 10+ | Linux, Mac OS X, Windows | Ja | Ja | Ja | Ikke |
| Opera 44+ | Linux, Mac OS X, Windows | Ja | Ja | Ja | Ja |
| Safari 4 | Mac OS X, Windows (XP, Vista, 7), iOS 4.0 | Ja | Ikke | Ikke | Ikke |
| Safari 5 | Mac OS X, Windows (XP, Vista, 7) | Ja | Ikke | Ikke | Ikke |
| Safari 7-10 | iOS 5.0- | Ja | Ja | Ja | Ikke |
Specifikationer:
Oprindeligt blev SSL-baserede virtuelle private netværk ( VPN ) udviklet som en komplementær og alternativ fjernadgangsteknologi baseret på IPsec VPN. Faktorer som tilstrækkelig pålidelighed og lave omkostninger gjorde imidlertid denne teknologi attraktiv for VPN-organisationer. SSL er også meget brugt i e-mail.
Den mest almindelige implementering af SSL er open source kryptografiske pakke OpenSSL , baseret på SSLeay skrevet af Eric Young. Den seneste version af OpenSSL understøtter SSLv3. Pakken er designet til at oprette og administrere forskellige slags certifikater . Det inkluderer også et bibliotek til SSL-understøttelse af forskellige programmer. Biblioteket bruges for eksempel af SSL-modulet i den fælles Apache HTTP -server .
Alle data i SSL sendes i form af records (records) - objekter, der består af en header og en vis mængde data. Hver posthoved indeholder 2 eller 3 bytes længdekode. Hvis den mest signifikante bit i den første byte af postlængdekoden er 1, så har posten ingen udfyldning, og den samlede headerlængde er 2 bytes, ellers indeholder posten en udfyldning, og den samlede headerlængde er 3 bytes. I tilfælde af en lang (3 bytes) header har den næstmest signifikante bit af den første byte en særlig betydning. Hvis den er lig med 0 - posten er informativ, hvis den er lig med 1 - er posten en sikkerhedsudslip. Postlængdekoden inkluderer ikke antallet af header-bytes. For en 2-byte header beregnes dens længde som følger:
RECORD-LENGTH = ((byte[0] & 0x7F) << 8) | byte[1];
Her er byte[0] den første modtagne byte, og byte[1] er den anden modtagne byte.
For en 3-byte header beregnes postlængden som følger:
RECORD-LENGTH = ((byte[0] & 0x3F) <<8) | byte[1];
IS-ESCAPE = (byte[0] & 0x40) !=0;
PADDING = byte[2];
PADDING - værdien angiver antallet af bytes tilføjet af afsenderen til den originale post. Udfyldningsdataene bruges til at gøre postlængden til et multiplum af chifferblokstørrelsen. Afsenderen tilføjer PADDING efter de givne data og krypterer derefter det hele, da længden af dette array er et multiplum af blokstørrelsen af den chiffer, der bruges. Da mængden af transmitterede data er kendt, kan meddelelseshovedet dannes under hensyntagen til mængden af PADDING . Modtageren af beskeden dekrypterer hele datafeltet og får den originale information, og beregner derefter den sande værdi af RECORD-LENGTH , mens PADDING fjernes fra "data"-feltet.
SSL-registreringsdatadelen består af 3 komponenter:
MAC-DATA - meddelelsesgodkendelseskode
MAC-SIZE - funktion af den algoritme, der bruges til at beregne hash-summen
ACTUAL-DATA - faktisk transmitterede data eller meddelelsesdatafelt
PADDING-DATA - PADDING data (med blokkryptering)
MAC-DATA = HASH [ SECRET , ACTUAL-DATA , PADDING-DATA , SEQUENCE-NUMBER ]
Her sendes SECRET først til hash-funktionen efterfulgt af ACTUAL-DATA og PADDING-DATA , efterfulgt af SEQUENCE-NUMBER , et sekvensnummer.
Værdien af SECRET afhænger af, hvem der sender beskeden. Hvis klienten gør det, så er SECRET lig med CLIENT-WRITE-KEY . Hvis klienten modtager beskeden, er SECRET lig med CLIENT-READ-KEY .
Sekvensnummeret er en 32-bit kode, der sendes til hash-funktionen som 4 bytes ved hjælp af netværksrækkefølgen fra høj til lav. Sekvensnummeret er tælleren for serveren eller klienten. For hver transmissionsretning bruges et par tællere - for afsender og for modtager; hver gang en besked sendes, stiger tælleren med 1.
Modtageren af beskeden bruger den forventede sekvensnummerværdi til at sende MAC'en (hash-typen bestemmes af CIPHER-CHOICE parameteren ). Den beregnede MAC-DATA- værdi skal svare til den transmitterede værdi. Hvis sammenligningen mislykkes, betragtes meddelelsen som korrupt, hvilket resulterer i en fejl, der får forbindelsen til at blive lukket.
Den sidste matchningskontrol udføres, når der anvendes en blokcifre. Mængden af data i meddelelsen ( RECORD-LENGTH ) skal være et multiplum af chifferblokstørrelsen. Hvis denne betingelse ikke er opfyldt, anses meddelelsen for at være beskadiget, hvilket resulterer i en afbrydelse af forbindelsen.
For en 2-byte header er den maksimale meddelelseslængde 32767 bytes, for en 3-byte header er den 16383 bytes. SSL-samtaleprotokolmeddelelser skal svare til enkelte SSL-protokolposter, og applikationsprotokolmeddelelser kan optage flere SSL-poster.
SSL-samtaleprotokollen indeholder 2 hovedfaser.
Fase 1Den første fase bruges til at etablere en fortrolig kommunikationskanal.
Denne fase initialiserer forbindelsen, når begge peers udveksler "hej" beskeder. Klienten sender en KLIENT-HEJ- meddelelse . Serveren modtager denne besked, behandler den og sender en SERVER-HEJ- meddelelse tilbage .
På dette tidspunkt har både serveren og klienten nok information til at vide, om en ny hovednøgle er nødvendig. Hvis nøglen ikke er nødvendig, går serveren og klienten til fase 2.
Når en ny hovednøgle skal oprettes , indeholder serverens SERVER-HEJ- meddelelse allerede nok data til, at klienten kan generere en hovednøgle . Disse data inkluderer serverens signerede certifikat, en liste over basiscifre og et forbindelses-id (et tilfældigt tal genereret af serveren, som bruges under hele sessionen). Når klienten har genereret en hovednøgle , sender den serveren en CLIENT-MASTER-KEY- meddelelse eller en fejlmeddelelse, når klienten og serveren ikke kan blive enige om en basischiffer.
Efter at have bestemt hovednøglen sender serveren en SERVERVERIFY- meddelelse til klienten , som godkender serveren.
Fase 2 kaldes autentificeringsfasen. Da serveren allerede er autentificeret i første fase, bliver klienten godkendt i anden fase. Serveren sender en anmodning til klienten, og hvis klienten har de nødvendige oplysninger, sender den et positivt svar, hvis ikke, en fejlmeddelelse. Når en peer har godkendt en anden peer, sender den en færdig besked . I tilfælde af en klient indeholder CLIENT-FINISHED-meddelelsen en krypteret form af CONNECTION-ID'et , som serveren skal verificere. Hvis verifikationen mislykkedes, sender serveren en FEJL -meddelelse .
Når en af peers har sendt en færdig besked , skal den acceptere beskeder, indtil den modtager en færdig besked fra den anden peer, og først når både peers har sendt og modtaget færdige beskeder , afsluttes SSL-samtaleprotokollen. Fra dette øjeblik begynder applikationsprotokollen at fungere.
Nedenfor er flere muligheder for at udveksle beskeder inden for SSL-samtaleprotokollen. Klienten er C , serveren er S. "{smth}key" betyder, at "smth" er krypteret med en nøgle.
I mangel af et sessions-id| klient-hej | C®S: | udfordring, cipher_specs |
| server-hej | S ® C: | forbindelses-id, server_certifikat, chifferspecifikationer |
| klient-hovednøgle | C®S: | {master_key}server_offentlig_nøgle |
| klient-finish | C®S: | {connection-id}client_write_key |
| server-bekræft | S ® C: | {challenge}server_skrivenøgle |
| server-finish | S ® C: | {new_session_id}server_skrivenøgle |
| klient-hej | C®S: | challenge, session_id, cipher_specs |
| server-hej | S ® C: | forbindelses-id, session_id_hit |
| klient-finish | C®S: | {connection-id}client_write_key |
| server-bekræft | S ® C: | {challenge}server_skrivenøgle |
| server-finish | S ® C: | {session_id}server_write_key |
| klient-hej | C®S: | challenge, session_id, cipher_specs |
| server-hej | S ® C: | forbindelses-id, session_id_hit |
| klient-finish | C®S: | {connection-id}client_write_key |
| server-bekræft | S ® C: | {challenge}server_skrivenøgle |
| Anmod om certifikat | S ® C: | {auth_type ,challenge'}server_write_key |
| klient-certifikat | C®S: | {cert_type,client_cert,response_data}client_write_key |
| server-finish | S ® C: | {new_session_id}server_skrivenøgle |
SSL understøtter 3 typer godkendelse:
Hvis serveren er autentificeret, skal dens certificeringsmeddelelse give den korrekte certificeringskæde, der fører til en acceptabel CA. Kort sagt skal den autentificerede server levere et gyldigt certifikat til klienten. Hver part er ansvarlig for at verificere, at den anden parts certifikat endnu ikke er udløbet eller tilbagekaldt. Når serveren autentificerer, er kanalen modstandsdygtig (sikker) over for et forsøg på at opsnappe data mellem webserveren og browseren, men en fuldstændig anonym session er i sagens natur sårbar over for et sådant angreb. Den anonyme server kan ikke godkende klienten. Hovedformålet med nøgleudvekslingsprocessen er at skabe en klienthemmelighed (pre_master_secret), som kun er kendt af klienten og serveren. Hemmeligheden (pre_master_secret) bruges til at skabe den delte hemmelighed (master_secret). Den delte hemmelighed er nødvendig for at oprette en meddelelse for at bekræfte certifikatet, krypteringsnøgler, MAC -hemmeligheden (meddelelsesgodkendelseskode) og den færdige meddelelse. Ved at sende den færdige besked angiver parterne, at de kender den rigtige hemmelighed (pre_master_secret).
En fuldstændig anonym session kan etableres ved at bruge RSA- eller Diffie-Hellman-algoritmen til at generere udvekslingsnøglerne. I tilfælde af brug af RSA , krypterer klienten hemmeligheden (pre_master_secret) ved hjælp af den offentlige nøgle på den ikke-certificerede server. Klienten lærer den offentlige nøgle fra nøgleudvekslingsmeddelelsen fra serveren. Resultatet sendes i en nøgleudvekslingsmeddelelse fra klienten. Da interceptoren ikke kender serverens private nøgle, vil det være umuligt for den at dekryptere hemmeligheden (pre_master_secret). Når du bruger Diffie-Hellman-algoritmen , er serverens offentlige parametre indeholdt i en nøgleudvekslingsmeddelelse fra serveren og sendes til klienten i en nøgleudvekslingsmeddelelse. En interceptor, der ikke kender de private værdier, vil ikke være i stand til at finde hemmeligheden (pre_master_secret).
I dette tilfælde kan nøgleudveksling og servergodkendelse kombineres. Den offentlige nøgle kan også være indeholdt i serverens certifikat, eller der kan bruges en midlertidig RSA -nøgle , som sendes i nøgleudvekslingsmeddelelsen fra serveren. Når en midlertidig RSA-nøgle bruges, signeres udvekslingsmeddelelserne af serverens RSA- eller DSS-certifikat (???). Signaturen indeholder den aktuelle værdi af Client_Hello.random-meddelelsen, så gamle signaturer og gamle midlertidige nøgler kan ikke gentages. Serveren kan kun bruge den midlertidige RSA-nøgle én gang til at oprette en session. Efter at have verificeret serverens certifikat, krypterer klienten hemmeligheden (pre_master_secret) ved hjælp af serverens offentlige nøgle. Ved vellykket afkodning af hemmeligheden (pre_master_secret) genereres en "færdig" besked, der derved demonstrerer over for serveren, at den kender den private nøgle, der svarer til serverens certifikat.
Når RSA bruges til nøgleudveksling, bruges klientcertifikatbekræftelsen til at godkende klienten. Klienten underskriver værdien beregnet fra master_secret og alle foregående handshake-protokolmeddelelser. Disse handshake-meddelelser indeholder et servercertifikat, der matcher serverens signatur med en Server_Hello.random-meddelelse, der matcher signaturen på den aktuelle handshake-meddelelse (???).
I dette tilfælde understøtter serveren muligvis også en parameterspecifik Diffie-Hellman-algoritme eller kan bruge nøgleudvekslingsmeddelelser fra serveren til at sende et sæt midlertidige parametre, der er signeret med DSS- eller RSA-certifikater. Midlertidige parametre hashes med en hello.random-meddelelse før signering for at forhindre en angriber i at gentage gamle parametre. I begge tilfælde kan klienten kontrollere certifikatet eller signaturen for at sikre, at parametrene tilhører serveren.
Hvis klienten har et certifikat, der indeholder parametrene for Diffie-Hellman- algoritmen , så indeholder certifikatet også de oplysninger, der kræves for at fuldføre nøgleudvekslingen. I dette tilfælde skal klienten og serveren generere de samme Diffie-Hellman-resultater (pre_master_secret), hver gang de etablerer en forbindelse. For at forhindre hemmeligheden (pre_master_secret) i at blive lagret i computerens hukommelse i længere tid end nødvendigt, bør hemmeligheden konverteres til den delte hemmelighed (master_secret) så hurtigt som muligt. Klientindstillingerne skal være kompatible med dem, der understøttes af serveren, for at nøgleudvekslingen kan fungere.
Record Layer-protokollen er en lagdelt protokol. På hvert niveau indeholder meddelelser felter for længde, beskrivelse og validering. Skriveprotokollen modtager de beskeder, der skal transmitteres, fragmenterer dataene i håndterbare blokke, komprimerer dataene intelligent ved hjælp af en MAC (meddelelsesgodkendelseskode), krypterer og transmitterer resultatet. Det dekrypterer de modtagne data, kontrollerer, pakker ud, indsamler og leverer til højere niveauer af klienten.
Der er fire optagelsesprotokoller:
Hvis en SSL-implementering modtager en indgangstype, som den ikke kender, ignoreres den indgang simpelthen. Enhver protokol, der er oprettet til at blive brugt i forbindelse med SSL, skal være gennemtænkt, da den skal håndtere angreb på den. Bemærk, at på grund af postens type og længde er protokollen ikke beskyttet af kryptering. Man skal sørge for at minimere trafikken.
En SSL-klient og server er enige om at etablere en forbindelse ved hjælp af en håndtryksprocedure. Under håndtrykket bliver klienten og serveren enige om forskellige parametre, der skal bruges til at sikre forbindelsen:
Dette afslutter håndtrykket og starter en sikker forbindelse, som krypteres og dekrypteres ved hjælp af nøgledata. Hvis noget af ovenstående mislykkes, er SSL-håndtrykket mislykket, og forbindelsen er ikke oprettet.
Der findes en protokol til ændring af krypteringsparameter for at signalere overgangen til krypteringstilstand. Protokollen indeholder en enkelt besked, der er krypteret og komprimeret på den aktuelt etablerede forbindelse. Meddelelsen består kun af én bit med værdien 1.
struct { enum { change_cipher_spec ( 1 ), ( 255 ) } type ; } ChangeCipherSpec ;En chifferændringsmeddelelse sendes af klienten og serveren for at underrette den modtagende part om, at efterfølgende skrivninger vil blive beskyttet i henhold til de nyligt forhandlede CipherSpec og nøgler. Accept af denne meddelelse får modtageren til at instruere skrivelaget om straks at kopiere den ventende læsetilstand til den aktuelle læsetilstand. Umiddelbart efter afsendelse af denne besked skal afsenderen instruere skrivelaget om at ændre tilbageskrivningstilstanden til den aktuelle skrivetilstand. Beskeden om chifferændring sendes under håndtrykket, efter at sikkerhedsparametrene er blevet overført, men før den "færdige" meddelelse sendes.
En af de typer validering, der understøttes i skrive-SSL-protokollen, er alarmprotokollen. Alarmmeddelelsen formidler de vanskeligheder, der opstår i meddelelsen, og en beskrivelse af alarmen. En alarmmeddelelse om kritisk niveau afbryder forbindelsen med det samme. I dette tilfælde kan andre forbindelser, der svarer til sessionen, fortsætte, men sessionsidentifikatoren skal være ugyldig. Som andre meddelelser krypteres og komprimeres alarmmeddelelsen, så snart den aktuelle forbindelsestilstand er angivet.
Dataapplikationsmeddelelsen fungerer på rekordniveau. Den er fragmenteret, komprimeret og krypteret baseret på den aktuelle tilstand af forbindelsen. Meddelelser betragtes som gennemsigtige for registreringslaget.
Der er en række angreb, der kan udføres mod SSL-protokollen. SSL er dog modstandsdygtig over for disse angreb, forudsat at brugeren kun bruger betroede servere til at behandle information. SSL 2.0 er sårbar i nogle situationer [23] :
SSL 2.0 er som standard deaktiveret i browsere, der starter med Internet Explorer 7 [24] , Mozilla Firefox 2 [25] , Opera 9.5 [26] og Safari .
Den 14. oktober 2014 blev en sårbarhed CVE-2014-3566 identificeret, kaldet POODLE (Padding Oracle On Downgraded Legacy Encryption). Denne sårbarhed gør det muligt for en angriber at udføre et Man-in-the-Middle- angreb på en forbindelse, der er krypteret med SSL 3.0. POODLE-sårbarheden er en sårbarhed i protokollen og ikke i nogen af dens implementeringer, så alle forbindelser krypteret med SSL v3 påvirkes af den.
Der er andre svagheder i SSL 3.0. For eksempel afhænger halvdelen af hovednøglen, der indstilles, helt af MD5-hash-funktionen, som ikke er kollisionsbestandig og derfor ikke anses for sikker [27] .
Denne type angreb udføres, når angriberen har en idé om, hvilken type beskeder der sendes.
En kryptoanalytiker kan danne en database, hvor nøglerne er krypterede klartekststrenge. Baseret på den oprettede database kan du bestemme den sessionsnøgle, der svarer til en specifik datablok.
Generelt er sådanne angreb mulige for SSL. Men SSL forsøger at imødegå disse angreb ved at bruge store sessionsnøgler - klienten genererer en nøgle, der er længere end tilladt af eksportrestriktioner, hvoraf en del sendes til serveren i klartekst, og resten kombineres med den hemmelige del for at få en tilstrækkelig lang nøgle (f.eks. 128 bit, som krævet af RC4). Måden at blokere almindeligtekstangreb på er at gøre den nødvendige mængde tekst uacceptabelt stor. Hver bit tilføjet til længden af sessionsnøglen fordobler størrelsen af ordbogen. Brug af en sessionsnøgle på 128 bit gør ordbogens størrelse langt ud over moderne tekniske muligheder (løsningen ville kræve et antal atomer, som ikke findes i hele universet). En anden måde, hvorpå SSL kan imødegå dette angreb, er ved at bruge de maksimalt mulige nøglelængder (i tilfælde af ikke-eksport). Konsekvensen af dette er, at den enkleste og billigste angrebsmetode er et frontalt angreb af nøglen, men for en 128-bit nøgle kan omkostningerne ved at afsløre den betragtes som uendelige.
RefleksionsangrebAngriberen registrerer kommunikationssessionen mellem serveren og klienten. Senere forsøger den at etablere en forbindelse med serveren ved at afspille klientens optagede beskeder. Men SSL afviser dette angreb med en speciel unik forbindelsesidentifikation (IC). Selvfølgelig, teoretisk set, kan en tredjepart ikke forudsige IS, fordi det er baseret på et sæt tilfældige hændelser. En angriber med store ressourcer kan dog logge et stort antal sessioner og forsøge at opfange den "korrekte" session baseret på den besked , som serveren sendte i Server_Hello -meddelelsen . Men SSL -nonces er mindst 128 bit lange, hvilket betyder, at en angriber skal skrive 264 nonces for at få en 50% chance for at gætte. Men 2 64 er et stort nok tal til at gøre disse angreb meningsløse.
HåndtryksprotokolangrebEn angriber kan forsøge at påvirke håndtryksudvekslingen, så parterne vælger forskellige krypteringsalgoritmer, og ikke dem, de normalt vælger. Fordi mange implementeringer understøtter eksporteret kryptering, og nogle endda understøtter 0-kryptering eller MAC, er disse angreb af stor interesse.
For et sådant angreb skal en angriber hurtigt forfalske en eller flere håndtryksmeddelelser. Hvis dette sker, vil klienten og serveren beregne forskellige hashværdier for håndtryksmeddelelsen. Som et resultat vil parterne ikke acceptere " færdige " beskeder fra hinanden . Uden at kende hemmeligheden, vil angriberen ikke være i stand til at rette den færdige besked , så angrebet kan opdages.
Hacking af SSL-forbindelser inde i datacentretDen mest berygtede hændelse med massehacking af information beskyttet af SSL-protokoller blev udført af FBI-agenter ved hjælp af Carnivore og NarusInsight- systemer , hvilket førte til en retssag på vegne af menneskerettighedsorganisationen Electronic Frontier Foundation mod AT&T, som installerede disse komplekser for at knække kryptografisk beskyttede oplysninger.
På trods af det høje offentlige ramaskrig i USA af denne sag og efterforskningen på niveau med Repræsentanternes Hus' forfatningsudvalg, var der ingen teknologisk hacking af SSL-protokollen fra FBI -agenter . Carnivore og NarusInsight blev installeret i selve datacentret , hvor der var servere, der udførte SSL-forbindelser med fjernklienter. NarusInsight gendannede krypteret information fuldstændigt ved ikke at lytte til en SSL-forbindelse, men til intern trafik mellem applikationsservere i selve datacentret, efter at data modtaget via SSL blev dekrypteret af serveren selv, som modtog dem fra eksterne brugere.
Denne hændelse viste dog, at SSL ikke kan være et pålideligt middel til kryptografisk beskyttelse af serverdata på internettet, da specielle tjenester kan installere lyttesystemer såsom NarusInsight eller SORM-2 [28] i datacentret. Enhver form for kryptografi, som indebærer, at nøglerne til chifferne er på modtagerserveren i datacentret, hackes automatisk af efterretningstjenestens sniffere ved at indsprøjte dem i modtageren selv. Yderligere er dataene fuldstændigt rekonstrueret i overensstemmelse med de procedurer, der i øjeblikket er regulerede og lovgivningsmæssige handlinger, såsom " Patriot Act ". Desuden forbyder disse lovgivningsmæssige handlinger, op til retsforfølgelse af datacenterejere, fjernelse af efterretningstjenestesniffere fra den interne del af modtagerserverne. Med disse systemer på plads kan SSL kun sikre en forbindelse mellem to brugere på internettet, ikke en SSL-forbindelse til et eksternt websted.
BEAST angrebDen 23. september 2011 demonstrerede thailandske forskere Duong og Giuliano Rizzo, ved hjælp af en Java-applet, et "proof of concept" kaldet Beast ("Browser Exploit Against SSL/TLS"), hvilket indikerer en sårbarhed i TLS 1.0 [29] [30] . Tidligere var denne sårbarhed, som oprindeligt blev opdaget af Phillip Rogaway [31] i 2002, praktisk talt umulig for nogen at påvise. TLS 1.1-sårbarheden blev rapporteret i 2006.
Angrebet er baseret på flere antagelser, men som det viste sig, er det meget muligt at implementere dem. For det første skal kryptoanalytikeren være i stand til at opsnappe den trafik, der transmitteres af browseren . For det andet er det nødvendigt på en eller anden måde at tvinge brugeren til at overføre data over den samme sikre kommunikationskanal . Lad en sikker forbindelse etableres mellem Bob ( B ) og Alices ( A ) computere. Lad os antage, at den i-te blok af beskeden, der kom til os, indeholder hemmelige oplysninger (for eksempel et kodeord).
C i = E ( Nøgle , Mi xor C i -1 ) , hvor Ci er den krypterede blok, Mi er den hemmelige tekst
Lad os antage, at adgangskoden A er P . Vi kan kontrollere, om vores antagelse er korrekt:
Så vi var i stand til at opsnappe initialiseringsvektoren, som bruges til at kryptere den første blok af den næste besked, men dette er også den sidste blok af den forrige besked (i krypteret form) - IV . Vi opsnappede også C i-1 . Ved hjælp af disse data danner vi en besked, så den første blok bliver lig med følgende:
M 1 = C i-1 x eller IV x eller P
Hvis kryptanalytikeren kan sende meddelelsen over den samme sikre kanal, vil den første blok af den nye meddelelse se sådan ud:
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 viser sig, at hvis P = M , så vil den første krypterede blok af den nye meddelelse C1 være lig med den tidligere opsnappede Ci .
I praksis opstår der et problem: blok M er 16 bytes lang, selvom vi kender alle på nær to bytes, skal vi bruge 2 15 forsøg for at gætte resten. Hvad hvis vi ikke ved noget?
Derfor konklusionen om, at denne praksis kan fungere, hvis kryptoanalytikeren har et begrænset antal antagelser om værdien af M , eller rettere det meste af indholdet af denne blok. Den næste antagelse er, at kryptanalytikeren kan kontrollere placeringen af data i blokken, for eksempel ved, at adgangskoden er n tegn lang. Ved at vide dette arrangerer kryptanalytikeren adgangskoden på en sådan måde, at kun 1 tegn kommer ind i den første blok, og den resterende (n-1) i den næste - det vil sige, de første 15 bytes indeholder kendte data. Og for at gætte 1 karakter skal en angriber i værste fald have brug for 256 forsøg.
Sårbarheden var kendt meget tidligere, men udviklerne af værktøjet er de første, der formåede at implementere alle betingelserne for dette angreb. Nemlig:
Her er en liste over forskellige teknologier og browser-plugins, der kan udføre agentinjektion på offerets browser: Javascript XMLHttpRequest API, HTML5 WebSocket API, Flash URLRequest API, Java Applet URLConnection API og Silverlight WebClient API.
RC4 angrebI 2013 blev der afholdt en konference i Singapore, hvor professor Dan Bernstein præsenterede en ny teknik til at knække SSL/TLS-protokoller ved hjælp af RC4-chifferet, som blev foreslået i 2011 som et forsvar mod BEAST. En sårbarhed fundet i RC4 er relateret til manglen på tilfældighed i den bitstrøm, der forvanskede beskeden. Efter at have kørt det samme budskab igennem det mange gange, blev et tilstrækkeligt antal gentagne mønstre afsløret til at genoprette den originale tekst. For et angreb skal en enorm mængde data køres gennem chifferen. I den præsenterede implementering tog hacking op til 32 timer, men muligheden for at optimere processen var ikke udelukket. Men dette angreb er svært at gennemføre i praksis. Skaberne hævder, at 256 chiffertekster er nødvendige for at gendanne 80 bytes ud af 256 .
Afslørende ciphersSom du ved, afhænger SSL af forskellige kryptografiske parametre. RSA offentlig nøglekryptering er påkrævet til nøgleoverførsel og server/klientgodkendelse. Imidlertid bruges forskellige kryptografiske algoritmer som en chiffer. Så hvis et vellykket angreb på disse algoritmer udføres, kan SSL ikke længere betragtes som sikkert. Et angreb på visse kommunikationssessioner foretages ved at optage sessionen, og derefter vælges sessionsnøglen eller RSA-nøglen over tid.
Man-in-the-middle-angrebOgså kendt som MitM (Man-in-the-Middle) angreb. Det involverer deltagelse af tre parter: serveren, klienten og angriberen imellem. I denne situation kan en angriber opsnappe alle meddelelser, der følger i begge retninger og erstatte dem. Angriberen ser ud til at være serveren til klienten og klienten til serveren. I tilfælde af Diffie-Hellman nøgleudveksling er dette angreb effektivt, da integriteten af den modtagne information og dens kilde ikke kan verificeres. Et sådant angreb er dog ikke muligt ved brug af SSL-protokollen [32] , da certifikater autentificeret af en certifikatmyndighed [33] bruges til at autentificere kilden (normalt serveren) .
Angrebet vil lykkes, hvis:
Denne type angreb kan findes i store organisationer, der bruger Microsoft Forefront TMG - firewallen eller Blue Coat Proxy SG -proxyserveren . I dette tilfælde er den "indtrængende" placeret på kanten af organisationens netværk og erstatter det originale certifikat med sit eget. Dette angreb bliver muligt på grund af evnen til at angive selve proxyserveren som en betroet certificeringsmyndighed (enten som en rod eller som et underordnet af virksomhedens rod). Typisk er en sådan implementeringsprocedure gennemsigtig for brugeren på grund af virksomhedens brugeres arbejde i Active Directory-miljøet. Dette værktøj kan bruges både til at kontrollere de overførte oplysninger og til at stjæle personlige data, der er transmitteret ved hjælp af en sikker HTTPS-forbindelse.
Det mest kontroversielle spørgsmål er brugerens bevidsthed om muligheden for dataaflytning, da der i tilfælde af en udskiftning af rodcertifikater ikke vil blive vist nogen sikkerhedsmeddelelser, og brugeren vil forvente fortroligheden af de transmitterede data.
Når du bruger Forefront TMG som SSL-proxy, er der desuden mulighed for et andet MitM-angreb på internetsiden, da det originale certifikat ikke vil blive overført til brugeren, og Forefront TMG kan konfigureres til at acceptere og derefter erstatte sig selv. -underskrevne eller tilbagekaldte certifikater. For at beskytte mod et sådant angreb er det nødvendigt fuldstændigt at forbyde at arbejde med webservere, hvis certifikater indeholder fejl, hvilket helt sikkert vil føre til manglende evne til at arbejde med HTTPS-protokollen med mange websteder.
Blue Coat Proxy SG er beskyttet mod det andet MitM-angreb: Systemet giver dig mulighed for at konfigurere politikken, så i tilfælde af et webservercertifikat, der ikke er tillid til, udsteder systemet også et certifikat, der ikke er underskrevet af en betroet kæde, men af et midlertidigt selv. -underskrevet en.
THC-SSL-DOSDen 24. oktober 2011 udgav The Hacker's Choice (THC) værktøjet THC-SSL-DOS, som kan bruges til at udføre DoS-angreb på SSL-servere. Dette værktøj udnytter en sårbarhed i SSL-genforhandlingsfunktionen, som oprindeligt blev designet til at gøre SSL mere sikker. Genvalidering giver serveren mulighed for at oprette en ny privat nøgle over en eksisterende SSL-forbindelse. Denne funktion er som standard aktiveret på de fleste servere. Etablering af en sikker forbindelse, samt udførelse af SSL-genvalidering, kræver flere gange flere ressourcer på serversiden end på klientsiden, det vil sige, hvis klienten sender mange SSL-genvalideringsanmodninger, dræner dette serverens systemressourcer.
Ifølge en THC-deltager kræver et vellykket angreb en bærbar computer med værktøjet installeret og internetadgang. Programmet blev offentliggjort i det offentlige domæne, fordi dets modstykke dukkede op på netværket for et par måneder siden. Også ifølge udviklerne kan et angreb udføres, selvom serveren ikke understøtter genvalideringsfunktionen, selvom dette vil kræve ændring af angrebsmetoden. I dette tilfælde er der etableret mange TCP-forbindelser til det nye SSL-håndtryk, men flere bots er nødvendige for et effektivt angreb.
Som et forsvar anbefaler nogle softwareudviklere at opsætte specifikke regler for at afslutte en forbindelse med en klient, der udfører en genvalideringsoperation mere end et bestemt antal gange i sekundet.
I 2009, på en Black Hat-konference i Washington DC, demonstrerede Moxie Marlinspike, en uafhængig hacker, et nyt værktøj , SSLstrip, der kan udtrække vigtig information ved at narre brugere til at tro, at de er på en sikker side, når de ikke er det. Dette kan opnås ved at konvertere normalt SSL-sikrede sider til deres usikre modstykker, hvilket bedrager både serveren og klienten. Hjælpeprogrammet fungerer, fordi mange websteder, der bruger SSL-beskyttelse, har en usikker hjemmeside. De krypterer kun de sektioner, hvor vigtig information overføres. Og når brugeren klikker på autorisationssiden, erstatter værktøjet webstedets svar ved at ændre https til http. SSLstrip bruger følgende teknikker: For det første installeres en proxyserver på det lokale netværk, som har et gyldigt certifikat - herfra fortsætter brugeren med at se https i adresselinjen, for det andet bruges en teknik til at oprette lange URL'er indeholdende falske '/ ' i adresselinjen - dette er nødvendigt for at undgå tegnkonvertering fra browsere. For at bevise, at systemet fungerede, kørte Moxxi SSLstrip på en server, der betjener Tor-netværket , og på 24 timer fiskede han 254 adgangskoder fra brugere af Yahoo , Gmail , Ticketmaster, PayPal og LinkedIn .
I SSL-protokollen er fejlhåndtering meget enkel. Når en fejl opdages, sender den, der opdagede den, en besked om den til sin partner. Fatale fejl kræver, at serveren og klienten lukker forbindelsen [35] . SSL-protokollen definerer følgende fejl:
| Grundlæggende TCP / IP-protokoller efter lag af OSI-modellen | |
|---|---|
| Fysisk | |
| kanaliseret | |
| netværk | |
| Transportere | |
| session | |
| Repræsentation | |
| Anvendt | |
| Andet anvendt | |
| Liste over TCP- og UDP-porte | |
| Internetsikkerhedsmekanismer _ | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Kryptering og trafikfiltrering _ |
| ||||||||||||||
| Godkendelse | |||||||||||||||
| Computerbeskyttelse |
| ||||||||||||||
| IP-telefonisikkerhed |
| ||||||||||||||
| Trafikanonymisering | |||||||||||||||
| Trådløs sikkerhed | |||||||||||||||