Ano ang TLS at paano ito gumagana?

Ang Transport Layer Security (TLS) ay isa sa pinakamahalaga at malawakang ginagamit na protocol ng seguridad. Pinoprotektahan nito ang isang makabuluhang proporsyon ng data na nakukuha sa online. Ito ay pinakaprominente ginamit upang ma-secure ang data na naglalakbay sa pagitan ng isang web browser at website sa pamamagitan ng HTTPS, ngunit maaari din itong magamit upang ma-secure ang email at isang host ng iba pang mga protocol.

Mahalaga ang TLS dahil tinitiyak nito ang ibang partido sa isang koneksyon ay ang sinasabi nila na sila ay, ipinapakita kung ang data ay nagpapanatili ng paunang integridad, at nagbibigay ng kumpidensyal sa pamamagitan ng pag-encrypt.

Ang TLS ay gumagamit ng isang iba’t ibang mga iba’t ibang mga algorithm at scheme upang makamit ang mga layuning ito. Maaari itong maging kumplikado, ngunit ang artikulong ito ay masakop ang isang aspeto sa isang oras upang mabigyan ka ng isang malalim na pagtingin sa kung paano gumagana ang TLS upang ma-secure ang mga koneksyon.

Ano ang ginagawa ng TLS?

Kapag nagpapadala ng impormasyon sa online, tumatakbo kami sa tatlong pangunahing problema sa seguridad:

• Paano natin malalaman kung ang taong ating nakikipag-usap ay tunay na sinasabi nila na sila?
• Paano natin malalaman na ang data ay hindi na-tampo mula noong ipinadala nila ito?
• Paano natin maiiwasan ang ibang mga tao na makita at ma-access ang data?

Ang mga isyung ito ay mahalaga, lalo na kung nagpapadala kami ng sensitibo o mahalagang impormasyon. Ang TLS ay gumagamit ng isang hanay ng mga diskarteng kriptograpiko upang matugunan ang bawat isa sa tatlong mga problema. Sama-sama, pinapayagan nila ang protocol patunayan ang ibang partido sa isang koneksyon, suriin ang integridad ng data at magbigay ng naka-encrypt na proteksyon.

Gawing pasimplehin ang mga bagay at magpanggap na sinusubukan mong ibalik-balik ang impormasyon sa isang kaibigan na nakatira sa buong bansa. Kung ang impormasyon ay sensitibo, mag-aalala ka tungkol sa tatlong pangunahing mga problema na nabanggit sa itaas.

Hindi ka lamang maaaring magpadala ng isang sulat at umaasa para sa pinakamahusay, lalo na kung pinaghihinalaan mo na ang iyong mga komunikasyon ay na-target ng mga umaatake. Sa halip, kailangan mo ng isang system na nagbibigay-daan sa iyo upang mapatunayan na ang iyong tatanggap ay lehitimo, isang paraan na maaari mong suriin kung binago ang mga mensahe, at isang paraan upang maprotektahan ang mga ito mula sa mga mata ng prying..

Tinutupad ng TLS ang mga kinakailangang ito gamit ang isang iba’t ibang mga proseso. Nagsisimula ito sa kung ano ang kilala bilang isang Paghawak ng kamay ng TLS, kung saan naganap ang pagpapatunay at itinatag ang mga susi.

Upang bumalik sa aming pagkakatulad ng liham, ang bahagi ng pagpapatunay ng TLS ay magiging uri tulad ng pagpapadala ng isang sulat sa pamamagitan ng isang courier na nangangailangan ng pagkakakilanlan. Kapag naghahatid ng sulat ang courier, ihahambing nila ang ID ng tao sa kanilang mukha at mapatunayan kung ang tatanggap ba o tamang tao.

Ang pangunahing yugto ng pagtatatag ay magiging kaunti kung ang iyong sulat ay naglalaman ng kalahati ng isang numero ng pin na inilaan mong gamitin sa mga komunikasyon sa hinaharap. Hilingin mo sa iyong tatanggap na makabuo ng ikalawang kalahati ng numero at ipadala ito sa iyo sa kanilang sulat.

Kapag napatunayan ng courier ang pagkakakilanlan at ang numero ng pin ay naitatag, magkakaroon ka ng lahat ng kailangan mo upang ligtas na magpadala ng impormasyon. Sa katotohanan, ang mga yugtong ito ay mas kumplikado, ngunit makakarating tayo sa paglaon.

Ligtas na ipinagpapalit ng TLS ang impormasyon sa protocol ng aplikasyon. Upang maisakatuparan ang aming pagkakatulad, ligtas na pagpapadala ng data sa TLS ay magiging tulad ng pagsulat ng isang mensahe at paglalagay nito sa isang sobre. Isusulat mo ang iyong lagda sa buong selyo, upang kung ang sulat ay na-tampered, ang iyong tatanggap ay maaaring sabihin sa pamamagitan ng napunit na pirma (ito ay talagang ginagawa sa matematika, ngunit muli, tatakpan namin ito nang malalim).

Pagkatapos ay ilalagay mo ang liham sa isang maliit na kahon ng metal na may isang lock ng kumbinasyon, na itinatakda ang kumbinasyon bilang numero ng pin na pinagsama-sama mo sa iyong tatanggap. Ipadala mo ang kahon sa pamamagitan ng courier na sinusuri ang pagkilala kapag inihatid ang mga pakete. Ang iyong tatanggap ay tumugon sa parehong paraan, at anumang mga komunikasyon sa hinaharap ay susundin ang parehong mga hakbang.

