Serveri TLS që. TLS dhe SSL: Dituria minimale e kërkuar. Informacion rreth bërjes së ndryshimeve në regjistër

Përshkrim

TLS u mundëson aplikacioneve të klientëve për të komunikuar në rrjet në mënyrë të tillë që të parandalojnë dëgjimin dhe qasjen e paautorizuar.

Meqenëse shumica e protokolleve të komunikimit mund të përdoren si me dhe pa TLS (ose SSL), kur lidhja është e instaluar, është e nevojshme të specifikoni në mënyrë eksplicite serverin, nëse klienti dëshiron të instalojë TLS. Kjo mund të arrihet ose duke përdorur një numër të unifikuar të portit, me të cilin lidhja gjithmonë është instaluar duke përdorur TLS (si Port 443 për HTTPS), ose duke përdorur një port arbitrar dhe një komandë të veçantë për të kaluar në lidhjet TLS duke përdorur mekanizma të veçantë . Protokoll (të tilla si startttls për protokollet e postës elektronike). Pasi klienti dhe serveri ranë dakord për përdorimin e TLS, ata duhet të instalojnë një lidhje të sigurt. Kjo është bërë duke përdorur procedurën e konfirmimit të komunikimit (Eng. Shtresa të sigurta të socket.). Gjatë këtij procesi, klienti dhe serveri marrin një marrëveshje mbi parametrat e ndryshëm të kërkuar për të instaluar një lidhje të sigurt.

Ka edhe mundësi për sulme të bazuara drejtpërdrejt në zbatimin e programit të protokollit, dhe jo në algoritmin e saj.

Procedura e konfirmimit të komunikimit në TLS në detaje

Sipas protokollit të TLS, aplikacionet e këmbimit të aplikacioneve që përfshijnë informacionin (të ruajtura brenda vetes) për t'u transmetuar. Secila nga të dhënat mund të ngjeshen, të plotësohen, të kodohen ose të identifikohen nga MAC (kodi i vërtetimit të mesazhit) në varësi të gjendjes aktuale të lidhjes (statusi i protokollit). Çdo hyrje në TLS përmban fushat e mëposhtme: lloji i përmbajtjes (përcakton llojin e përmbajtjes së regjistrimit), fusha që tregon gjatësinë e paketës dhe fushën që tregon versionin e protokollit të TLS.

Kur lidhja është instaluar vetëm, ndërveprimi shkon në protokollin e duarve të TLS, lloji i përmbajtjes. e cila 22.

Konfirmimi i thjeshtë i komunikimit në TLS

1. Negociatat e fazës:
   • Klienti dërgon një mesazh Klientedhello.
   • Serveri përgjigjet me mesazhin Serverhello.
   • Serveri dërgon një mesazh Certifikatë.
   • Serveri dërgon një mesazh Serverhellodone
   • Klienti takon mesazhin Clientkeyexchange.E cila përmban çelësin publik të PremastersKet (kjo premasterscet është e koduar duke përdorur çelësin publik të certifikatës së serverit.) ose asgjë (sërish varet nga algoritmi i enkriptimit);
   • PremastersEkret.
2. Klienti dërgon një mesazh Changeciferspec.
   • Klienti dërgon një mesazh Përfundoi
3. Serveri dërgon Changeciferspec.

Konfirmimi i autentifikimit të klientit

NË ky shembull Tregohet autentifikimi i plotë i klientit (përveç autentifikimit të serverit, si në shembullin e mëparshëm) duke përdorur shkëmbimin e certifikatës midis serverit dhe klientit.

