Si punon Transport Layer Security (TLS)

Shtoni lidhje
Nga Wikipedia, enciklopedia e lirë

TLS qëndron për Transport Layer Protocol, ku me anë të këtij protokoli kriohet mundësia e komunikimit të sigurtë nëpërmjet dy palëve (klientit dhe serverit) nëpërmjet një mediumi jo të sigurtë siç është interneti. Kjo bëhet më së shpeshti për arsye të komercionalitetit elektronik - e-commerce. Pra, TLS përdoret për të krijuar siguri në shërbimet e Web-it. Më saktësisht, TLS siguron një lidhje të sigurtë nga kompjuteri jonë deri tek kompjuteri I kompanisë, ashtu që sulmuesit nuk mund të kapin informatat gjatë rrugëtimit të tyre. Gjithashtu, e siguron klientin që është duke punuar me një kompani të besueshme. Si rezultat, nëse klienti punon me një kompani që është e besueshme, duke përdorur një lidhje të sigurtë, shkëmbimi I të dhënave të ndjeshme siq janë numrat e xhirollogarisë, fjalëkalimet dhe të dhënat tjera private do të jetë I sigurtë.[1]

Siguria e TLS[Redakto | Redakto nëpërmjet kodit]

Nëse shqyrtojmë rastin e një web-serveri I cili punon me anë të TLS, atëherë ky server ofron:

  • Privatësi – Duke parandaluar përgjimin gjatë komunikimit mes klientit dhe serverit
  • Autentifikim – Duke parandaluar vjedhjen e identitetit të kompanisë që ka në pronësi web-faqen e përdorur me TLS
  • Integritet – Duke parandaluar modifikime të mesazheve gjatë shkëmbimeve të tyre[2]


Arkitektura e TLS[Redakto | Redakto nëpërmjet kodit]

TLS është I dizajnuar që të përdor TCP për të jepur një shërbim të besueshëm dhe të sigurtë ndërmjet 2 palëve. Besueshmërinë e përkrahë TCP, përderisa TLS e jep sigurinë. TLS nuk është një protokol I vetëm, por mund të thuhet që përbehet prej 2 shtresave të protokoleve, atë të TLS Record Protocol dhe TLS Handshake Protocol, sikurse në figurën 1.1.

Fig 1.1 - Arkitektura e TLS

TLS Record Protokol, siq shihet në figurën më lartë, jep shërbime të sigurta për protokolet e shtresave më të larta. Shembull, Hypertext Transfer Protocol(HTTP), e cila jep shërbimin e transferit gjatë ndërveprimit të web klientit dhe serverit, mund të operoj mbi TLS. Tri protokole të shtresës më të lartë të definuar sipas TLS janë: TLS Handshake Protocol, TLS Change Cipher Spec Protocol si dhe TLS Alert Protocol. Këto protokole shërbejnë për menagjimin e shkëmbimit të informatave të TLS.[3]

TLS Record Protocol[Redakto | Redakto nëpërmjet kodit]

TLS Record Protocol jep dy shërbime për TLS konektimet:

  • Konfidencialitetin – Handshake Protokoli definon çelësin sekret I cili përdoret për enkriptim - Me anë të konfidencialitetit arrihet siguria që informatat sensitive nuk janë përgjuar, ose edhe nëse janë përgjuar, janë të palexueshme për sulmuesit
  • Integritetin e mesazhit – Handshake Protokoli gjithashtu definon çelësin sekret I cili përdoret për të formuar kodin e autentifikimit (message authentification code, MAC) - Me anë të integritetit arrihet siguria për mosndryshim të informatës gjatë transmetimit

Se si punon ky protokol, mund t’a analizojmë nëpërmjet figurës 1.2 në vijim.

Fig 1.2 - Si punon TLS Record Protocol

Record Protocol siç shihet nga figura, së pari merr një mesazh nga shtresa e aplikacionit për t’a transmetuar atë dhe e fragmenton atë në blloqe menagjuese. Pastaj, një metodë për kompresim të blloqeve përdoret (është opcionale, mund të mos përdoret fare. TLS nuk e përdor kompresimin, prandaj algoritmi për kompresim është null). Hapi tjetër I procesimit është njehsimi I message authentication code (MAC), mbi të dhënat e kompresuara dhe aplikimi I tij në këto fragmente. Pastaj vazhdon procesi me enkriptim të këtyre fragmenteve së bashku me MAC të shtuar, e që vazhdon me futjen e një header-I dhe pastaj rezultatin e fituar e dërgon tek protokoli TCP. Të dhënat e pranuara janë të dekriptuara, verifikuara, dekompresuara nëse është përdorur algoritëm për kompresim dhe të rigrumbulluara para se të dërgohen tek përdoruesit në nivel më të lartë.