Malulutas ng TLS ang lahat ng tatlo sa aming mga problema sa medyo katulad na paraan. Naghahain ang courier upang mapatunayan ang tatanggap at siguraduhin na ang kahon ay naihatid sa nilalayon nitong tao. Ang naka-lock na kahon ay nagsisilbing isang form ng pag-encrypt, na pumipigil sa sinuman ngunit ang iyong kapareha sa pag-access sa mga titik. Ang naka-sign na sobre ay nagpapahintulot sa iyo na malaman kung hindi ang mensahe ay na-tampuhan.

Ito ay isang napaka-magaspang na pagtatantya ng ginagawa ng TLS. Sa totoo, Nagaganap ang TLS sa pagitan ng mga kliyente at server, kaysa sa dalawang tao na nagpapadala ng mail sa bawat isa. Ang pagkakatulad ay magbibigay sa iyo ng isang paggunita sa kung ano ang nangyayari at ang pangangatuwiran sa likod nito. Sa mga sumusunod na seksyon, tatalakayin namin kung ano ang aktwal na nangyayari.

TLS kumpara sa SSL

Kapag nagbabasa tungkol sa TLS, madalas mong makita ang pagbanggit ng SSL o kahit na TLS / SSL. Ang Secure Sockets Layer (SSL) ay ang lumang bersyon ng TLS, ngunit marami sa industriya ang tumutukoy pa rin sa TLS sa ilalim ng lumang moniker. Gagamitin ng artikulong ito ang salitang TLS sa buong, ngunit mahalagang tandaan na ang mga pangalan ay madalas na ginagamit nang magkakapalit. Maaari mong basahin ang higit pa tungkol sa SSL sa aming gabay.

Ang kasaysayan ng TLS

Nagsimula ang lahat sa pag-secure ng layer ng transportasyon. Tulad ng nabanggit namin sa itaas, ang nauna sa TLS ay SSL. Ang mga unang bersyon ng SSL ay binuo sa mga nineties ng Netscape, isang kumpanya na nagtayo ng isa sa mga unang web browser.

Ang SSL 1.0 ay hindi pinakawalan sapagkat naglalaman ito ng mga seryosong kahinaan. Ang Bersyon 2.0 ay lumabas kasama ang Netscape Navigator 1.1 noong 1995, gayunpaman naglalaman pa rin ito ng isang bilang ng mga malubhang bahid. Ang SSL 3.0 ay isang mabibigat na bersyon na muling idisenyo at lumabas noong 1996, na nalutas ang marami sa mga isyu sa seguridad.

Noong 1996, pinakawalan ng IETF ang isang draft ng SSL 3.0 sa RFC 6101. Ang IETF ay nabuo ng isang nagtatrabaho na grupo upang gawing standard ang SSL, na inilalathala ang mga resulta noong 1999 bilang TLS 1.0. Ito ay naitala sa RFC 2246 at ang standardisasyon ay kasama ang ilang mga pagbabago sa orihinal na protocol, pati na rin ang pagbabago ng pangalan. Ang mga pagbabagong ito ay naganap bilang isang resulta ng mga negosasyon sa pagitan ng Netscape, Microsoft at pangkat ng nagtatrabaho IETF.

Noong 2006, pinakawalan ng IETF ang RFC 4346, na nagtataguyod ng TLS 1.1. Ang bersyon na ito ay naglalaman ng mga bagong probisyon sa seguridad at isang bilang ng iba pang mga pag-update. Ang Bersyon 1.2 ay pinakawalan makalipas lamang ng dalawang taon sa 2008. Kasama nito ang suporta para sa mga na-verify na ciphers na naka-encrypt, isang bilang ng mga pagbabago sa kung paano ginagamit ang mga function ng hash at maraming iba pang mga pagpapabuti.

Ang susunod na bersyon ay hindi dumating hanggang sa 2023, nang tinukoy ang TLS 1.3. Nagtatampok ito ng isang host ng mga pagbabago, kabilang ang ipinatupad na pasulong na lihim, pag-alis ng suporta para sa mas mahina na mga algorithm at marami pa.

Ang TLS 1.0 at 1.1 ay nakatakda na ngayong maiurong sa 2023, ngunit ang bersyon 1.2 ay malawakang ginagamit. Ang Bersyon 1.3 ay nagsisimula upang makita ang pagtaas ng pag-ampon.

TLS: Ang mga teknikal na detalye

Ang TLS ay binubuo ng maraming iba’t ibang mga elemento. Ang pangunahing bahagi ay ang record protocol, ang pinagbabatayan na protocol na responsable sa overarching na istraktura ng lahat ng iba pa.

Diagram na nagpapakita ng TLS stack. TLS protocol stack ni Jeffreytedjosukmono. May lisensya sa ilalim ng CC0.

Ang record protocol ay naglalaman ng limang magkakahiwalay na subprotocols, na ang bawat isa ay na-format na talaan:

• Handshake – Ang protocol na ito ay ginagamit upang i-set up ang mga parameter para sa isang ligtas na koneksyon.
• Application – Ang protocol ng aplikasyon ay nagsisimula pagkatapos ng proseso ng handshake, at ito ay kung saan ang data ay ligtas na nailipat sa pagitan ng dalawang partido.
• Alerto – Ang alerto protocol ay ginagamit ng alinman sa partido sa isang koneksyon upang ipaalam sa iba pang kung mayroong anumang mga pagkakamali, mga isyu sa katatagan o isang potensyal na kompromiso.
• Baguhin ang Cipher Spec – Ang protocol na ito ay ginagamit ng alinman sa client o server upang baguhin ang mga parameter ng pag-encrypt. Medyo diretso ito, kaya hindi namin ito masaklaw nang malalim sa artikulong ito.
• Tibok ng puso – Ito ay isang extension ng TLS na nagbibigay-daan sa isang panig ng koneksyon kung buhay pa rin ang kanyang kapantay, at pinipigilan ang mga firewall na isara ang mga hindi aktibong koneksyon. Hindi ito pangunahing bahagi ng TLS, kaya’t laktawan namin ito sa gabay na ito.