1. Negociatat e fazës:
   • Klienti dërgon një mesazh Klientedhello., duke treguar versioni i fundit Protokolli i mbështetur TLS, numri i rastësishëm dhe një listë e metodave të mbështetura të enkriptimit dhe kompresimit të përshtatshme për të punuar me TLS;
   • Serveri përgjigjet me mesazhin Serverhello.Që përbëhet nga: versioni i përzgjedhur i serverit të protokollit, një numër i rastësishëm i dërguar nga klienti, një encryption i përshtatshëm dhe algoritmi i kompresimit nga lista e ofruar nga klienti;
   • Serveri dërgon një mesazh Certifikatë.e cila përmban një certifikatë digjitale të serverit (në varësi të algoritmit të enkriptimit, ky hap mund të humbet);
   • Serveri dërgon një mesazh Certifikatëe cila përmban një kërkesë të certifikatës së klientit për autentifikim të ndërsjellë;
   • [Mungon një klauzolë dhe verifikimin e certifikatës së klientit] ;
   • Serveri dërgon një mesazh Serverhellodoneidentifikon fundin e konfirmimit të komunikimit;
   • Klienti takon mesazhin Clientkeyexchange.e cila përmban çelësin publik të PremastersKet (asgjë (nuk varet përsëri nga algoritmi i enkriptimit);
   • Klienti dhe serveri duke përdorur çelësin PremastersEkret. Dhe numra të gjeneruar rastësisht, llogarisin çelësin e përgjithshëm të fshehtë. Të gjitha informatat e tjera në lidhje me çelësin do të merren nga çelësi i përgjithshëm i përgjithshëm (dhe i gjeneruar nga klienti dhe serveri i vlerave të rastësishme);
2. Klienti dërgon një mesazh Changeciferspec.Kjo tregon se të gjitha informatat pasuese do të kodohen në procesin e konfirmimit nga algoritmi, duke përdorur një çelës të përbashkët sekret. Këto janë mesazhe të të dhënave dhe për këtë arsye ka tipin 20, jo 22;
   • Klienti dërgon një mesazh Përfundoie cila përmban hash dhe Mac të krijuara në bazë të procedurës së konfirmimit të mesazheve të mëparshme;
   • Serveri përpiqet të dekriptojë mesazhin e fundit të klientit dhe të kontrollojë hash dhe WT. Nëse procesi i decryption ose verifikimit dështon, lidhja konsiderohet e dështuar, dhe lidhja duhet të pritet.
3. Serveri dërgon Changeciferspec. Dhe mesazhi i koduar i përfunduar, dhe nga ana tjetër, klienti kryen edhe decryption dhe verifikim.

Nga kjo pikë, lidhja konsiderohet e përfunduar, është themeluar protokolli. Të gjitha përmbajtjet pasuese të paketave janë me tipin 23 dhe të gjitha të dhënat do të kodohen.

Rinovimi i lidhjeve TLS

Algoritmet e enkriptimit asimetrik të përdorura gjatë gjenerimit të një çelësi të sesionit zakonisht janë të shtrenjta nga pikëpamja e kapaciteteve informatike. Për të shmangur përsëritjet, kur rinovimi i lidhjes TLS krijon një shkurtore të veçantë kur konfirmojnë komunikimin e përdorur për të rifilluar lidhjen. Në të njëjtën kohë, me konfirmimin e zakonshëm të komunikimit, klienti shton mesazhin Klientedhello. Identifikues i seancës së mëparshme iD e sesionit. Klienti lidh identifikuesin iD e sesionit Me adresën IP të serverit dhe portin TCP në mënyrë që kur lidhni me serverin, mund të përdorni të gjitha parametrat e lidhjes së mëparshme. Serveri e krahason identifikuesin e seancës së mëparshme. iD e sesionit Me parametrat e lidhjes, të tilla si algoritmi i përdorur encryption dhe sekret master. Të dyja palët duhet të kenë të njëjtin sekret master, përndryshe lidhja nuk do të instalohet. Kjo parandalon përdorimin iD e sesionit Kriptanalitik për qasje jo bankare. Sekuenca digjitale të rastësishme në mesazhe Klientedhello. dhe Serverhello. Ju lejojnë të siguroni që çelësi i sesionit të gjeneruar do të ndryshojë nga çelësi i sesionit në lidhjen e mësipërme. Në RFC, ky lloj konfirmimi i lidhjes është quajtur shkurtuar.

1. Negociatat e fazës:
   • Klienti dërgon një mesazh Klientedhello., duke treguar versionin më të fundit të protokollit të mbështetur TLS, një numër të rastësishëm dhe një listë të metodave të mbështetura të encryption dhe compression të përshtatshme për të punuar me TLS; Gjithashtu, mesazhi shton identifikuesin e lidhjes së mëparshme iD e sesionit.
   • Serveri përgjigjet me mesazhin Serverhello.Që përbëhet nga: serveri i përzgjedhur nga serveri, një numër i rastësishëm i dërguar nga klienti, një encryption i përshtatshëm dhe algoritëm compression nga lista e ofruar nga klienti. Nëse serveri mësoi identifikuesin e sesionit iD e sesionit Serverhello. I njëjti identifikues iD e sesionit. Ky është një sinjal i klientit që mund të përdorni rifillimin e seancës së mëparshme. Nëse serveri nuk e njohu identifikuesin e sesionit iD e sesionitPastaj ai shton mesazhin Serverhello.një vlerë tjetër në vend iD e sesionit. Për klientin, kjo do të thotë se është e pamundur të përdoret një lidhje e rifilluar. Kështu, serveri dhe klienti duhet të kenë të njëjtin mjeshtër të fshehtë dhe numra të rastësishëm për të gjeneruar një çelës të sesionit;
2. Klienti dërgon një mesazh Changeciferspec.Kjo tregon se të gjitha informatat e mëvonshme do të kodohen në procesin e konfirmimit të komunikimit me një çelës të përbashkët sekret. Këto janë mesazhe të të dhënave dhe për këtë arsye ka tipin 20, jo 22;
3. Klienti dërgon një mesazh Changeciferspec.Kjo tregon se të gjitha informatat pasuese do të kodohen në procesin e konfirmimit nga algoritmi, duke përdorur një çelës të përbashkët sekret. Këto janë mesazhe të të dhënave dhe për këtë arsye ka tipin 20, jo 22;
   • Klienti dërgon një mesazh Përfundoie cila përmban hash dhe Mac të krijuara në bazë të procedurës së konfirmimit të mesazheve të mëparshme;
   • Serveri përpiqet të dekriptojë mesazhin e fundit të klientit dhe të kontrollojë hash dhe WT. Nëse procesi i decryption ose verifikimi dështon, lidhja konsiderohet e dështuar, dhe përbërja duhet të pritet;
4. Serveri dërgon Changeciferspec. Dhe mesazhi i koduar i përfunduar, dhe nga ana tjetër, klienti kryen edhe decryption dhe verifikim.

Nga kjo pikë, lidhja konsiderohet e përfunduar, është themeluar protokolli. Të gjitha përmbajtjet pasuese të paketave janë me tipin 23 dhe të gjitha të dhënat do të kodohen.

Përveç performancës së performancës, algoritmi i rifillimit mund të përdoret për të zbatuar një hyrje të vetme, sepse është e garantuar që seanca fillestare, si dhe çdo sesion i rifilluar, është iniciuar nga i njëjti klient (RFC 5077). Kjo është veçanërisht e rëndësishme për zbatimin e FTP përmes protokollit TLS / SSL, i cili përndryshe do të ishte i prekshëm ndaj sulmit të personit në mes, në të cilin sulmuesi mund të kapte përmbajtjen e të dhënave kur u krijua ri-lidhja .

Algoritme të përdorura në tls

Në këtë version të tanishëm të protokollit, janë në dispozicion algoritmet e mëposhtme:

• Për të shkëmbyer çelësat dhe verifikimin e autenticitetit të tyre, zbatohen kombinime të algoritmeve: RSA (shifër asimetrike), diffie-hellman (shkëmbim i sigurt kyç), DSA (algoritmi i nënshkrimit digjital) dhe algoritmet e teknologjisë Fortezza;
• Për encryption simetrik: rc2, rc4, ideja, des, trefishtë des ose AES;

Algoritmet mund të plotësohen në varësi të versionit të protokollit.

Krahasim me analogët

Një nga aplikacionet e lidhjes TLS është lidhja e nyjave në rrjetin privat virtual. Përveç TLS, mund të përdoret edhe shkrimi i protokollit IPSEC dhe SSH. Secila prej këtyre qasjeve në zbatimin e rrjetit privat virtual ka avantazhet dhe disavantazhet e tij. .

1. TLS / SSL.
   • Përfitimet:
     • I padukshëm për protokollet e nivelit më të lartë;
     • Popullariteti i përdorimit në lidhjet e internetit dhe aplikacionet e e-commerce;
     • Mungesa e një lidhjeje të përhershme midis serverit dhe klientit;
     • TCP / IP, të tilla si mjetet e email-it, programet etj.
   • Disavantazhet:
     • UDP dhe ICMP;
     • Nevoja për të ndjekur gjendjen e përbërë;
     • Disponueshmëria e kërkesave shtesë për softuer Rreth mbështetjes për TLS.
2. Ipsec.
   • Përfitimet:
     • Siguria dhe besueshmëria e mbrojtjes së të dhënave të protokollit verifikohet dhe vërtetohet, pasi që protokolli është miratuar si një standard i internetit;
     • Puna në shtresën më të lartë të protokollit të rrjetit dhe encryption e të dhënave në nivelin e protokollit të rrjetit.
   • Disavantazhet:
     • Kompleksiteti i zbatimit;
     • Kërkesa shtesë për pajisjet e rrjetit (routers, etj.);
     • Ka shumë implementime të ndryshme jo gjithmonë të ndërlidhura me njëri-tjetrin.
3. Ssh.
   • Përfitimet:
     • Ju lejon të krijoni një tunel për aplikacione duke përdorur TCP / IP, të tilla si mjetet e programimit, etj;
     • Shtresa e sigurisë janë të padukshme për përdoruesit.
   • Disavantazhet:
     • Vështirësia e përdorimit të rrjeteve me një numër të madh të portave, të tilla si routers ose firewalls;
     • Pamundësia për t'u përdorur me protokollet UDP dhe ICMP.

Shiko gjithashtu

Lidhje

1. T. Dierks, E. rescorla Protokolli i Sigurisë së Shtresës së Transportit (TLS), versioni 1.2 (gusht 2008). Arkivuar nga burimi origjinal më 9 shkurt 2012.
2. Protokolli SSL: Version 3.0 SSL i Netscape SSL 3.0 Draft (18 nëntor 1996)
3. "SSL / TLS në detaje". Microsoft Technet.. Përditësuar më 31 korrik 2003.
4. Dan Goodin. . Regjistri. (19 shtator 2011). I arkivuar
5. Eric resscorla Kuptimi i sulmit të rinegociimit të TLS. Supozime të arsimuara. (5 nëntor 2009). Arkivuar nga burimi origjinal 9 shkurt 2012. Kontrolluar më 7 dhjetor 2011.
6. McMillan, Robert.. Siguria Pro thotë se sulmi i ri SSL mund të godasë shumë vende, PC World (20 nëntor 2009). Kontrolluar më 7 dhjetor 2011.
7. SSL_CTX_SET_OPTIONS SEEGE_RENEGOTION. Docs openssl. (25 shkurt 2010). Arkivuar nga burimi origjinal më 9 shkurt 2012. Kontrolluar 7 dhjetor 2010.
8. Gnutls 2.10.0 lëshuar. Shënimet e lëshimit të gnutls. (25 qershor 2010). Arkivuar nga burimi origjinal 9 shkurt 2012. Kontrolluar më 7 dhjetor 2011.
9. NSS 3.12.6 Shënimet e lëshimit. Shënimet e lëshimit të NSS. (3 mars 2010). Kontrolluar 24 korrik 2011.
10. I ndryshëm Dmth. SSL dobësi. Supozime të arsimuara. (10 gusht 2002).

TLS është një ndjekës SSL, një protokoll që jep një lidhje të besueshme dhe të sigurt midis nyjeve në internet. Përdoret në zhvillimin e klientëve të ndryshëm, duke përfshirë shfletuesit dhe aplikacionet e klientëve-server. Çfarë është TLS në Internet Explorer?

Pak për teknologjinë

Të gjitha ndërmarrjet dhe organizatat që janë të angazhuara në transaksionet financiare e përdorin këtë protokoll për të eliminuar pamjen e paketës dhe për të zbatuar qasje të paautorizuar nga ndërhyrës. Kjo teknologji është krijuar për të mbrojtur komponimet e rëndësishme nga sulmet e sulmuesve.

Në thelb, organizata e saj përdor një shfletues të integruar. Në disa raste - Mozilla Firefox..

Duke mundësuar dhe çaktivizuar protokollin

Disa vende ndonjëherë janë të pamundura për të dalë për shkak të faktit se mbështetja e teknologjisë SSL dhe TLS është e çaktivizuar. Në shfletuesin shfaqet njoftimi i duhur. Pra, si të mundësoni protokollet që të vazhdojnë të gëzojnë një lidhje të sigurt?
1. Mbuloni panelin e kontrollit përmes fillimit. Një tjetër mënyrë: për të hapur eksploruesin dhe klikoni në ikonën e marshit në të djathtë këndi i sipërm.

2. Shkoni në seksionin "Pronat e shfletuesit" dhe hapni bllokun "të avancuar".

3. Të përmbajë kutitë e kontrollit pranë "Përdorni TLS 1.1 dhe TLS 1.2".

4.Klikoni OK për të ruajtur ndryshimet e bëra. Nëse doni të çaktivizoni protokollet, e cila është jashtëzakonisht e rekomanduar për të bërë, veçanërisht nëse përdorni Internet Banking, hiqni shenjat nga të njëjtat sende.

Cili është ndryshimi midis 1.0 nga 1.1 dhe 1.2? 1.1 është vetëm një version pak i përmirësuar i TLS 1.0, i cili pjesërisht trashëgoi të metat e saj. 1.2 është më së shumti version i sigurt Protokoll. Nga ana tjetër, jo të gjitha vendet mund të hapen me këtë version të protokollit të përfshirë.

Siç e dini, Skype Messenger është i lidhur drejtpërdrejt me Internet Explorer si komponenti i Windows. Nëse nuk jeni shënuar nga protokolli TLS në cilësimet, problemet mund të lindin me Skype. Programi thjesht nuk do të jetë në gjendje të lidhet me serverin.

Nëse cilësimet e Internet Explorer zhduken mbështet TLS, të gjitha funksionet e programit të lidhur me rrjetin nuk do të funksionojnë. Për më tepër, ruajtja e të dhënave tuaja varet nga kjo teknologji. Mos e neglizhoni nëse kryeni operacionet financiare Në këtë shfletues (blerjet në dyqanet online, transferojnë para përmes internetit bankare ose portofolit elektronik, etj.).

TLS dhe SSL përmenden kohët e fundit gjithnjë e më shpesh, përdorimi i certifikatave digjitale bëhet më i rëndësishëm dhe madje edhe kompanitë janë të gatshme të ofrojnë certifikata digjitale për të gjithë për të siguruar që enkriptimi i trafikut është midis vendeve të vizituara dhe shfletuesit të klientit. Është e nevojshme, natyrisht, për sigurinë, në mënyrë që askush në rrjet të mos marrë të dhëna që transmetohen nga klienti në server dhe mbrapa. Si funksionon të gjithë dhe si ta përdorni? Për të kuptuar këtë, është e nevojshme, ndoshta, të filloni me teorinë, dhe pastaj të tregoni në praktikë. Pra, SSL dhe TLS.

Çfarë është SSL dhe çfarë është TLS?

SSL - Shtresa e Secure Socket, niveli i bazave të mbrojtura. TLS - Siguria e shtresës së transportit, siguria e nivelit të transportit. SSL është një sistem më i hershëm, TLS u shfaq më vonë dhe bazohet në specifikimet SSL 3.0 të zhvilluara nga komunikimet e Netscape. Megjithatë, detyra e këtyre protokolleve është një - sigurimi i transferimit të sigurt të të dhënave midis dy kompjuterëve në internet. Një program i tillë përdoret për vende të ndryshme për të email, Për të shkëmbyer mesazhe dhe shumë më tepër për atë. Në parim, ju mund të transmetoni ndonjë informacion në një mënyrë të tillë për atë pak më të ulët.

Transmetimi i sigurt është i pajisur me autentifikim dhe informacione të transmetuara nga encryption. Në thelb, këto protokolle, TLS dhe SSL punojnë në të njëjtën mënyrë, nuk ka dallime themelore. TLS, ju mund të thoni është pasardhësi SSL, edhe pse ato mund të përdoren në të njëjtën kohë, madje edhe në të njëjtin server. Një mbështetje e tillë është e nevojshme për të siguruar punë me të dy klientët e rinj (pajisje dhe shfletues) dhe me të vjetëruar, të cilat TLS nuk e mbështesin. Sekuenca e këtyre protokolleve duket kështu:

SSL 1.0 - kurrë nuk është publikuar
SSL 2.0 - Shkurt 1995
SSL 3.0 - 1996
TLS 1.0 - janar 1999
TLS 1.1 - Prill 2006
TLS 1.2 - Gusht 2008

Parimi i Operacionit SSL dhe TLS

Parimi i Operacionit SSL dhe TLS, siç thashë, e njëjta. Në krye të protokollit TCP / IP, është instaluar një kanal i koduar, brenda të cilit transmetohen të dhënat mbi protokollin e aplikimit - http, ftp, dhe kështu me radhë. Kjo është se si mund të përfaqësohet në mënyrë grafike:

Protokolli i aplikimit është "i mbështjellë" në TLS / SSL, dhe nga ana tjetër në TCP / IP. Në thelb, të dhënat mbi protokollin e aplikimit transmetohen nga TCP / IP, por ato janë të koduara. Dhe vetëm makina që vendos lidhjet mund të deshifrojnë të dhënat e transmetueshme. Për të gjithë të tjerët, të cilët do të marrin paketa të transmetuara, ky informacion do të jetë i pakuptimtë nëse nuk mund ta deshifrojnë.

Lidhja ofrohet në disa faza:

1) Klienti krijon një lidhje me serverin dhe kërkon një lidhje të sigurt. Kjo mund të ofrohet ose duke krijuar një lidhje me portin, i cili fillimisht është projektuar për të punuar me SSL / TLS, për shembull, 443 ose një kërkesë shtesë për instalimin e një lidhjeje të sigurt pas instalimit të zakonshme.