Disa sqarime për pikat e cekura më lartë:

Fragmentimi[Redakto | Redakto nëpërmjet kodit]

Mesazhin nga shtresa më e lartë e fragmenton në blloqe (të quajtura TLSPlaintext records) jo më të mëdha se 214 bytes apo 16384 bytes.

Kompresimi dhe dekompresimi[Redakto | Redakto nëpërmjet kodit]

Kompresimi është opcionale. Algoritmi për kompresim TLSPlaintext strukturën e kthen në TLSCompressed strukturë. Kompresimi nuk guxon që ta rrit madhësinë e bllokut për më shumë se 1024 bytes (Edhe pse kompresimi bëhet për të reduktuar madhësinë e byte-ave, nëse blloku është shumë I vogël, atëherë për shkak të ndryshimit të strukturës mund të rritet numri I byte-ave). Kompresimi, nëse aplikohet, duhet të bëhet gjithmonë para enkriptimit dhe njehsimit të MAC, e poashtu duhet të sigurojë që TLSPlaintext struktura do të jetë identike pasi të kompresohet dhe dekompresohet.

MAC[Redakto | Redakto nëpërmjet kodit]

MAC(Kodi autentifikues i mesazhit) gjithmonë njehsohet para se të bëhet enkriptimi. Të shqyrtojmë se si njehsohet MAC nëpërmjet figurës 1.3 në vijim.

Fig 1.3 - Si njehsohet MAC (Kodi autentifikues i mesazhit)

Duke përdorur një çelës sekret, dhe duke u bazuar në figurën në anën e djathtë të tekstit, njehsimin e MAC mund t’a definojmë në këtë mënyrë :

  • H1 = hash(MAC-write-secret || pad-1 || seq-num || TLSCompressed.type || TLSCompressed.length || TLSCompressed.fragment)
  • H = hash(MAC-write-secret || pad-2 ||H1)

Ku parametrat e përdorur kanë këtë kuptim:

  • Mac-write-secret – çelësi sekret
  • Hash (H1 dhe H) – Hash algoritmet kriptografike
  • Pad-1 – bajti 0x36 (0011 0110) I cili është I përsëritur 48 herë (384 bits) për MD5 dhe 40 herë (320 bits) për SHA-1
  • Pad-2 – Bajti 0x5C (0101 1100) I përsëritur 48 herë për MD5 dhe 40herë për SHA-1.
  • Seq-num – Sekuencë e numrave për këtë mesazh (secila palë menaxhon një sekuencë të numrave për mesazhet e transmetuara apo të pranuara për secilin konektim).
  • TLSCompressed.type – një protokol I nivelit më të lartë I përdorur për të procesuat këtë fragment.
  • TLSCompressed.length – gjatësia e fragmentit të kompresuar.
  • TLSCompressed.fragment – fragmenti I kompresuar(apo fragment plainteksti nëse nuk është kompresuar)
  • || - Simboli I konkatinimit (bashkimit).

Enkriptimi[Redakto | Redakto nëpërmjet kodit]

Pastaj, mesazhi I kompresuar e poashtu edhe MAC enkriptohen duke përdorur enkriptimin simetrik, ku, bllok koduesit (block ciphers) të cilat përdoren si algoritme enkriptike në këtë rast janë:

  • DES(56)
  • Triple DES(168)
  • IDEA(128)
  • RC5(variable)
  • Fortezza(80)

Ku numrat brenda kllapave e tregojnë madhësinë efektive të çelësit. Madhësia totale e të dhënave(plantext + MAC) për t’u enkriptuar duhet që të jenë për nga gjatësia shumëfish I gjatësisë së bllokut të Cipher-it (koduesit). Padingu formohet duke ia shtuar ‘1’ bit tek fundi I mesazhit, dhe pastaj duke I shtuar ‘0’ bitat, sado që të nevojiten që të arrihet shumëfishi I gjatësisë së bllokut. 64bitët e fundit të madhësisë totale të padding-ut janë të rezervuara për gjatësinë e mesazhit origjinal.[4]

Shtimi I TLS record header[Redakto | Redakto nëpërmjet kodit]