Ang bawat isa sa mga subprotocol na ito ay ginagamit sa iba’t ibang yugto upang makipag-usap ng iba’t ibang impormasyon. Ang pinakamahalagang maiintindihan ay ang pagkakamay at ang mga protocol ng aplikasyon, sapagkat ang mga ito ay may pananagutan sa pagtaguyod ng koneksyon at ligtas na pagpapadala ng data.

Ang protocol ng handshake ng TLS

Ito ay kung saan ang koneksyon ay itinatag sa isang ligtas na paraan. Maaaring maging kumplikado kung bago ka sa ilan sa mga konsepto, ngunit ang bawat isa sa mga ito ay nasaklaw sa susunod na artikulo kung kailangan mong sumangguni sa kanila.

Mayroong tatlong pangunahing uri ng TLS handshake: ang pangunahing handshake ng TLS, ang handshake na na-verify ng client at ang pinaikling kamay.

Ang pangunahing handshake ng TLS

Diagram na nagpapakita ng proseso ng handshake ng TLS. Buong TLS 1.2 Handshake ni FleshGrinder. May lisensya sa ilalim ng CC0.

Sa ganitong uri ng handshake, tanging ang server ay napatunayan at hindi ang kliyente. Nagsisimula ito sa phase ng negosasyon, kung saan nagpapadala ang isang kliyente ng Kamusta sa Kamusta mensahe. Naglalaman ito ng pinakamataas na bersyon ng TLS na sinusuportahan ng kliyente, posibleng mga cipher suite, isang indikasyon kung sinusuportahan nito ang compression, isang random na numero at ilang iba pang impormasyon

Ang mensahe ng kliyente ng kliyente ay nakilala sa isang Kumusta ang server mensahe. Ang tugon na ito ay naglalaman ng session ID, bersyon ng protocol, cipher suite at compression (kung mayroong ginagamit) na pinili ng server mula sa listahan ng kliyente. Kasama rin dito ang isang iba’t ibang mga random na numero.

Ito ay nakasalalay sa cipher suite na napili, ngunit sa pangkalahatan ay susundin ito ng server sa pamamagitan ng pagpapadala ng Sertipiko mensahe para sa pagpapatunay. Pinatunayan nito ang pagkakakilanlan nito at naglalaman ng susi ng publiko.

Kung ang ephemeral diffie-Hellman o ang hindi nagpapakilalang pagpapalitan ng susi sa pagsasabong ay ginagamit, pagkatapos ito ay sinusundan ng isang Exchange Key Exchange mensahe. Ang iba pang mga pangunahing paraan ng palitan ay lumaktaw sa bahaging ito. Kapag natapos na ang server kasama ang panig ng negosasyon, nagpapadala ito ng Kumusta ang server Kumusta mensahe.

Ngayon ay muli ang client. Depende sa napiling cipher suite, magpapadala ito ng Client Key Exchange mensahe. Maaari itong maglaman ng isang pampublikong susi o isang lihim ng pasilyo, na naka-encrypt gamit ang pampublikong susi ng server.

Ang parehong mga partido pagkatapos ay gamitin ang mga random na numero at ang lihim ng pasilyo upang makabuo ng isang master secret. Ang mga susi ay nagmula sa master secret, na kung saan ay ginamit upang mapatunayan at i-encrypt ang mga komunikasyon.

Nagpapadala ang kliyente a Baguhin ang Cipher Spec mensahe. Sinasabi nito sa server na ang mga sumusunod na mensahe ay ngayon ay mapatunayan at mai-encrypt (kahit na kung minsan ay hindi maaaring gamitin ang pag-encrypt).

Ang kliyente pagkatapos ay sumusunod ito sa isang Tapos na mensahe, na naka-encrypt at naglalaman din ng isang Message Authentication Code (MAC) para sa pagpapatunay. Ang server ay decrypts ang mensaheng ito at nagpapatunay sa MAC. Kung nabigo ang anumang mga prosesong ito, dapat tanggihan ang koneksyon.

Ngayon ay sulit ng server na magpadala ng Baguhin ang Cipher Spec mensahe, pati na rin a Tapos na mensahe na may parehong nilalaman tulad ng nasa itaas. Sinusubukan din ng kliyente na i-decrypt at i-verify ang mga nilalaman. Kung matagumpay itong nakumpleto, ang handshake ay tapos na. Sa puntong ito, ang protocol ng aplikasyon ay itinatag. Ang data ay maaaring palitan ng ligtas sa parehong paraan tulad ng Tapos na mensahe mula sa itaas, na may pagpapatunay at opsyonal na pag-encrypt.

Ang handshake na pinagtibay ng Client

Ang handshake na ito ay katulad ng pangunahing handshake ng TLS, ngunit ang client ay napatunayan din. Ang pangunahing pagkakaiba ay pagkatapos ng pagpapadala ng server nito Sertipiko mensahe, nagpapadala rin ito ng Humiling ng Sertipiko mensahe, humihingi ng sertipiko ng kliyente. Kapag natapos na ang server, ipinapadala ng kliyente ang sertipiko nito sa isang Sertipiko mensahe.