2) Kur instaloni lidhjen, klienti ofron një listë të algoritmeve të enkriptimit që ai "e di". Serveri ka shije listën që rezulton me listën e algoritmeve që serveri "e di" dhe përzgjedh algoritmin më të besueshëm, pas së cilës i tregon klientit që algoritmi të përdorë

3) Serveri dërgon certifikatën e tij digjitale tek klienti, i nënshkruar nga qendra certifikuese dhe serveri kryesor publik.

4) Klienti mund të kontaktojë serverin e një autoriteti të besueshëm të certifikimit që ka nënshkruar një certifikatë të serverit dhe kontrollon nëse certifikata e serverit është e vlefshme. Por ndoshta jo për t'u përfshirë. Sistemi operativ zakonisht ka instaluar certifikatat rrënjësore të qendrave të certifikimit me të cilat kontrollohen nënshkrimet e certifikatave të serverëve, për shembull, shfletuesit.

5) Krijuar një çelës të sesionit për një lidhje të sigurt. Kjo është bërë si më poshtë:
- Klienti gjeneron një sekuencë dixhitale të rastësishme
- Klienti e kodon atë me një çelës të hapur të serverit dhe e dërgon rezultatin në server
- Serveri dekripton sekuencën që rezulton duke përdorur një çelës të mbyllur.
Duke pasur parasysh se algoritmi i enkriptimit është asimetrik, vetëm serveri mund të dekriptojë rendin. Kur përdorni encryption asimetrike, përdoren dy çelësa - privat dhe publik. Mesazhi i dërguar publik është i koduar dhe dekoduar privatisht. Dëfshin mesazhin, duke pasur një publik, çelësi nuk mund të jetë.