Procesi final I protokolit TLS Record Protocol është shtimi I një TLS record header. Një header përbëhet prej këtyre fushave:

Fig 1.4 - Formati i TLS Record-it
  • Content Type(8bits) – Protokoli I shtresës më të lartë I përdorur për të procesuar mesazhin I cili dërgohet për t’u fragmentuar.
  • Major Version(8bits) – Tregon versionin më të ri të TLS që mund të përdoret. Për TLSv1, vlera e kësaj është 3.
  • Minor Version(8bits) – Tregon versionin më të vjetër që mund të përdoret. Për TLSv1, kjo vlerë është 0.

4.Compressed Length(16bits) – Gjatësia në bytes e fragmentit të plaintext-it( ose fragmentit të kompresuar nëse është përdorur ndonjë algoritëm për kompresim). Vlera maksimale e kësaj mund të jetë 214 + 2048.

Content types të cilat u përmendën janë change_cipher_spec, alert, handshake dhe application_data, ku tri të parat janë protokole specifike të TLS. Siq po shihet, nuk u bë ndonjë veqim për aplikacione të ndryshme(psh HTTP) të cilët mund të përdorin TLS; përmbajtja e të dhënave të krijuar nga këto aplikacione nuk I intereson TLS. . Pamja e ilustruar e një TLS Record formati, shih figurën 1.4 :


Change Cipher Spec Protocol[Redakto | Redakto nëpërmjet kodit]

Fig 1.5 - Change Cipher Spec Protokoli

Change Cipher Spec Protocol është një nga tri protokolet specifike të TLS, të cilat I përdor TLS Record Protokoli, dhe është shumë I thjeshtë. Ky protokol përbëhet prej vetëm një mesazhi I cili e ka një byte të vetëm dhe egziston për t’a azhornuar(update) të ashtuquajturën “Cipher suite” për t’u përdorur gjatë konektimit, ashtu që lejon që në një TLS sesion të ndodhin ndryshime. Thënë më ndryshe, duke parasysh që kemi dy gjendje të këtij protokoli, qëllimi I këtij mesazhi është që `pending state` ta kopjoj tek `current state`, e cila e azhornon “cipher suite” për përdorim gjatë lidhjes në mes dy palëve. Shih fig 1.5 :

Cipher suite : Definon një set të algoritmeve kriptografike që përdoren gjatë komunikimit në mes të klientit dhe serverit.

TLS Alert Protocol[Redakto | Redakto nëpërmjet kodit]

Fig 1.6 - TLS Protokoli paralajmerues

Ky protokol sinjalizon probleme të cilat mund të shkaktohen gjatë një TLS Sesioni. Secili mesazh nga ky protokol përbëhet nga 2 byte. Byte-I I parë specifikon vlerën që tregon për nivelin e problemit, a është vetëm një paralajmërim, apo është diqka fatale. Nëse niveli I këtij mesazhi alarmues është fatal, atëherë lidhja në mes të klientit dhe serverit shkatërrohet menjëherë dhe asnjë konektim I ri për atë sesion nuk mund të vendoset. Byte I dytë përbëhet prej një kodi I cili tregon për domethënien e mesazhit alarmues. Shih këtë protokol të ilustruar në figurën 1.6 :

Kodet e TLS Alert Protocol[Redakto | Redakto nëpërmjet kodit]

Kodet e TLS Alert Protocol, të cilat janë të definuara:

  • Unexpected_message – tregon që një mesazh I papërshtatshëm është pranuar dhe kjo është fatale për implementimin e komunikimit ndërmjet klientit dhe serverit.
  • Bad_record_mac – Ky sinjal dërgohet atëherë kur rekordi I pranuar ka MAC jo korrekt. Ky mesazh gjithmonë është fatal.
  • Decompression_failure – Funksioni për dekompresim ka pranuar hyrje jo të përshtatshme (psh. E dhëna e cila e kalon gjatësinë e lejuar). Mesazhi gjithmonë është fatal.
  • Handshake_failure – tregon që klienti e ka pasur të pamundshëm të negociojë për një set të parametrave të sigurisë, për shkak të opcioneve të limituara të këtyre parametrave të përkrahur nga pala e dërguesit. Mesazhi është fatal.
  • No_certificate – Mund të dërgohet për shkak të shkak të kërkesës për certifikatë, ku marrësi I kësaj kërkese nuk ka certifikatë të disponueshme.
  • Bad_certifikate – Ky mesazh kthehet kur certifikata është e korruptuar, zakonisht kur përmban një nënshkrim digjital që nuk është verifikuar në mënyrë të saktë.
  • Unsupported_certificate – Certifikata është e një tipi që nuk përkrahet.
  • Certifikate_revoked – Certifikata është anuluar nga nënshkruesi.
  • Certificate_expired – Certifikatës I ka kaluar data e validimit dhe nuk është më valid.