Pagkatapos ay ipinapadala ng kliyente Client Key Exchange mensahe, tulad ng sa pangunahing handshake ng TLS. Sinusundan ito ng Patunayan ang Sertipiko mensahe, na kasama ang digital na pirma ng kliyente. Dahil kinakalkula ito mula sa pribadong susi ng kliyente, maaaring mapatunayan ng server ang pirma gamit ang pampublikong susi na ipinadala bilang bahagi ng digital certificate ng kliyente. Ang natitirang bahagi ng Ang handshake na pinagtibay ng Client sumusunod sa parehong mga linya tulad ng pangunahing pagkakamay ng TLS.

Nai -ikli ang handshake ng TLS

Kapag naganap na ang isang handhake, pinapayagan ng TLS ang karamihan sa proseso na gupitin sa pamamagitan ng paggamit ng isang pinaikling handshake sa halip. Ginagamit ng mga handshakes na ito ang session ID upang mai-link ang bagong koneksyon sa mga nakaraang mga parameter.

Ang isang pinaikling kamay ay nagbibigay-daan sa kapwa partido na ipagpatuloy ang ligtas na koneksyon sa parehong pag-setup na napagkasunduan nang mas maaga. Dahil ang ilan sa mga kriptograpiya na normal na kasangkot sa pagpapasimula ng isang pagkakamay ay maaaring maging mabigat sa mga mapagkukunan ng computational, nakakatipid ito ng oras at ginagawang mas madali ang koneksyon..

Ang proseso ay nagsisimula sa Kamusta sa Kamusta mensahe. Ito ay katulad ng naunang mensahe ng Client Hello, ngunit naglalaman din ito ng session ID mula sa naunang koneksyon. Kung alam ng server ang session ID, kasama nito ito Kumusta ang server mensahe. Kung hindi nito kinikilala ang session ID, babalik ito ng ibang numero, at ang isang buong pagkakamay ng TLS ay magaganap sa halip.

Kung kinikilala ng server ang session ID, pagkatapos ang Sertipiko at Key Exchange ang mga hakbang ay maaaring laktawan. Ang Baguhin ang Cipher Spec at Tapos na ipinapadala ang mga mensahe sa parehong paraan tulad ng pangunahing handshake ng TLS na ipinakita sa itaas. Sa sandaling nai-deculate ng kliyente ang mensahe at napatunayan ang MAC, ang data ay maipadala sa buong ligtas na koneksyon ng TLS.

Mayroon ding isang extension ng TLS na nagbibigay-daan sa mga koneksyon na maipagpapatuloy sa mga tiket ng session sa halip na mga session ID. Ang server ay nag-encrypt ng data tungkol sa session at ipinapadala ito sa kliyente. Kapag nais ng kliyente na ipagpatuloy ang koneksyon na ito, ipinapadala nito ang ticket ng session sa server, na nag-decrypts upang ipakita ang mga parameter.

Ang mga tiket ng session ay hindi gagamitin nang madalas, dahil nangangailangan sila ng pagpapalawak. Sa kabila nito, maaari silang maging kapaki-pakinabang sa ilang mga sitwasyon, dahil hindi dapat mag-imbak ng anuman ang server.

Hindi binubuklod ang handshake ng TLS

Ang tatlong pinakamahalagang hakbang ng pagkakamay ay kinabibilangan ng:

• napili ang mga parameter,
• nagsasagawa ito ng pagpapatunay, at
• ang mga susi ay itinatag.

Takpan ang mga ito nang mas detalyado upang maunawaan mo ang nangyayari.

Ang mga parameter

Sa pagsisimula ng handshake, ang kliyente at ang server ay nakipag-ayos sa mga parameter ng koneksyon sa pamamagitan ng magkakasamang kasunduan. Ang una sa mga ito ay kung aling bersyon ng TLS ang gagamitin. Ito ang pinakamataas na bersyon na sinusuportahan ng parehong partido, na may posibilidad na maging pinaka-secure.

Nagpasya rin ang mga partido kung aling key ng algorithm ng pagpapalitan ang gagamitin nila upang maitaguyod ang master key. Ang hash function, pag-encrypt algorithm, at paraan ng compression ay napagkasunduan din sa yugtong ito. Ang mga ito ay saklaw nang detalyado kung tatalakayin natin ang Application ng protocol mamaya sa artikulo.

Pagpapatunay: Mga digital na sertipiko

Ang pagpapatunay ay isang pangunahing bahagi ng pag-secure ng isang channel ng komunikasyon, sapagkat ito ay nagpapaalam sa kapwa partido na sila ay tunay na nakikipag-usap sa kung sino ang inaakala nilang sila at hindi isang impostor. Sa TLS at maraming iba pang mga mekanismo ng seguridad, nakamit ito sa kung ano ang kilala bilang mga digital na sertipiko.

Ang mga digital na sertipiko ay mga elektronikong dokumento na nagpapakita ng link sa pagitan ng isang indibidwal o nilalang at ang kanilang pampublikong susi. Ang link na ito ay napatunayan ng isang awtoridad sa sertipiko (CA), na isang mapagkakatiwalaang samahan na nagpapatunay na ang dalawa ay talagang nauugnay, pagkatapos ay gumagamit ng sariling reputasyon upang magbigay ng tiwala sa sertipiko.   

Iba’t ibang mga antas ng sertipiko ay kumakatawan sa iba’t ibang antas ng pagtitiwala. Ang mahalagang dapat malaman ay kung ang isang kliyente o isang server ay may maaasahan at wastong sertipiko, pagkatapos makatuwiran na isipin na ang susi ng publiko ay lehitimo at hindi ka nakikipag-ugnay sa isang umaatake.