6) Kjo përcakton një kompleks të koduar. Të dhënat e transmetuara sipas saj janë të koduara dhe decrypted derisa lidhja është thyer.

Certifikatë rrënjësore

Vetëm më lart, përmenda certifikatën e rrënjës. Kjo është certifikata e Qendrës së Autorizimit, nënshkrimi që konfirmon se certifikata që nënshkruhet është pikërisht ajo që i takon shërbimit përkatës. Vetë certifikata zakonisht përmban një numër fushash informacioni që përmbajnë informacion në lidhje me emrin e serverit në të cilin lëshohet certifikata dhe koha e kësaj certifikate. Nëse certifikata është e skaduar, është e pavlefshme.

Kërkesa e nënshkrimit (CSR, kërkesa për nënshkrimin e certifikatës)

Për të marrë një certifikatë të nënshkruar të serverit, duhet të gjeneroni një kërkesë të nënshkrimit (CSR, kërkesën e nënshkrimit të certifikatës) dhe ta dërgoni këtë kërkesë në qendrën e autorizimit, i cili do të kthejë certifikatën e nënshkruar të instaluar direkt në server, vetëm shikoni se si ta bëni atë në praktikë . Së pari, çelësi gjenerohet për encryption, pastaj bazuar në këtë kyç gjeneron një kërkesë nënshkrimi, një skedar CSR.

Certifikata e Klientit

Certifikata e klientit mund të gjenerohet si për përdorim në pajisje dhe të përdorin përdoruesit. Zakonisht certifikatat e tilla përdoren në verifikimin dypalësh kur klienti verifikon se serveri është me të vërtetë ai për të cilin jep vetë dhe serveri bën të njëjtën gjë në përgjigje. Ndërveprim i tillë quhet autentifikim dypalësh ose autentifikim reciprok. Autentifikimi dypalësh ju lejon të rrisni nivelin e sigurisë në krahasim me njëanshëm dhe gjithashtu mund të shërbejë si një zëvendësim i vërtetimit duke përdorur identifikimin dhe fjalëkalimin.

Zinxhiri i Veprimit të Gjenerimit të Certifikatës

Le të shohim praktikën, se si po ndodhin veprimet lidhur me gjenerimin e certifikatave që nga fillimi, dhe në të njëjtën kohë në praktikë.

Gjëja e parë që po bëhet është gjenerimi i certifikatës së rrënjës. Certifikata rrënjës është nënshkruar në vetvete. Dhe pastaj kjo certifikatë do të nënshkruajë certifikata të tjera.

$ Openssl Genrsa -ouut Root.Key 2048 Gjenerimi i çelësit privat RSA, 2048 bit Modulus Long ........... +++ .................. ... ....................................... +++ e është 65537 (0x10001 ) $ Openssl req -new -key round.key - root.CSR Ju jeni gati për t'u kërkuar për të hyrë në informacion që do të përfshihet në kërkesën tuaj të certifikatës. Çfarë jeni gati për të hyrë në një DN. Çfarë quhet DNN. Ka mjaft fusha, por ju mund të lini disa zhurmë për disa fusha do të ketë një vlerë të parazgjedhur, nëse hyni. ", Fusha do të lihet bosh. ----- Emri i vendit (kodi i letrës): RU Shteti ose emri i krahinës: N / A Emri i lokalitetit (p.sh. Qyteti): Emri i Organizatës Saint-Petersburg (p.sh. Kompania): Emri i njësisë organizative të kompanisë sime (p.sh. Seksioni ): IT Service Emri i zakonshëm): Certifikata e rrënjës së kompanisë My Adresa e emailit: It@mycompany.com Ju lutemi shkruani në vijim "Extra" atributet për t'u dërguar WIT WIT Certifikata juaj Kërkoni një Sfidë Fjalëkalimi: Një Emri i Kompanisë Opsionale: Kompania ime $ OpenSL X509 - req -days 3650 -in root.csr -signkey rrënjë.key -out rrënjë.pem nënshkrim ok \u003d / c \u003d ru / st \u003d n / a / l \u003d saint-petersburg / o \u003d kompania ime / ou \u003d IT Service / CN \u003d Certifikata ime e rrënjës së kompanisë/emailaddress\u003dit@mycompany.com Getting tastet private

Në këtë mënyrë, ne së pari krijuam çelësin privat, atëherë kërkesa e nënshkrimit, dhe pastaj çelësi ynë u nënshkrua kërkesën tonë dhe morëm certifikatën tuaj dixhitale të lëshuar për 10 vjet. Fjalëkalimi (Fjalëkalimi i Sfidës) Kur gjeneroni një certifikatë, nuk mund të hyni.

Çelësi privat duhet të mbahet në një vend të sigurt, duke pasur atë që mund të nënshkruhet në emrin tuaj çdo certifikatë. Dhe certifikata rrënjësor rezulton për të identifikuar se certifikata, për shembull, serveri është nënshkruar nga ne, dhe jo dikush tjetër. Veprime të tilla kryejnë qendrat e autorizimit kur gjenerojnë certifikatat e tyre. Pas krijimit të certifikatës rrënjë, mund të filloni të gjeneroni certifikatën e serverit.

Shikoni informacionin e certifikatës

Përmbajtja e certifikatës mund të shihet në këtë mënyrë:

$ Openssl x509 -noout-eissuer-enddate -in root.pem lëshon \u003d / c \u003d ru / st \u003d n / a / l \u003d saint-petersburg / o \u003d kompania ime / ou \u003d shërbimi IT / CN \u003d Certifikata e rrënjës së kompanisë time / Certifikata ime rrënjë e kompanisë / emailaddress\u003dit@mycompany.com nuk më pas 22 11:49:41 2025 GMT

Ne shohim se kush e ka lëshuar këtë certifikatë dhe kur përfundon jeta e saj.

Certifikata e serverit

Për të nënshkruar një certifikatë për serverin, ne duhet të kryejmë veprimet e mëposhtme:

1) të gjenerojë çelësin
2) për të gjeneruar një kërkesë nënshkrimi
3) dërgoni skedarë CSR në qendrën e autorizimit ose nënshkruani veten

Certifikata e serverit mund të përfshijë një zinxhir të certifikatave që nënshkruan një certifikatë të serverit, por gjithashtu mund të ruhet në një skedar të veçantë. Në parim, gjithçka duket si e njëjtë si kur certifikata rrënjëore të gjenerohet

$ Openssl Genrsa -Out server.Key 2048 Gjenerimi i tastit privat RSA, 2048 bit i gjatë modul ................................ ... ................................................ .. +++ ......................................... +++ E është 65537 (0x10001) $ openssl req -new -key server.key - jashtë server.CSR Ju jeni gati për t'u kërkuar për të hyrë në informacion që do të përfshihen në kërkesën tuaj të certifikatës. Çfarë jeni gati për të hyrë në një DN. Çfarë quhet DNN. Ka mjaft fusha, por ju mund të lini disa zhurmë për disa fusha do të ketë një vlerë të parazgjedhur, nëse hyni. ", Fusha do të lihet bosh. ----- Emri i vendit (kodi i letrës): RU Shteti ose emri i krahinës: N / A Emri i lokalitetit (p.sh. Qyteti): Emri i Organizatës Saint-Petersburg (p.sh. Kompania): Emri i njësisë organizative të kompanisë sime (p.sh. Seksioni ): IT Service Emri i zakonshëm (p.sh. Serveri FQDN ose emri juaj): www.mycompany.com Adresa e postës elektronike: Webmaster@mycompany.com Ju lutemi shkruani atributet e mëposhtme "shtesë" që do të dërgohen me certifikatën tuaj Kërkoni një fjalëkalim sfidues: një kompani opsionale Emri: $ openssl x509-inq-in server.csr -ca root.pem -cakey root.key-cacreateserial-out server.pem-days 365 Nënshkrimi ok subjekt \u003d / c \u003d ru / st \u003d n / a / l \u003d Shën -Petersburg / o \u003d kompania ime / ou \u003d atij shërbimi/cn\u003dwww.mycompany.com/emailaddress\u003dwebmaster@mycompany.com Getting CA Private Key $ openssl X509 -NOOUT -DSiSuer-Server .PEM Lëshuesi \u003d / C \u003d ru / st \u003d n / a / l \u003d Saint-Petersburg / O \u003d Kompania ime / OU \u003d IT Service / CN \u003d Certifikata e Rrota e Kompanisë time/emailaddress\u003dit@mycompany.com Subjekti \u003d / C \u003d ru / st \u003d N / A / L \u003d Saint-Petersburg / O \u003d Kompania ime / OU \u003d IT Service / CN \u003d www.mycompany.c om/emailaddress\u003dwebmaster@mycompany.com notafter \u003d 25 Jan 12:22:32 2016 GMT