10.Illegal_parameter – kur një fushë në handshake është e papajtueshme me fushat tjera. Kjo është gjithmonë fatale.[5]


Handshake Protocol[Redakto | Redakto nëpërmjet kodit]

TLS Handshake Protocol e përdor TLS Record Protocol për të shkëmbyer një seri të mesazheve ndërmjet një TLS të lëshuar në server dhe një TLS të lëshuar tek klienti, kur këto dy të fundit e vendosin një TLS Konektim. Shkëmbimi I këtyre mesazheve është I dizajnuar që të mundësojnë këto aksione:

  • Autentifikimi I serverit tek klienti
  • Mundësia që klienti dhe serveri të zgjedhin algoritme kriptografike, ose ‘ciphers’ (kodues), të cilat që të dy palët I përkrahin ato.
  • Në mënyrë opcionale, të bëhet autentifikimi I klientit tek serveri (kjo pasi që, si arsye kryesore e TLS, është fitimi I besimit nga ana e klientit për serverin që po komunikon)
  • Përdorimi I çelësave publik për të gjeneruar çelësa sekret të cilat I ndajnë klienti dhe serveri ndërmjet vete.
  • Të vendosin një konektim TLS të enkriptuar

Veprimet e TLS Handshake Protocol[Redakto | Redakto nëpërmjet kodit]

Një TLS sesion fillon atëherë kur klienti konektohet me TLS serverin. Do të thotë që klienti është ai që e fillon sesionin dhe komunikimin me server.

  • Në momentin që një TLS sesion startohet, në atë moment edhe protokoli TLS Handshake fillon punën.
  • Vendosen protokolet të cilat përdoren për komunikim.
  • Algoritmet kriptografike zgjidhen me marrëveshje ndërmjet klientit dhe serverit, edhe pse kjo nuk vërehet nga përdoruesit.
  • Klienti dhe serveri autentifikohen.
  • Një master secret krijohen duke përdorur çelësin publik për enkriptim.

Një master secret krijohet nga një premaster secret I cili dërgohet nga klienti. Ky përdoret për t’I gjeneruar katër sesion çelësa ( që përdoren vetëm për një sesion):

  • Një çelës për enkriptim për të dhënat ë cilat dërgohen nga klienti për tek serveri.
  • Një çelës për enkriptim për të dhënat të cilat dërgohen nga serveri për tek klienti.
  • Një çelës autentifikues për të dhënat të cilat dërgohen nga klienti për tek serveri.
  • Një çelës autentifikues për të dhënat të cilat dërgohen nga serveri për tek klienti.


Hapat të cilat I ndjek TLS Handshake Protocol[Redakto | Redakto nëpërmjet kodit]

Siq u cek në formë të shkurtë edhe më herët, një TLS sesion gjithmonë me një shkëmbim të mesazheve, të cilat përkrahen nga TLS Handshake Protocol. Hapat të cilat I ndjek TLS Handshake gjatë shkëmbimeve të mesazheve janë:

Fig 1.7 - TLS Handshake Protokoli
  • Klienti dërgon tek serveri TLS versionin që e përdor klienti, ciphers që I përkrah, gjeneron disa të dhëna random dhe I dërgon të gjitha këto informata të cilat serveri duhet t’I dijë në mënyrë që të komunikojë me klientin duke e përdorur TLS.
  • Serveri I dërgon klientit TLS versionin të cilin e përdor serveri, cipher-in, disa të dhëna të gjeneruara random, dhe I dërgon këto informata klientit, informata këto të cilat klienti duhet t’I dijë që të komunikojë me serverin. Serveri gjithashtu I dërgon certifikatën e tij digjitale. Nëse klienti kërkon ndonjë resurs të serverit I cili e obligon autentifikimin e klientit, atëherë serveri ia dërgon edhe një kërkesë klientit për certifikatën digjitale të klientit.
  • Pas dërgimit të TLS versionit dhe setit të algoritmeve që I përkrah klienti tek serveri, parametrat kriptografik të cilat I kthen serveri tek klienti, janë ato të cilat përdoren gjatë komunikimit të këtyre dy palëve.
  • Klienti, informatat e pranuara nga serveri, këtu duke përfshirë certifikatën digjitale të serverit, I përdor për t’a autentifikuar serverin. Nëse serveri nuk mund të autentifikohet, përdoruesi njoftohet për problemin që nuk mund t’I besohet këtij serveri, dhe se nuk mund të vendos një konektim të sigurtë, të autentifikuar dhe të enkriptuar me këtë server. Nëse serveri mund të autentifikohet me sukses, atëherë klienti vazhdon më tutje me konektim me serverin.
  • Duke I përdorur të gjitha të dhënat të gjeneruara deri më tani me anë të handshake, klienti krijon një premaster secret për këtë sesion, e enkripton aë me çelësin publik të serverit ( të marrë nga certifikate digjitale e serverit) dhe e dërgon këtë premaster secret tek serveri.
  • Nëse serveri ka kërkuar nga klienti autentifikim ( që është një hap opcional në handshake), klienti gjithashtu e nënshkruan një pjesë të të dhënave që është unike për këtë handshake dhe që dihet nga të dy palët, edhe nga ana e klientit, edhe nga ana e serverit. Në këtë rast, klienti I dërgon të dyja, të dhënën e nënshkruar dhe certifikatën digjitale të klientit tek serveri, së bashku me premaster secret të enkriptuar me çelësin publik të serverit, siq u cek në hapin paraprak.
  • Nëse serveri ka kërkuar autentifikim të klientit, serveri do të tentojë që të autentifikojë klientin. Nëse klienti nuk mund të autentifikohet, sesioni përfundon. Nëse klienti autentifikohet me sukses tek serveri, atëherë serveri e përdor çelësin privat të tij për të dekriptuar ‘premaster secret’, dhe pastaj pastaj I performon një seri të hapave të cilat edhe klienti I performon, duke filluar nga `premaster secret` I njëjtë dhe I njohur nga të dy palët, të gjeneroj `master secret`.
  • Që të dy, edhe klienti, edhe serveri, e përdorin këtë master secret që të gjenerojnë çelësat e sesionit të cilët janë çelësa simetrik dhe përdoren për të enkriptuar dhe dekriptuar informatat e shkëmbyera gjatë TLS sesionit. Gjithashtu përdoren edhe për të verifikuar integritetin e tyre.
  • Klienti e informon serverin se mesazhet të cilat do t’I dërgojë tek klienti tani e tutje do të enkriptohen me sesion çelësin. Pastaj dërgon një mesazh të ndarë dhe të enkriptuar në mënyrë që të tregoj që klienti I ka përmbushur detyrat e tij të handshake protokolit dhe se I ka përfunduar të gjitha hapat sipas handshake protokolit.
  • Serveri pastaj dërgon një mesazh tek klienti duke e informuat që mesazhet që tani e tutje do të dërgohen nga serveri do të enkriptohen me një sesion çelës. Pastaj e dërgon një mesazh të ndarë dhe të enkriptuar me të cilin tregon që serveri I ka përmbushur detyrat e tij të handshake protokolit dhe se I ka përfunduar të gjitha hapat sipas handshake protokolit.
  • Tani, TLS handshake kompletohet, dhe TLS sesioni fillon. Klienti dhe serveri I përdorin sesion çelësat për të enkriptuar dhe dekriptuar të dhënat të cilat I dërgojnë njëri tjetrit, informata këto të cilat mund të jenë numrat e xhirollogarisë, të dhëna private apo çfardo informate tjetër e cila nevojitet të shkëmbehet e sigurtë.[6]


Referimet[Redakto | Redakto nëpërmjet kodit]

  1. ^ Cryptography and Network Security – William Stallings, 489
  2. ^ High Performance Browser Networking - O'Reilly, Section of Encryption, Authentication, and Integrity
  3. ^ High Performance Browser Networking - O'Reilly, Section of entrance, Chapter 4
  4. ^ Cryptography and Network Security – William Stallings, fq.491 - 493
  5. ^ Internet Security Cryptographic Principles, Algorithms and Protocols - Man Young Rhee, fq. 282 - 285
  6. ^ Cryptography and Network Security - William Stallings, 5th edition, fq. 495 - 501
Marrë nga "https://sq.wikipedia.org/w/index.php?title=Si_punon_Transport_Layer_Security_(TLS)&oldid=2032393"