Isang tala sa mga pampublikong susi

Ang pampublikong key na pag-encrypt (na kilala rin bilang asymmetric encryption) ay isang mahalagang bahagi ng kriptograpiya, at malawak itong ginagamit sa iba’t ibang aspeto ng TLS. Narito ang isang mabilis na panimulang aklat para sa mga hindi pamilyar sa kung paano ito gumagana.

Ang maikling paliwanag ay iyon Ang pampublikong-susi kriptograpiya ay gumagamit ng isang pangunahing pares para sa pag-encrypt at decryption, kaysa sa isang solong key lamang. Ginagamit ng nagpadala ang susi ng publiko na kanilang inilaan na tatanggap upang i-encrypt ang data. Kapag nai-encrypt na ito, maaari lamang itong mai-decry ng pagtutugma ng pribadong key ng tatanggap. Siyempre, ang pampublikong susi ay maaaring ibinahagi sa publiko habang ang pribadong key ay dapat na itago.

Pinahihintulutan ng pampublikong key na pag-encrypt ang mga partido na maibabahagi nang ligtas ang impormasyon, kahit na hindi pa nila nakilala o nagkaroon ng pagkakataon na palitan muna ang mga key. Ginagawa ito sa pamamagitan ng ilang natatanging katangian ng mga pangunahing numero. Maaari mong malaman ang higit pa sa aming artikulo sa pampublikong key na pag-encrypt.

Pagtatatag ng isang master secret

Tulad ng nakita natin sa itaas noong napag-usapan namin ang proseso ng pangunahing handhake ng TLS, pagkatapos ng isang partido (o kapwa partido) ay nagpapatunay ng pagkakakilanlan nito kasama ang pampublikong sertipiko, ang susunod na hakbang ay upang maitaguyod ang master secret, na kilala rin bilang ibinahaging lihim. Ang master secret ay ang batayan para sa pagkuha ng mga susi na ginamit sa parehong pag-encrypt at suriin ang integridad ng data na ipinadala sa pagitan ng dalawang partido.

Ang handshake ng TLS ay maaaring gumamit ng maraming iba’t ibang mga mekanismo upang maibahagi nang ligtas ang lihim na ito. Kabilang dito ang RSA, maraming magkakaibang uri ng exchange exchange ngie-Hellman, PSK, Kerberos, at iba pa. Ang bawat isa ay may sariling mga pakinabang at kawalan, tulad ng pagbibigay ng pasulong na lihim, ngunit ang mga pagkakaiba na ito ay wala sa saklaw ng artikulong ito.

Ang eksaktong proseso ay depende sa kung aling paraan ng pangunahing palitan ang pinili, ngunit sinusunod nito ang mga magaspang na hakbang na binanggit sa Ang pangunahing handshake ng TLS seksyon.

Ang lihim ng preaster ay nakuha ayon sa alinmang paraan ng key exchange na napili dati. Ini-encrypt ng kliyente ang lihim ng pasilyo gamit ang pampublikong susi ng server upang ligtas na maipadala ito sa buong koneksyon.

Ang kliyente at server pagkatapos ay parehong gumamit ng lihim ng pasilyo at ang mga random na numero na ipinadala nila sa simula ng komunikasyon upang makabuo ng master secret. Kapag ang master key ay kinakalkula, ginagamit ito upang makabuo ng alinman sa apat o anim na hiwalay na mga susi. Ito ang mga:

• Isulat ng kliyente ang key ng MAC – Ang key na ito ay ginagamit ng server upang suriin ang integridad ng data na ipinadala ng kliyente.
• Sumulat ng server ang MAC key – Ang server ay sumulat ng MAC key ay ginagamit ng kliyente upang suriin ang integridad ng data na ipinadala ng server.
• Isulat ang susi ng pag-encrypt ng kliyente – Ginagamit ng server ang susi na ito upang i-encrypt ang data na ipinadala ng kliyente.
• Sumulat ng server ang key key – Ginagamit ng client ang susi na ito upang i-encrypt ang data na ipinadala ng server.
• Isulat ng kliyente ang IV key – Ang kliyente ng pagsusulat ng IV susi ay ginagamit ng server sa mga ciphers ng AEAD, ngunit hindi kapag ginagamit ang iba pang mga key algorithm ng palitan.
• Isulat ng server ang IV key – Katulad nito, ang susi na ito ay ginagamit ng kliyente sa mga ciphers ng AEAD, ngunit hindi kapag ginagamit ang iba pang mga key algorithm algorithm.

Ang pagtatatag ng master key ay isang mahalagang bahagi ng TLS handshake, sapagkat pinapayagan nito ang magkabilang panig ng koneksyon upang ligtas na makuha ang mga susi na maaaring magamit para sa parehong pagpapatunay at pag-encrypt. Ang mga hiwalay na mga susi ay ginagamit para sa parehong mga proseso bilang pag-iingat.

Kapag nakuha na ang mga susi ng pagpapatunay at pag-encrypt, ginagamit ang mga ito upang protektahan ang pareho Tapos na mga mensahe, pati na rin ang mga talaan na ipinadala sa pamamagitan ng application na protocol.

Ang application na protocol

Kapag ang isang ligtas na koneksyon ay naitatag ng handshake ng TLS, ginagamit ang protocol ng aplikasyon upang maprotektahan ang ipinadala na data. Maaari itong mai-configure upang magamit ang isang malawak na hanay ng mga algorithm upang umangkop sa iba’t ibang mga sitwasyon.

Mga algorithm ng pagpapatunay