Kështu, certifikata e serverit është nënshkruar dhe ne do të dimë se cila organizatë është lëshuar kjo certifikatë. Pas nënshkrimit, një certifikatë e gatshme mund të përdoret për destinacion, për shembull, instaloni në një server web.

Instalimi i certifikatës SSL / TLS në server me NGINX

Për të instaluar një certifikatë SSL / TLS në serverin e internetit të NGINX, ju duhet të kryeni disa hapa të thjeshtë:

1) Kopjoni skedarët.Key i.pem në server. Në të ndryshme sistemet operative Certifikatat dhe çelësat mund të ruhen në drejtori të ndryshme. Në Debian, për shembull, kjo është dosja / etc / SSL / Certs për certifikatat dhe / etj / SSL / çelësat privatë. Në centos kjo / etc / pki / tls / certs dhe etc / pki / tls / private

2) të regjistrojë cilësimet e nevojshme në skedarin e konfigurimit. Për pritësin. Ja se si duhet të duket kështu (ky është vetëm një shembull):

Server (të dëgjuar 443; server_name www.mycompany.com; rrënjë html; index.html index.htm; ssl në; ssl_certificate server.pem; ssl_certificate_key server.Key; # # # # # # # nuk është e rekomanduar për të përdorur SSLV3 !!! # është këtu vetëm për shembull SSL_PROTOCOLS SSLV3 TLSV1; SSL_CIPERS ALL :!: EXPORT56: RC4 + RSA: + Lartë: + Mesatar: + Exp; SSL_PREFER_SERVER_CIPERS ON; Vendndodhja / (TRY_FILES $ URI $ URI / \u003d 404;))

3) Restart nginx

4) Ruaj shfletuesin në portën 443 të serverit - https://www.mycompany.com dhe kontrolloni performancën e tij.

Instalimi i certifikatës SSL / TLS në serverin Apache

Instalimi i certifikatës SSL / TLS në Apache duket për të njëjtën gjë.

1) Kopjoni skedarët kryesorë dhe certifikatën në server në dosjen e duhur

2) Aktivizoni modulin SSL për Apache nga komanda A2ENMOD SSL, nëse nuk është e ndezur

3) Krijo një mikpritës virtual që do të dëgjojë portin 443. Konfigurimi do të duket diçka e tillë:

ServerAdmin webmaster@mycompany.com dokumentroot / var / www Opsionet FallowsMlinks Allowoverride Asnjë Informacionet e opsioneve të lejuara nuk lejojnë asnjë urdhër, mohoni të lejoni nga lejoni mos lejoni Scriptalias / CGI-BIN / / USR / LIB / CGI-bin / Allowoverride Asnjë Options + Execcgi -Multivime + SylinksifOwnMatch Rendit lejoni, mohoni të lejoni nga të gjithë / / Skedari që përmban një listë # të të gjitha certifikatave që nënshkruan një certifikatë server #sslcertificatechainfile /etc/apache2/ssl.crt/server-ca.crt Ssloptions + stdenvvars Ssloptions + stdenvvars Browsermatch "MSIE" \\ nokeeepalive SSL-i papastër-Shutdown \\ downgrade-1.0 Force-përgjigje-1.0 Browsermatch "MSI" SSL-Unluftdown

Në të njëjtën kohë është e nevojshme të bëjmë diçka tjetër. Gjeni në skedarin httpd.conf, ose apache2.conf, ose portet.conf, në varësi të sistemit, një komplot i tillë i konfigurimit:

Dëgjoni 443.

Nëse nuk ka gjendje të tillë, duhet të shtohet në konfigurimin. Dhe një gjë tjetër: ju duhet të shtoni një varg

Namevirtualhost *: 443

Ky varg mund të jetë në skedarin httpd.conf, apache2.conf ose portet .conf

4) Restart Apache Web Server

Duke krijuar një certifikatë të klientit

Certifikata e klientit është krijuar përafërsisht si serveri.

$ Openssl Genrsa -Out Client.Key 2048 Gjenerimi i çelësit privat RSA, 2048 bit Modulus gjatë ................................ ....................................... ........... .................................. +++ E është 65537 (0x10001) $ openssl req -new -key Client.Key - Client.CSR Ju jeni gati për t'u kërkuar për të hyrë në informacion që do të përfshihen në kërkesën tuaj të certifikatës. Çfarë jeni gati për të hyrë në një DN. Çfarë quhet DNN. Ka mjaft fusha, por ju mund të lini disa zhurmë për disa fusha do të ketë një vlerë të parazgjedhur, nëse hyni. ", Fusha do të lihet bosh. ----- Emri i vendit (kodi i letrës): RU Shteti ose emri i krahinës: Emri i lokalitetit Saint-Petersburg (p.sh. qyteti): ^ c mnorin @ mnorin-work: ~ / Temp / Certs / ca $ openssl req -new -Key client.key -Out client.CSR Ju jeni gati për t'u kërkuar për të hyrë në informacion që do të përfshihet në kërkesën tuaj të certifikatës. Çfarë jeni gati për të hyrë në një DN. Çfarë quhet DNN. Ka mjaft fusha, por ju mund të lini disa zhurmë për disa fusha do të ketë një vlerë të parazgjedhur, nëse hyni. ", Fusha do të lihet bosh. ----- Emri i vendit (kodi i letrës): RU Shteti ose emri i krahinës: N / një Emri i lokalitetit (p.sh., Qyteti): Emri i Organizatës Saint-Petrersburg (p.sh. Kompania): Emri i njësisë organizative të kompanisë sime (p.sh. Seksioni ): ENGINEERING Emri i zakonshëm (p.sh. Serveri FQDN ose emri juaj): Ivan Ivanov Adresa e emailit: Ivanov@mycompany.com Ju lutemi shkruani në vijim "ekstra" atributet që do të dërgohen me certifikatën tuaj Kërkoni një fjalëkalim të sfidës: një emër opsional i kompanisë: $ openssl X509 -req -in client.csr -ca root.pem -cakey root.key -cacreateserial -Out client.pem -demes 365 Nënshkrimi ok subjekt \u003d / c \u003d ru / st \u003d n / a / l \u003d saint -petrersburg / o \u003d Kompania ime / ou \u003d inxhinieri / cn \u003d Ivan ivanov/emailaddress\u003diivanov@mycompany.com Getting CA Private Key $ OpenSL X509 -NOOOUT -Sissuer-Cakto-Client.Pem Lëshuesi \u003d / C \u003d RU / st \u003d n / A / l \u003d Saint-Petersburg / O \u003d Kompania ime / OU \u003d IT Service / CN \u003d Certifikata e Rrota e Kompanisë time/emailaddress\u003dit@mycompany.com subjekt \u003d / c \u003d ru / st \u003d n / a / l \u003d Saint- Petrersburg / O \u003d Kompania ime / ou \u003d Inxhinieri / CN \u003d Ivan Ivanov / EmailAddress \u003d ivanov@mycompany.com notafter \u003d 25 janar 13:17:15 2016 GMT

Nëse kërkohet një certifikatë e klientit në formatin PKCS12, krijoni atë:

$ Openssl pkcs12 -Export -in client.pem -inkey client.key -cerfile root.pem - out ivanov.p12 Enter Export Password: Verifikimi - Shkruani fjalëkalimin e eksportit:

Tani mund të përdorni certifikatën e klientit për të punuar me serverin tonë.

Vendosja e NGINX për të përdorur certifikatat e klientit

Më shpesh, siç thashë, përdoret vertetimi i njëanshëm, vetëm certifikata e serverit zakonisht kontrollohet. Le të shohim se si të detyrojmë serverin e internetit të NGINX për të kontrolluar certifikatën e klientit. Ju duhet të shtoni opsione për të punuar me certifikatat e klientit në seksionin e serverit:

# Certifikata rrënjësore (s), të cilat (nënshkruan klientë ssl_client_certificate /etc/nginx/certs/lientiroot.pem; # Opsionet e mundshme: On | Off | Opsional | optional_no_ca ssl_verify_client opsional; # Certifikatat e zinxhirit të testit të thellësisë të nënshkruara nga klienti ssl_verify_depth 2;

Pas kësaj, ju duhet të rifilloni cilësimet ose serverin tërësisht dhe ju mund të kontrolloni punën.

Rregullimi i Apache për të përdorur certifikatat e klientit

Apache është konfiguruar gjithashtu përmes shtimit të opsioneve shtesë në seksionin e pritjes virtuale:

# Drejtoria që përmban certifikata rrënjësore për të kontrolluar sslcarevocationpath /etc/apache2/ssl.cl/ # ose skedar që përmbajnë certifikata sslcarevocationfile /etc/apache2/ssl.crl/ca-bundle.crl # opsioni i verifikimit të klientit. Opsionet e mundshme: # asnjë, opsional, i nevojshëm dhe opsional_no_ca sslversifyClient kërkojnë # zinxhir të hollësishëm të shikimit të nënshkrimeve. Default 1 sslverifydepth 2

Siç mund ta shihni, opsionet janë përafërsisht të njëjta si për nginx, pasi që procesi i verifikimit është i organizuar në mënyrë uniforme.

Çertifikata e informacionit të certifikatës me openssl

Për të kontrolluar ndërveprimin e serverit me certifikatat e klientit, mund të kontrolloni nëse është vendosur lidhja duke përdorur TLS / SSL.

Në anën e serverit, ne të drejtuar tela port me openssl:

Openssl s_server -accept 443-cert server.pem -key server.key -state

Në anën e klientit, ne apelojmë në server, për shembull, Culr:

Curl -k https://127.0.1:443

Në tastierë nga ana e serverit, mund të vëzhgoni procesin e shkëmbimit të informacionit midis serverit dhe klientit.

Ju gjithashtu mund të përdorni opsionin -Vrify [kontrolloni thellësinë] dhe -Verrify [kontrolloni thellësinë]. Opsioni me një letër të vogël kërkon një certifikatë nga klienti, por nuk është e detyruar ta ofrojë atë. Me një letër të madhe - nëse certifikata nuk ofrohet, do të ndodhë një gabim. Drejtoni dëgjuesin nga ana e serverit në këtë mënyrë:

Openssl s_server -accept 443 -cert server.pem -key server.Key -state -verify 3

Nga ana e serverit, gabimi duket kështu:

140203927217808: Gabim: 140890C7: Rutinat SSL: SSL3_Get_Client_Certificate: Peer nuk ka kthyer një certifikatë: S3_SRVR.C: 3287:

Nga klienti kështu:

Curl: (35) ERROR: 14094410: Rutinat SSL: SSL3_Read_bytes: SSLV3 Dështimi i shtrëngimit të duarve

Shto një certifikatë dhe emrin e domain nga ana e klientit (ju mund të kontrolloni emrin e pritësit në adresën 127.0.0.1 për të kontrolluar skedarin / etc / hosts):

Curl https://www.mycompany.com:443 --cacert root.pem - client.pem - client.Key

Tani lidhja do të përfundojë me sukses dhe mund të instaloni certifikatën e serverit në serverin e internetit, klientin për t'i dhënë klientit dhe për të punuar me ta.

Sigurinë

Kur përdorni SSL / TLS, një nga metodat kryesore është metoda MITM (njeri në mes), "njeri në mes". Kjo metodë bazohet në përdorimin e një certifikate të serverit dhe një çelës në një nyje që do të dëgjojë trafikun dhe do të dekriptojë informacionin që serveri dhe klienti të shkëmbehen. Ju mund të përdorni, për shembull, programin SSLSniff për të organizuar dëgjimin. Prandaj, certifikata rrënjë dhe çelësi zakonisht është e dëshirueshme për të ruajtur në makinë, e cila nuk është e lidhur me rrjetin, për të nënshkruar, për të sjellë kërkesa për nënshkrimin në flash drive, për të nënshkruar dhe gjithashtu kryer. Dhe, natyrisht, të bëjë kopje rezervë.

Në përgjithësi, kjo është se si përdoren certifikatat digjitale dhe protokollet TLS dhe SSL. Nëse keni pyetje / shtesa, shkruani në komentet.

Hyrja u postua nga autori nën titullin me etiketat ,.

Lundrimi në të dhënat

: 29 komente

1. cl-Service.com.

   Klienti CSR gjeneron veten kur urdhëron një certifikatë ku të shpëtojë çelësin privat gjithashtu zgjidh klientin, të lëshojë një certifikatë, ne nuk kemi nevojë për një çelës privat dhe klienti nuk e transmeton atë. Natyrisht, nëse kjo ndodh në virtual të zakonshëm, atëherë administratorët me qasje në rrënjë Serveri ka qasje në çelësat që ruhen atje.

2. Goodwire.

   Tema e boobs nuk është e shpalosur, sepse teknologjia e përshkruar e PKI-së nuk ka të bëjë fare me titullin e temës. Nëse vetëm për referencë në RFC LED.
   P.S. Kishte një shaka të tillë për qenin dhe pleshtin.

3. Goodwire.

   Rasti nuk donte t'ju ofendonte. Unë isha duke kërkuar për informacion në lidhje me dallimin midis SSL dhe TLS në praktikë dhe lidhja juaj në Google ishte e para. Ajo u xhekua nga titulli i temës. Të gjitha të ftohtë, e mbajnë atë!

4. Draibolit.

   Faleminderit për shpjegime të ndjeshme rreth certifikimit digjital. Unë jam i ri për këtë \u003d)
   Unë shpresoj që të shpjegoj pyetjen tjetër.
   Meqë fushëveprimi i mashtrimit është shumë i zhvilluar në industrinë e internetit, unë do të doja të mësoja se si të përcaktoj vendet në faqen tënde (sidomos ku janë të pranishëm kollitet dhe pagesa, investimet etj) dhe përcaktojnë në bazë të kësaj shkalle të Besimi im (shpesh është i regjistruar, për të lënë informacionin personal, pazaret, transaksionet, investimet). Nëse e kuptova saktësisht se prania e këtij certifikimi ju lejon të bëni një vlerësim të tillë. Epo, nga ana tjetër, të marrë atë nuk është një problem dhe madje edhe për të lira.
   Si ose me cilin program ju mund të përcaktoni praninë e një certifikate dixhitale në një vend të caktuar? Dhe është e dëshirueshme kategoria e tij, e cila është caktuar kur lëshon specialist SSL DV (lëshimi i një certifikate është kryer me një kontroll të vetëm një domen), SSL OV (me verifikimin e një organizate), EV (me një auditim të zgjeruar të Jurlitzit) . Faqet mashtruese ka shumë të ngjarë, versioni më i fundit i certifikimit nuk do të përdorë ..
   Unë do të jem i lumtur nëse ende keni ndonjë mënyrë për të përcaktuar besueshmërinë e vendeve))

   1. mnorin. Autori i regjistrimit

      Unë nuk kam takuar ende një program specifik për këto qëllime, por unë mund të jap disa këshilla për këtë rast.
      Ju mund të përdorni, për shembull, krom ose Google Chrome.. Merrni, për shembull, faqen https://www.thawte.com/ - një kompani që në të vërtetë merret me digjitalët.
      Kompania dhe bllokimi i gjelbër do të shkruhen në shiritin e adresës. Kjo do të thotë se organizata është verifikuar, është së paku SSL OV.
      Nëse klikoni mbi bllokimin, dhe në dritaren e dremitjes "Detajet" dhe pastaj "View Certifikata", atëherë ju mund të shihni informacionin e certifikatës. Për Thawte, certifikata është nënshkruar me certifikatën e mëposhtme: "Thawte zgjeruar Validation SHA256 SSL CA", dhe certifikatën për klikim.Alfabank.ru gjithashtu nënshkruan Thawte, por një certifikatë tjetër. Kjo është "Thawte ev SSL CA - G3", domethënë, ata gjithashtu kaluan validim të zgjeruar.
      Diçka si kjo.