Ang integridad ng mga mensahe ay maaaring suriin sa maraming iba’t ibang mga algorithm. Kabilang dito ang:

• HMAC-MD5
• HMAC-SHA1
• HMAC-SHA2
• AEAD

Upang mapatunayan ang integridad ng data na ipinadala, nagpadala ang nagpadala ng impormasyon sa pamamagitan ng isang function na hash upang maibalik ang isang natatanging string ng mga character. Ang mga ito ay mga espesyal na pormula na palaging babalik sa parehong resulta tuwing nakakatanggap sila ng parehong input.

Sinusenyasan ng nagpadala ang data na ito gamit ang kanilang pribadong key upang mabuo kung ano ang kilala bilang isang digital na pirma, Ang digital na pirma ay pagkatapos ay naka-attach sa mensahe at ipinadala sa tatanggap. Upang masuri kung ang data ay nananatili ng integridad nito at hindi na-tampuhan, tinatanggal ng tatanggap ang hash gamit ang pampublikong susi ng nagpadala. Pagkatapos ay ginagamit nila ang parehong function ng hash sa data na ipinadala. Ikinukumpara ng tatanggap ang dalawang halaga.

Kung magkapareho sila, nangangahulugan ito na ang data ay hindi nabago mula nang ito ay nilagdaan ng nagpadala. Kung naiiba sila, malamang na ang data ay na-tampered, o nagkaroon ng iba pang mga error.

Iyon ang maikling bersyon ng kung paano maaaring magamit ang hash function upang maipakita ang integridad ng data. Kung nais mo ng isang mas malalim na pag-unawa, tingnan ang aming artikulo sa pag-encrypt, salting at hashing.

Mga algorithm ng pag-encrypt

Gumagamit ang TLS ng simetriko-key encryption upang magbigay ng pagiging kompidensiyal sa data na ipinapadala nito. Hindi tulad ng pampublikong key na pag-encrypt, isang key lamang ang ginagamit sa parehong mga proseso ng pag-encrypt at decryption. Sa sandaling naka-encrypt ang data gamit ang isang algorithm, lilitaw ito bilang isang pag-iingat ng ciphertext. Hangga’t ginagamit ang isang naaangkop na algorithm, hindi mai-access ng mga umaatake ang aktwal na data, kahit na hinarang nila ito.

Ang TLS ay maaaring gumamit ng maraming iba’t ibang mga algorithm, tulad ng Camellia o ARIA, kahit na ang pinakapopular ay AES.

Kompresyon

Ang compression ay ang proseso ng pag-encode ng data upang gawin itong mas kaunting silid. Sinusuportahan ng TLS ang compression kung ang magkabilang panig ng koneksyon ay magpasya na gamitin ito. Sa kabila ng kakayahang ito, karaniwang inirerekumenda na maiwasan ang paggamit ng TLS upang i-compress ang data, lalo na mula sa pag-atake ng CRIME (tingnan ang Mga Isyu sa Seguridad ng TLS seksyon sa ibaba) ay natagpuan upang samantalahin ang mga naka-compress na data para sa pag-hijack ng session.

Padding

Ang padding ay nagdaragdag ng labis na data sa isang mensahe bago ito mai-encrypt. Ito ay isang pangkaraniwang proseso ng cryptographic na ginagamit upang makatulong na maiwasan ang mga pahiwatig sa istraktura ng naka-encrypt na data mula sa pagbibigay ng tunay na kahulugan. Karaniwang nalalapat ng TLS ang PKCS # 7 padding sa mga talaan bago sila mai-encrypt.

Alert protocol

Kung ang koneksyon o seguridad ay hindi matatag, nakompromiso, o isang malubhang pagkakamali ang naganap, pinapayagan ng alertong protocol ang nagpadala na abisuhan ang ibang partido. Ang mga mensahe na ito ay may dalawang uri, alinman sa babala o nakamamatay. Ang isang babalang mensahe ay nagpapahiwatig na ang session ay hindi matatag at pinapayagan ang tatanggap na matukoy kung dapat bang ipagpatuloy ang session.

Ang isang nakamamatay na mensahe ay nagsasabi sa tatanggap na ang koneksyon ay nakompromiso o naganap ang isang malubhang pagkakamali. Dapat isara ng nagpadala ang koneksyon pagkatapos na maipadala nila ang mensahe. Naglalaman din ang alerto ng protocol ng impormasyon tungkol sa kung ano ang nagiging sanhi ng partikular na problema sa koneksyon. Maaari nitong isama ang mga bagay tulad ng pagkabigo sa decryption, isang hindi kilalang awtoridad sa sertipiko, isang iligal na parameter at marami pa.

TLS & ang modelo ng OSI

Ang modelo ng OSI ay isang paraan upang ma-conceptualize at standardize kung paano namin titingnan ang aming iba’t ibang mga sistema ng komunikasyon at protocol. Mahalagang tandaan na ito ay isang modelo lamang, at ang ilan sa aming mga protocol ay hindi umaayon dito.

Ang OSI ay may pitong magkahiwalay na layer na nagpapakita ng mga antas na nagpapatakbo ng mga protocol, Ang TLS ay hindi umaangkop sa anumang iisa. Dumadaloy ito sa isa pang transport protocol tulad ng TCP, na dapat ipahiwatig na ito ay higit sa ikaapat na layer, ang layer ng transportasyon. Ito ay pinaka-tanyag na ginamit tulad ng isang layer ng transportasyon, ngunit dahil nagsasagawa ito ng mga handshakes, ipahiwatig nito na bahagi ito ng pagtatanghal o mga layer ng aplikasyon.