5. Ruslan

   Seksioni "Parimi i Operacionit SSL dhe TLS", "Klienti gjeneron një sekuencë të rastësishme digjitale".

   Unë kam qenë i sigurt se klienti gjeneron seancën e mbyllur dhe, në përputhje me rrethanat, çelësat e hapur (të cilat ju jeni quajtur qartë "sekuenca digjitale"). Çelësi publik transmetohet në server dhe serveri encryps paketat drejt sesionit të klientit të hapur Klienti Klienti.

   Ju lutem qartesoni.

6. Newbie

   Artikulli është shumë i dobishëm! Madje edhe atje shembuj praktikë\u003d) Vetëm unë nuk e kuptoja një gjë - cili është dallimi në mes të certifikatës së rrënjës dhe serverit? Apo është e njëjtë?

7. Vitaly

   Përshëndetje.
   Hoster sugjeroi një shërbim - SSL për serverat virtuale. Ne përdorëm. Doli se për nivelin e tretë, I.E. http://www.site.ru Certifikata është e pavlefshme, vetëm për site.ru. Për më tepër, vizitorët hedhin plotësisht protokollin HTTPS, nuk ka rëndësi nëse ata vijnë në vend.ru ose në http://www.site.ru. Natyrisht, në rastin e dytë, shfletuesi fillon të betohet në mënyrë të qëndrueshme, dhe vizitori në vend nuk merr.
   Dhe për ata që kanë arritur në këtë faqe, faqja filloi të dukej e zymtë, e zhdukur pjesë e menysë, pjesa e fotografive në lëshimin e disa komponentëve të ndaluara.

Protokolli TLS encrypts të gjitha llojet e trafikut të internetit, duke bërë kështu komunikim të sigurt dhe shitje në internet. Ne do të tregojmë se si punon protokolli dhe çfarë na pret në të ardhmen.

Nga artikulli do të mësoni:

Çfarë është SSL

SSL ose shtresa e bazave të mbrojtura ishte emri i protokollit origjinal, i cili u zhvillua nga Netscape në mesin e viteve '90. SSL 1.0 nuk ka qenë kurrë i përballueshëm publikisht, dhe në versionin 2.0 ka pasur mangësi serioze. Protokolli SSL 3.0, i lëshuar në vitin 1996, u redone plotësisht dhe kërkoi tonin e fazës së ardhshme të zhvillimit.

Çfarë është TLS.

Kur versioni i ardhshëm i protokollit u lirua në vitin 1999, ajo ka standardizuar një dizajn të posaçëm të grupeve të internetit të internetit dhe i dha një emër të ri: mbrojtja e nivelit të transportit, ose TLS. Siç thuhet në dokumentacionin TLS, "dallimi në mes të këtij protokolli dhe SSL 3.0 nuk është kritik". TLS dhe SSL formojnë një seri të përditësuar vazhdimisht të protokolleve, dhe ato shpesh kombinohen të quajtur SSL / TLS.

Protokolli TLS kodon trafikun e internetit të çdo lloji. Lloji më i zakonshëm është trafiku i internetit. Ju e dini kur shfletuesi juaj krijon një lidhje TLS - nëse lidhja në shiritin e adresës fillon me "https".

TLS përdoret gjithashtu nga aplikacione të tjera - për shembull, në sistemet e postës dhe telekonferencës.

Si punon TLS

Encryption është e nevojshme për të komunikuar në mënyrë të sigurtë në internet. Nëse të dhënat tuaja nuk janë të koduara, çdokush mund t'i analizojë ato dhe të lexojë informacionin konfidencial.

Metoda më e sigurt e enkriptimit është por encryption simetrik . Kjo kërkon 2 çelësa, 1 publik dhe 1 privat. Këto janë skedarë me informacione, numra më të mëdhenj shumë të mëdhenj. Mekanizmi është kompleks, por nëse thjesht përdorni çelësin publik për të koduar të dhënat, por keni nevojë për një çelës privat për t'i deshifruar ato. Dy çelësa janë të lidhur me një formulë komplekse matematikore, e cila është e vështirë për të hack.

Ju mund të dorëzoni një çelës publik si informacion në lidhje me vendndodhjen e të mbyllura kuti postare Me një vrimë, dhe çelësin privat si çelësi që hap kutinë. Kushdo që e di se ku është kutia, mund të vendosë një letër atje. Por për ta lexuar atë, një person ka nevojë për një çelës për të hapur kutinë.

Meqenëse llogaritjet komplekse matematikore përdoren në encryption asimetrike, ka shumë burime kompjuterike. TLS zgjidh këtë problem duke përdorur encryption asimetrike vetëm në fillim të seancës për të koduar komunikimin midis serverit dhe klientit. Serveri dhe klienti duhet të bien dakord për një çelës të vetëm të seancës, të cilën ata do të përdoren për të përdorur për të encrypt të paketave të të dhënave.

Procesi sipas të cilit klienti dhe serveri bien dakord mbi çelësin e seancës quhet dore. Ky është momenti kur 2 kompjuterë komunikues i paraqiten një miku.

Tls-handshake

Procesi i TLS-handshake është mjaft i komplikuar. Hapat e mëposhtëm pasqyrojnë procesin në përgjithësi në mënyrë që të kuptoni se si funksionon në përgjithësi.

1. Klienti është i lidhur me serverin dhe kërkon një lidhje të sigurt. Serveri përgjigjet me një listë të shifrave - një grup algorithmik për të krijuar lidhje të koduara - të cilat ai e di se si të përdorë. Klienti e krahason listën me listën e tij të shifrave të mbështetura, zgjedh një të drejtë dhe i jep serverit të dijë se do të përdorin së bashku.
2. Serveri ofron certifikatën e saj digjitale - një dokument elektronik i nënshkruar nga një palë e tretë, e cila konfirmon vërtetësinë e serverit. Sami informacion i rendesishem Çertifikata është një çelës publik për shifrën. Klienti konfirmon vërtetësinë e certifikatës.
3. Duke përdorur çelësin publik të serverit, klienti dhe serveri përcaktojnë çelësin e sesionit që të dy do të përdoren gjatë gjithë sesionit për të encrypt komunikimin. Ka disa metoda për këtë. Klienti mund të përdorë një çelës publik për të encrypt një numër arbitrar, i cili pastaj dërgohet në server për të decrypt, dhe të dyja palët pastaj e përdorin këtë numër për të vendosur çelësin e sesionit.

Çelësi i sesionit është i vlefshëm vetëm gjatë një sesioni të vazhdueshëm. Nëse për ndonjë arsye komunikimi midis klientit dhe serverit do të ndërpresë, do t'ju duhet një shtrëngim duarsh të reja për të vendosur një çelës të ri të sesionit.

TLS 1.2 dhe TLS 1.2 Vulnerabilities Protokolli