Tulad ng nakikita mo, ang TLS ay hindi umaayon sa modelo ng OSI. Hindi ito nangangahulugan na ang TLS ay nasira o mali, kung mayroon man, ipinakikita lamang nito na ang modelo ng OSI ay may kamalian at hindi na nagkuwenta para sa lahat ng aming mga protocol sa komunikasyon.

Paggamit ng TLS

Ginagamit ang TLS upang ma-secure ang isang makabuluhang proporsyon ng aming online na komunikasyon. Karaniwan ito ay ipinatutupad sa mga protocol tulad ng Transmission Control Protocol (TCP), ngunit maaari din itong magamit sa Datagram Congestion Control Protocol (DCCP) at User Datagram Protocol (UDP).

Maaari itong mai-secure ang mga protocol tulad ng HTTP, SMTP, FTP, XMPP at NNTP, pati na rin ang iba. Ang pinaka-karaniwang application ay bilang Hypertext Transfer Protocol Secure (HTTPS), na pinoprotektahan ang koneksyon sa pagitan ng isang web browser at isang website. Maaari mong sabihin kung kailan ginagamit ang HTTPS upang ma-secure ang iyong online na koneksyon, dahil ang isang maliit na berdeng icon ng lock ay lilitaw sa kaliwa ng URL sa tuktok ng iyong browser.

Maaari ring magamit ang TLS upang makabuo ng mga VPN, tulad ng sa OpenConnect at OpenVPN. Ginagamit nito ang mga kakayahan sa pag-encrypt at pagpapatotoo upang makabuo ng isang lagusan na maaaring kumonekta sa mga host at network sa bawat isa. Ang mga teknolohiya na batay sa TLS tulad ng OpenVPN ay kapaki-pakinabang sa mga kahalili tulad ng IPsec, dahil ang OpenVPN ay hindi kilala na magkaroon ng anumang mga seryosong isyu sa seguridad. Ang mga VPN na ito ay maaari ring maging mas madaling i-configure.

Ang isa pang gamit nito ay ang ligtas na email sa pamamagitan ng STARTTLS. Kapag ipinatupad ang TLS, pinipigilan ang mga attackers na ma-access ang mga mensahe habang naglalakbay sila sa pagitan ng mga mail server.

Mga isyu sa seguridad ng TLS

Tulad ng karamihan sa mga protocol, ang TLS ay nagkaroon ng maraming mga nakaraang kahinaan at pag-atake ng teoretiko laban sa iba’t ibang mga pagpapatupad nito. Sa kabila nito, ang pinakabagong bersyon ay itinuturing na ligtas para sa mga praktikal na layunin.

Ang mga nakaraang bersyon, tulad ng SSL 2.0 at 3.0 (at TLS 1.0, na mahalagang kapareho ng SSL 3.0) ay nagtatampok ng maraming mga bahid ng seguridad, ngunit dahil sila ay luma at inalis ang mga protocol, hindi namin napunta sa mga detalye. Dapat mong gamitin ang TLS 1.2 at 1.3 upang ma-secure ang iyong mga koneksyon sa halip.

Ang mga mas bagong bersyon ng TLS ay may maraming mga pag-upgrade na ginagawang mas mahina laban sa SSL. Sa kabila nito, ang protocol ay mayroon pa ring mga sumusunod na isyu sa seguridad:

Pag-atake sa pagbawi

Ang isa sa mga tampok ng TLS ay pinahihintulutan ang mga pares ng kliyente at server na muling baguhin ang mga parameter ng kanilang umiiral na koneksyon. Noong 2009, natuklasan na maaaring mapagsamantala ito ng mga umaatake upang maaari silang mag-iniksyon ng trapiko upang magmukhang nagmula ito sa kliyente. Tatanggapin ng mga server ang kahilingan bilang lehitimo, na nangangahulugang ang mga umaatake ay maaaring manipulahin ang mga papalabas na mensahe.

Ang pag-atake na ito ay hindi pinapayagan ang attacker na makita ang tugon, ngunit mayroon pa ring potensyal na mapinsala. Ang isang extension na maiiwasan ang mga pag-atake na ito ay kasalukuyang isang iminungkahing pamantayan.

HAYOP

Ang pag-atake ng Browser Laban sa SSL / TLS (BEAST) ay unang natuklasan ng mga mananaliksik noong 2011. Sinamantala nito ang kahinaan ng cipher block na kahinaan sa TLS, na maaaring magamit upang i-decrypt ang mga mensahe. Ang pag-atake na ito ay nakakaapekto lamang sa TLS 1.0, na kung saan ay isang luma at mahina na bersyon ng protocol. Bagaman hindi ito maialis hanggang sa 2023, ang mga gumagamit ay dapat gumamit ng mga bersyon 1.2 at 1.3.

Pag-atake sa oras

Ang mga pag-atake sa panig na ito ay pinag-aaralan kung gaano katagal kinakailangan upang tumakbo ang isang algorithm, pagkatapos ay gamitin ang impormasyong iyon upang gumana paatras at malaman ang susi. Noong 2013, ang pag-atake ng Lucky Thirteen ay natuklasan upang magamit ang parehong pag-atake sa tiyempo at isang pag-atake ng padding oracle habang sinusubaybayan ang mensahe na authentication code (MAC). Ang pag-atake na ito ay maaaring magamit upang masira ang TLS algorithm, bagaman hindi ito itinuturing na mapanganib para sa karamihan ng mga gumagamit ng TLS.

KRIMEN & BREACH