TLS 1.2 është versioni më i zakonshëm i protokollit. Ky version ka instaluar një platformë fillestare të opsioneve të enkriptimit të sesionit. Megjithatë, si disa versione të mëparshme të protokollit, ky protokoll lejohet të përdorë teknikat e mëvonshme të enkriptimit për të mbështetur kompjuterët e vjetër. Për fat të keq, kjo çoi në dobësitë e versionit 1.2, pasi që këto mekanizma më të vjetër të enkriptimit janë bërë më të prekshme.

Për shembull, protokolli TLS 1.2 është bërë veçanërisht i prekshëm ndaj sulmeve të tilla si ndërhyrja aktive në lidhje me lidhjen në të cilën hakeri përgjon paketat e të dhënave në mes të seancës dhe i dërgon ato pas leximit ose ndryshimit të tyre. Shumë nga këto probleme manifestohen gjatë 2 viteve të fundit, prandaj u bë e domosdoshme për të krijuar urgjentisht një version të përditësuar të protokollit.

TLS 1.3.

Versioni 1.3 i protokollit TLS, i cili së shpejti do të finalizohet, zgjidh shumë probleme me dobësitë sepse refuzon të mbështesë sistemet e encryption të vjetëruara.
Versioni i ri ka pajtueshmëri me versionet e mëparshme: Për shembull, lidhja rrotullohet në versionin TLS 1.2, nëse njëra prej palëve nuk mund të përdorë më shumë sistemi i ri Encryption në listën e algoritme të lejuara të protokollit version 1.3. Megjithatë, kur sulmon llojin e ndërhyrjes aktive në lidhje, nëse hakerët do të përpiqen me forcë versionin e protokollit në 1.2 në mes të seancës, ky veprim do të vërehet dhe lidhja do të ndërpritet.

Si të mundësoni mbështetje për TLS 1.3 në shfletuesit e Google Chrome dhe Firefox

Firefox dhe Chrome mbështesin TLS 1.3, por ky version nuk është i aktivizuar nga default. Arsyeja është se ajo ekziston deri më tani vetëm në draft versionin.

Mozilla Firefox.

Shkruani për: Konfiguroni në shiritin e adresës së shfletuesit. Konfirmoni që jeni në dijeni të rreziqeve.

1. Hapet redaktori i Settings Settings Firefox.
2. Shkruani kërkimin në Security.TLS.Version.max
3. Ndryshoni vlerën në 4 duke bërë një klikim të dyfishtë mbi vlerën aktuale.

Google Chrome.

1. Shkruani Chrome: // Flamujt / në shiritin e shfletuesit për të hapur panelin e eksperimenteve.
2. Gjeni opsionin # tls13-variant
3. Klikoni në menunë dhe vendosni të aktivizoni (draft).
4. Rinisni shfletuesin.

Si të verifikoni që shfletuesi juaj përdor versionin 1.2

Ne ju kujtojmë se versioni 1.3 nuk është përdorur ende publikisht. Nëse nuk dëshironi
Përdorni draft variantin, ju mund të qëndroni në versionin 1.2.

Për të verifikuar që shfletuesi juaj përdor versionin 1.2, bëni të njëjtat hapa si në udhëzimet e mësipërme dhe sigurohuni:

• Për Firefox, vlera e sigurisë.tls.version.max është 3. nëse është më poshtë, ndryshoni atë në 3 duke bërë një klikim të dyfishtë mbi vlerën aktuale.
• Për Google Chrome: Klikoni në menunë e shfletuesit - zgjidhni Parametrat - zgjidhni Tregojnë cilësime të avancuara. - zbrisni në seksionin Sistem. Dhe klikoni mbi Cilësimet e hapura proxy ...:

• Në dritaren që hapet, klikoni mbi skedën e sigurisë dhe kontrolloni se objekti i përdorimit TLS 1.2 qëndronte një shenjë kontrolli. Nëse nuk duhet të vendosni dhe klikoni OK:

Ndryshimet do të hyjnë në fuqi pasi të rifilloni kompjuterin.

Mjet i shpejtë për të kontrolluar versionin e protokollit të shfletuesit SSL / TLS

Shkoni në versionin online të versionit të protokollit të laboratorëve SSL. Faqja do të tregojë në kohë reale versionin e përdorur nga versioni i protokollit dhe nëse shfletuesi është subjekt i disa dobësive.

Burime: Përkthim

Protokolli SSL TLS siguron mbrojtjen e lidhjeve të internetit në http (për faqet e internetit), FTP ( skedari), IMAP, POP3 dhe SMTP (protokollet postare).

Në vitin 2014, një dobësi u zbulua në punën e SSL, përveç kësaj, ai filloi të shtrihej, prandaj, bazuar në SSL 3.0, standardi TLS krijuar.

Tls. (Siguria e shtresës së transportit në anglisht) është një protokoll kriptografik që siguron transferimin e të dhënave të mbrojtur nga serveri tek klienti. Në zemër të TLS, encryption simetrike për konfidencialitetin, kriptografinë asimetrike për autentifikim, kodet e autenticitetit për të ruajtur integritetin e informacionit të transmetueshëm. Ai merr parasysh gabimet e paraardhësit të tij dhe vazhdon zhvillimin.

Në thelb, dallimet në parimet e SSL dhe TLS janë minimale, kështu që kur flasin për SSL, kuptohet nga TLS.

Parimi i punës tls.

Procesi i TLS mund të ndahet në disa faza:

• Shtrëngim duarsh tls
• TLS FALSE START.
• TLS zinxhir i besimit

Shtrëngim duarsh tls - Koordinon parametrat e lidhjes midis klientit dhe serverit (metodën e encryption, versionin e protokollit), dhe gjithashtu kontrollon certifikatat. Kjo procedurë përdor një numër të madh të burimeve kompjuterike, në mënyrë që çdo herë që nuk mund të instaloni një lidhje të re dhe të mos kontrolloni certifikatat e ri-zhvilluar Procedura e Farm Start TLS.

TLS FALSE START. - Procedura për rifillimin e seancës. Nëse sesioni midis klientit dhe serverit u hap më parë, kjo fazë ju lejon të kaloni procedurën e shtrëngimit të duarve duke përdorur të dhënat që është konfiguruar më herët. Megjithatë, për arsye sigurie, çdo sesion ka jetën e vet dhe, nëse ka skaduar, do të rihapet duke përdorur procedurën e shtrëngimit të duarve TLS.

TLS zinxhir i besimit - Procedura e detyrueshme e kompleksit TLS. Ai siguron autentikim midis klientit dhe serverit. Është ndërtuar në një "zinxhir të besimit", i cili bazohet në certifikatat e legalizimit të lëshuara nga qendrat e certifikimit. Autoriteti i certifikimit kontrollon vërtetësinë e certifikatës dhe, nëse është e komprometuar, të dhënat përgjigjen. Falë kësaj procedure, ndodh autentifikimi i të dhënave të transmetuara.

Kështu, kur transmeton të dhënat e shtrëngimit të dorës TLS ose TLS të rreme Start TLS është thirrur së pari, i cili koordinon parametrat, dhe pastaj zinxhirin e besimit të TLS, i cili siguron autentifikim (duke kontrolluar autorësinë e informacionit të transmetuar).

Më shumë detaje me parimet e punës së TLS, ju mund të gjeni në dokumentacionin zyrtar të DataTracker.

Cilësimet e sigurisë së protokollit TLS

• Versioni TLS nuk mund të reduktohet në versionin e mëparshëm (më pak të mbrojtur), kalimi në një algoritëm të pabesueshëm të kodimit është gjithashtu e pamundur.
• Regjistrimet e aplikimit vijues numërohen, dhe numri i sekuencës përdoret në kodin e autentifikimit të mesazhit.
• Vetëm pronari i çelësit mund të gjenerojë kodin e autentifikimit të mesazhit.
• Mesazhi që plotëson konfirmimin e lidhjes përdoret për të konfirmuar vërtetësinë e mesazheve të transmetuara më herët.

Instalimi i SSL / TLS

Në kompaninë ju mund të zgjidhni dhe të blini, e cila punon në TLS 1.2:

Pas lëshimit të certifikatës, instaloni vetë. sipas një prej udhëzimeve.