Gumagawa ang pag-atake ng CRIME laban sa isang hanay ng mga protocol. Kapag na-compress ang data, maaari itong kumuha ng nilalaman mula sa cookies ng pagpapatunay. Ang impormasyong ito ay maaaring magamit para sa pag-hijack ng session. Habang nakakaapekto ito sa isang bilang ng mga protocol, ang pag-atake ay partikular na nababahala kapag ginagamit ang compression ng HTTP, dahil walang mga epektibong diskarte sa pagpapawalang-bisa.

Noong 2013, ang Browser Reconnaissance and Exfiltration sa pamamagitan ng Adaptive Compression of Hypertext (BREACH) ay nahanap upang makaapekto sa compression ng HTTP sa isang katulad na paraan. Ang bersyon na ito ng pag-atake ay maaaring mabawi ang mga email address at iba pang mahalagang data na naka-encrypt sa TLS. Ang pag-atake ng BREACH ay maaaring mapagaan sa pamamagitan ng hindi pagpapagana ng pag-compress ng HTTP, o paggamit ng mga pamamaraan tulad ng proteksyon ng kahilingan sa cross-site (CSRF).

Pag-atake ng pagbagsak

Ito ang mga pag-atake na ang mga server ng trick na gumagamit ng mas maaga at hindi gaanong ligtas na mga bersyon ng TLS. Maaaring gamitin ng mga umaatake ang mga pamamaraan na ito upang makipag-ayos sa paggamit ng mga hindi gaanong ligtas na mga palitan at ciphers. Ang pag-atake ng Logjam ay isang mabuting halimbawa dahil maaari itong gumawa ng mga mahina na server na gumamit ng 512-bit Diffie-Hellman, na mahina. Pagkatapos ay masisira ng mga atake ang susi na mekanismo ng palitan at kunin ang mga susi, na pinapayagan silang kumpletuhin ang pag-access sa session.

Malakas ang loob

Ang Heartbleed ay isang security flaw na hindi sinasadyang ipinakilala sa OpenSSL kriptograpiyang library noong 2012, ngunit hindi naisapubliko hanggang sa 2014. Dahil ito ay isang karaniwang ginagamit na pagpapatupad ng TLS, nagdulot ito ng malaking pandaigdigang pinsala.

Ang isa sa mga nag-develop para sa extension ng tibok ng puso ng TLS ay nagdagdag ng isang kahinaan sa over-read na kahinaan, na nagpapahintulot sa ilang dagdag na data na maihayag. Ang error ay hindi kinuha kung susuriin ang code, na humantong sa isang bilang ng mga makabuluhang pag-atake.

Dahil ang OpenSSL library ay ipinatupad nang napakalawak, ang internasyonal na gastos ng pag-iwas sa isyu ay natapos na medyo mahal. Kailangang mai-install ng mga tagapangasiwa ng server ang bagong patch at muling pagbuo ng mga sertipiko at mga pangunahing pares na maaaring na-kompromiso sa loob ng dalawang taon na ang kahinaan ay umiiral.

GUSTO

Ang Pag-decrypting ng RSA kasama ang Usaw at Nahihina na eNcryption (DROWN) na pag-atake ay inanunsyo noong 2016 at sinasamantala nito ang suporta sa server para sa SSL 2.0. Gumagamit ito ng isang napiling-ciphertext na pag-atake laban sa mga server na sumusuporta pa rin sa SSL 2.0, pati na rin ang mga nagbabahagi ng parehong pampublikong susi sertipiko sa isa pang server na sumusuporta sa SSL 2.0.

Kapag inihayag ang pag-atake, maaari itong mailunsad kasama ang paunang mga gastos sa pag-setup na halos $ 18,000 at tungkol sa $ 400 para sa bawat magkahiwalay na pag-atake. Kapag matagumpay ang pag-atake ng DROWN, nakuha nito ang mga susi ng session.

Ang pag-atake ay maaaring mapagaan sa pamamagitan ng hindi pagbabahagi ng mga sertipiko ng server. Ang grupong OpenSSL ay naglabas din ng mga patch na nag-aalis ng suporta para sa mga matatandang protocol at ciphers, ngunit ang mga ito ay gumagana lamang kung ang sertipiko ng server ay hindi ibinahagi sa iba pang mga server na sumusuporta sa SSL 2.0.

Di-banal na PAC

Ang pag-atake na ito ay natagpuan noong 2016. Nakukuha nito ang mga kahinaan na matatagpuan sa Web Proxy Autodiscovery Protocol (WPAD). Kapag sinusubukan ng isang gumagamit na bisitahin ang isang website sa isang koneksyon na naka-encrypt na TLS, maaaring makita ng kapintasan ang URL. Dahil ang mga URL ay kung minsan ay ipinapadala sa mga gumagamit bilang isang form ng pagpapatunay, ang Unholy PAC na pag-atake ay posible para sa isang umaatake na kumuha ng account ng isang gumagamit.

Ligtas ba ang TLS?

Habang ito ay tila tulad ng maraming mga isyu sa seguridad, ang katotohanan ay na ang karamihan sa mga ito ay medyo menor de edad at maaaring o napagaan. Habang tumatagal ang teknolohiya, ang mga kahinaan ay natuklasan at ang mga bagong pag-atake ay binuo, ang TLS ay magpapatuloy na magkaroon ng mas maraming mga problema sa seguridad. Sa kabila nito, sa ngayon at sa mahahanap na hinaharap, mukhang ang TLS ay magiging isa pa rin sa pangunahing at maaasahang mga tool na ginagamit namin upang ma-secure ang aming online na mundo.

Ang teknolohiya ng negosyo sa seguridad ng cyber sa pamamagitan ng TheDigitalArtist na lisensyado sa ilalim CC0