Transport qatlamining xavfsizligi - Transport Layer Security

Transport qatlamining xavfsizligi (TLS) va hozirda eskirgan salafiy, Xavfsiz soket qatlami (SSL),^[1] bor kriptografik protokollar ta'minlash uchun mo'ljallangan aloqa xavfsizligi ustidan kompyuter tarmog'i.^[2] Protokollarning bir nechta versiyalari kabi dasturlarda keng qo'llanilishini topadi veb-sahifalarni ko'rish, elektron pochta, tezkor xabar almashish va IP orqali ovoz (VoIP). Veb-saytlar TLS-dan o'zlarining barcha aloqalarini ta'minlash uchun foydalanishi mumkin serverlar va veb-brauzerlar.

TLS protokoli asosan ta'minlashga qaratilgan maxfiylik va ma'lumotlar yaxlitligi ikki yoki undan ortiq aloqa qiluvchi kompyuter dasturlari o'rtasida.^[2]:3 TLS bilan ta'minlangan holda, mijoz (masalan, veb-brauzer) va server (masalan, wikipedia.org) o'rtasidagi ulanishlar quyidagi xususiyatlardan biriga yoki bir nechtasiga ega bo'lishi kerak:

• Ulanish xususiy (yoki xavfsiz) chunki nosimmetrik kriptografiya uchun ishlatiladi shifrlash uzatilgan ma'lumotlar. The kalitlar chunki bu nosimmetrik shifrlash har bir ulanish uchun noyob tarzda hosil qilinadi va a ga asoslanadi umumiy sir boshida kelishilgan edi sessiya (qarang § TLS bilan qo'l siqish ). Server va mijoz birinchisidan oldin qaysi shifrlash algoritmi va kriptografik kalitlarni ishlatishi haqida batafsil ma'lumot beradi bayt ma'lumotlar uzatiladi (qarang. qarang § Algoritmlar quyida). Umumiy sirni muhokama qilish har ikkala xavfsizdir (muzokara qilingan sir mavjud emas) tinglovchilar va hatto o'zini tutashuvning o'rtasiga joylashtirgan tajovuzkor tomonidan ham olinishi mumkin emas) va ishonchli (biron bir tajovuzkor muzokaralar paytida aloqalarni aniqlanmasdan o'zgartira olmaydi).
• Muloqot qiluvchi tomonlarning shaxsiyati bo'lishi mumkin tasdiqlangan foydalanish ochiq kalitli kriptografiya. Ushbu autentifikatsiya ixtiyoriy bo'lishi mumkin, lekin, odatda, tomonlarning kamida bittasi (odatda server) uchun talab qilinadi.
• Ulanish ishonchli chunki har bir uzatilgan xabar a yordamida butunlikni tekshirishni o'z ichiga oladi xabarni tasdiqlash kodi davomida ma'lumotlarning aniqlanmagan yo'qolishi yoki o'zgarishini oldini olish yuqish.^[2]:3

Yuqoridagi xususiyatlardan tashqari, ehtiyot bo'ling konfiguratsiya kabi TLS maxfiylik bilan bog'liq qo'shimcha xususiyatlarni taqdim etishi mumkin oldinga maxfiylik, kelgusida shifrlash kalitlarining har qanday oshkor etilishi o'tmishda yozilgan har qanday TLS aloqalarini parolini hal qilish uchun ishlatilmasligini ta'minlash.^[3]

TLS kalitlarni almashtirish, ma'lumotlarni shifrlash va xabarlarning yaxlitligini tasdiqlash uchun turli xil usullarni qo'llab-quvvatlaydi (qarang § Algoritmlar quyida). Natijada, TLS-ning xavfsiz konfiguratsiyasi ko'plab sozlanishi parametrlarni o'z ichiga oladi va barcha tanlovlar yuqoridagi ro'yxatda tavsiflangan barcha maxfiylik xususiyatlarini ta'minlamaydi (qarang: § kalitlarni almashtirish (autentifikatsiya), § shifr xavfsizligi va § ma'lumotlar yaxlitligi jadvallar).

Aloqa xavfsizligining TLS ta'minlamoqchi bo'lgan tomonlarini buzishga urinishlar qilingan va ushbu tahdidlarga qarshi protokol bir necha bor qayta ko'rib chiqilgan (qarang. § xavfsizlik ). Veb-brauzerlar ishlab chiqaruvchilari xavfsizlikni yuzaga kelishi mumkin bo'lgan zaif tomonlaridan himoya qilish uchun o'z mahsulotlarini bir necha bor qayta ko'rib chiqdilar (qarang) TLS / SSL veb-brauzerlarini qo'llab-quvvatlash tarixi ).^[4]

TLS protokoli ikki qatlamdan iborat: the TLS yozuvi va TLS qo'l siqish protokollar.

TLS - bu taklif qilingan Internet Engineering Engineering Task (IETF ) standart, birinchi marta 1999 yilda aniqlangan va hozirgi versiyasi TLS 1.3 da belgilangan RFC  8446 (2018 yil avgust). TLS avval ishlab chiqarilgan SSL spetsifikatsiyalariga (1994, 1995, 1996) asoslanadi Netscape Communications^[5]qo'shish uchun HTTPS ularga protokol Navigator veb-brauzer.

Tavsif

Mijoz-server ilovalar TLS dan foydalanadi protokol tinglashning oldini olish uchun mo'ljallangan va tarmoq orqali aloqa qilish buzish.

Ilovalar TLS (yoki SSL) bilan yoki ular bilan aloqa o'rnatishi mumkinligi sababli, bu uchun zarur mijoz ga ishora qilish server TLS ulanishini sozlash.^[6] Bunga erishishning asosiy usullaridan biri boshqasidan foydalanishdir port raqami TLS ulanishlari uchun, masalan 443-port HTTPS. Boshqa bir mexanizm - mijozga ulanishni TLS ga o'tkazish uchun serverga protokolga xos so'rov yuborishi; masalan STARTTLS pochtadan foydalanishda so'rov va Yangiliklar protokollar.

Mijoz va server TLS-dan foydalanishga rozi bo'lgandan so'ng, ular bilan kelishishadi davlat a yordamida ulanish qo'l siqish protsedura.^[7] Protokollarda an bilan qo'l siqish ishlatiladi assimetrik shifr nafaqat shifrlash sozlamalarini, balki a yordamida keyingi aloqa shifrlangan sessiyaga xos umumiy kalitni ham o'rnatish nosimmetrik shifr. Ushbu qo'l siqish paytida mijoz va server ulanish xavfsizligini o'rnatish uchun foydalaniladigan turli xil parametrlarga kelishadi:

• Mijoz xavfsiz ulanishni talab qiladigan TLS-quvvatlangan serverga ulanganida va mijoz qo'llab-quvvatlanadigan ro'yxatini taqdim qilganda, qo'l siqish boshlanadi. shifrlangan suitlar (shifrlar va xash funktsiyalari ).
• Ushbu ro'yxatdan server shifr va xash funktsiyasini tanlaydi, u ham qo'llab-quvvatlaydi va mijozga qaror to'g'risida xabar beradi.
• Server odatda keyinchalik identifikatsiyani a shaklida taqdim etadi raqamli sertifikat. Sertifikatda quyidagilar mavjud server nomi, ishonchli sertifikat markazi (CA) sertifikatning haqiqiyligini va serverning ochiq shifrlash kalitini kafolatlaydi.
• Mijoz ish boshlashdan oldin sertifikatning amal qilish muddatini tasdiqlaydi.
• Xavfsiz ulanish uchun ishlatiladigan sessiya kalitlarini yaratish uchun mijoz ham:
  • shifrlash a tasodifiy raqam serverning ochiq kaliti bilan va natijani serverga yuboradi (faqat server o'zining shaxsiy kaliti bilan parolini ochishi kerak); keyin ikkala tomon tasodifiy raqamdan foydalanib sessiya davomida ma'lumotlarni keyingi shifrlash va parolini hal qilish uchun noyob seans kalitini yaratadi.
  • foydalanadi Diffie-Hellman kalit almashinuvi shifrlash va parolni hal qilish uchun tasodifiy va noyob seans kalitini xavfsiz tarzda yaratish uchun, oldinga sirning qo'shimcha xususiyatiga ega: agar kelajakda serverning shaxsiy kaliti oshkor bo'lsa, uni sessiyani ushlab qolish va yozib olishda ham, uni joriy seansning parolini ochishda ishlatib bo'lmaydi. uchinchi shaxs tomonidan.

Bu qo'l uzatishni yakunlaydi va ulanish yopilguncha sessiya tugmachasi bilan shifrlangan va shifrlangan xavfsiz ulanishni boshlaydi. Agar yuqoridagi qadamlardan biri bajarilmasa, u holda TLS bilan qo'l siqish muvaffaqiyatsiz bo'ladi va ulanish o'rnatilmaydi.

TLS va SSL har qanday qatlamga yaxshi mos kelmaydi OSI modeli yoki TCP / IP modeli.^[8][9] TLS "ishonchli transport protokoli (masalan, TCP) ustida" ishlaydi^[10] bu yuqorida ko'rsatilganligini anglatadi transport qatlami. Odatda yuqori funktsiyalarga ega bo'lgan yuqori qatlamlarga shifrlash xizmat qiladi taqdimot qatlami. Biroq, ilovalar odatda TLS-ni xuddi transport qatlami kabi ishlatadi,^[8][9] TLS-dan foydalanadigan dasturlar TLS-ning qo'l siqishlarini boshlashni va almashinadigan autentifikatsiya sertifikatlari bilan ishlashni faol nazorat qilishi kerak.^[10]

Tarix va rivojlanish

Xavfsiz ma'lumotlar tarmog'i tizimi

Transport qatlamining xavfsizligi to'g'risidagi protokol (TLS) boshqa bir qator asosiy tarmoq xavfsizligi platformalari bilan birgalikda 1986 yil avgustda boshlangan Milliy Xavfsizlik Agentligi, Milliy Standartlar Byurosi, Mudofaa Aloqa Agentligi va o'n ikkita aloqa va Secure Data Network System (SDNS) deb nomlangan maxsus loyihani boshlagan kompyuter korporatsiyalari.^[14] Dastur 1987 yil sentyabr oyida 10-sonli kompyuter xavfsizligi bo'yicha milliy konferentsiyada nashr etilgan keng ko'lamli to'plamda tavsiflangan. Innovatsion tadqiqot dasturi xavfsiz va ishonchli kompyuter kommunikatsiyalari tarmog'ining yangi avlodini loyihalashtirishga qaratilgan bo'lib, davlat va xususiy tarmoqlarda qo'llanilishi mumkin bo'lgan mahsulot spetsifikatsiyasi. Bu AQSh hukumatining GOSIP profillarida ham, xalqaro miqyosda ITU-ISO JTC1 ulkan Internet-sa'y-harakatlarida ham tez sur'atlar bilan rivojlanayotgan yangi OSI internet standartlarini to'ldirishga qaratilgan edi. Dastlab SP4 protokoli sifatida tanilgan, u TLS deb o'zgartirilgan va keyinchalik 1995 yilda ITU-T X.274 xalqaro standarti sifatida nashr etilgan | ISO / IEC 10736: 1995.

Xavfsiz tarmoq dasturlash

Transport qatlamining xavfsizligini ta'minlash bo'yicha dastlabki tadqiqot ishlariga quyidagilar kiradi Xavfsiz tarmoq dasturlash (SNP) dastur dasturlash interfeysi (API), 1993 yilda xavfsiz transport qatlami API ga o'xshash yondashuvni o'rganib chiqdi Berkli rozetkalari, xavfsizlik choralari bilan oldindan mavjud bo'lgan tarmoq dasturlarini qayta jihozlashni osonlashtirish.^[15]

SSL 1.0, 2.0 va 3.0

Netscape original SSL protokollarini ishlab chiqdi va Taher Elgamal, 1995 yildan 1998 yilgacha Netscape Communications kompaniyasining bosh olimi "SSLning otasi" deb ta'riflangan.^{[16][17][18][19]} SSL versiyasi 1.0 protokoldagi jiddiy xavfsizlik nuqsonlari tufayli hech qachon ommaviy ravishda chiqarilmagan. 1995 yil fevral oyida chiqarilgan 2.0 versiyasida bir qator xavfsizlik nuqsonlari mavjud bo'lib, ular 3.0 versiyasini ishlab chiqishni talab qildilar.^[20][18] 1996 yilda chiqarilgan SSL 3.0 versiyasi tomonidan ishlab chiqarilgan protokolning to'liq qayta ishlanganligini namoyish etdi Pol Kocher Netscape muhandislari Fil Karlton va Alan Frayer bilan ishlash, Kristofer Allen va Konsensusni rivojlantirish bo'yicha Tim Dierks tomonidan amalga oshirilgan ma'lumotlar. SSL / TLS ning yangi versiyalari SSL 3.0 ga asoslangan. 1996 yil SSL 3.0 loyihasi IETF tomonidan tarixiy hujjat sifatida nashr etilgan RFC  6101.

SSL 2.0 2011 yilda bekor qilingan RFC  6176. 2014 yilda SSL 3.0 ning himoyasizligi aniqlandi PODLE hammaga ta'sir qiladigan hujum blok shifrlari SSL-da; RC4, SSL 3.0 tomonidan qo'llab-quvvatlanadigan yagona blokirovka qilinmaydigan shifr, shuningdek SSL 3.0 da ishlatilganidek buzilgan.^[21] SSL 3.0 2015 yil iyun oyida bekor qilingan RFC  7568.

1.0 TL

TLS 1.0 birinchi marta aniqlangan RFC  2246 1999 yil yanvar oyida SSL Version 3.0 versiyasini yangilash sifatida va Kristofer Allen va Tim Dierks tomonidan Consensus Development kompaniyasi tomonidan yozilgan. RFCda ta'kidlanganidek, "ushbu protokol va SSL 3.0 o'rtasidagi farqlar keskin emas, ammo ular TLS 1.0 va SSL 3.0 o'rtasidagi o'zaro bog'liqlikni istisno qiladigan darajada ahamiyatlidir". Keyinchalik Tim Dierks ushbu o'zgarishlar va "SSL" dan "TLS" ga o'zgartirilishi Microsoft uchun yuzni tejaydigan imo-ishora ekanligini aytdi, "shuning uchun IETF bu shunchaki Netscape protokoliga muhr bosgan".^[22]

TLS 1.0, TLS dasturining ulanishni SSL 3.0 ga tushirishi va xavfsizlikni zaiflashtirishi mumkin bo'lgan vositalarni o'z ichiga oladi.^[23]:1–2

The PCI Kengashi tashkilotlarga 2018 yil 30-iyungacha 1,0 TLS dan 1,1 yoki undan yuqori TLS ga o'tishni taklif qildi.^[24][25] 2018 yil oktyabr oyida, olma, Google, Microsoft va Mozilla birgalikda 2020 yil mart oyida 1.0 va 1.1 TLS qiymatini bekor qilishlarini e'lon qilishdi.^[11]

TLS 1.1

TLS 1.1 da belgilangan RFC  4346 2006 yil aprel oyida.^[26] Bu TLS 1.0 versiyasining yangilanishi. Ushbu versiyadagi sezilarli farqlarga quyidagilar kiradi:

• Qarshi himoya qo'shildi shifr-blok zanjiri (CBC) hujumlari.
  • Yashirin boshlash vektori (IV) aniq IV bilan almashtirildi.
  • Bilan ishlashning o'zgarishi to'ldirish xatolari.
• Qo'llab-quvvatlash IANA parametrlarni ro'yxatdan o'tkazish.^[23]:2

TLS 1.2

TLS 1.2 da belgilangan RFC  5246 2008 yil avgustida. U avvalgi TLS 1.1 spetsifikatsiyasiga asoslangan. Asosiy farqlarga quyidagilar kiradi:

• The MD5 -SHA-1 tarkibidagi pseudorandom funktsiyasi (PRF) bilan almashtirildi SHA-256, foydalanish imkoniyati bilan shifrlangan to'plam belgilangan PRFlar.
• Tugatilgan xabarda MD5-SHA-1 kombinatsiyasi xash shifrlangan to'plamga xos hash algoritmlaridan foydalanish imkoniyati bilan SHA-256 bilan almashtirildi. Shu bilan birga, tugagan xabardagi xash hajmi hali kamida 96 bo'lishi kerak bitlar.^[27]
• Raqamli imzolangan elementdagi MD5-SHA-1 kombinatsiyasi davomida kelishilgan bitta xash bilan almashtirildi qo'l siqish, bu SHA-1 ga mos kelmaydi.
• Mijoz va serverning qaysi xeshlar va imzo algoritmlarini qabul qilishlarini belgilash qobiliyatini oshirish.
• Uchun yordamni kengaytirish tasdiqlangan shifrlash asosan uchun ishlatiladigan shifrlar Galois / hisoblagich rejimi (GCM) va CCM rejimi ning Kengaytirilgan shifrlash standarti (AES) shifrlash.
• TLS kengaytmalari ta'rifi va AES shifrlangan to'plamlari qo'shildi.^[23]:2

Barcha TLS versiyalari yanada takomillashtirildi RFC  6176 2011 yil mart oyida, ularning SSL bilan orqaga qarab muvofiqligini olib tashladilar, shunda TLS sessiyalari Secure Sockets Layer (SSL) 2.0 versiyasidan foydalanish to'g'risida hech qachon muzokara o'tkazmaydi.

TLS 1.3

TLS 1.3 da belgilangan RFC  8446 avgust oyida 2018. Bu avvalgi TLS 1.2 spetsifikatsiyasiga asoslangan. TLS 1.2 ning asosiy farqlariga quyidagilar kiradi:^[28]

• Shifrlangan to'plamlardan kalit kelishuv va autentifikatsiya algoritmlarini ajratish
• Zaif va kam ishlatiladigan nomlanganlarni qo'llab-quvvatlashni olib tashlash elliptik egri chiziqlar
• MD5 va SHA-224 uchun yordamni olib tashlash kriptografik xash funktsiyalari
• Oldingi konfiguratsiyadan foydalanilganda ham raqamli imzolarni talab qilish
• Birlashtirilmoqda HKDF va yarim efemer DH taklifi
• Qayta tiklashni almashtirish PSK va chiptalar
• 1-ni qo'llab-quvvatlashRTT 0 uchun qo'l siqish va dastlabki yordamRTT
• Majburiy oldinga mukammal maxfiylik, (EC) DH kalit kelishuvi paytida vaqtinchalik kalitlardan foydalanish orqali
• Ko'plab xavfli yoki eskirgan xususiyatlarni qo'llab-quvvatlashni bekor qilish, shu jumladan siqilish, qayta muzokaralar olib borish,AEAD shifrlarPFS kalit almashinuvi (ular orasida statik) RSA va statik DH kalit almashinuvlar), odatiy DHE guruhlar, EC nuqta formati bo'yicha muzokaralar, Cipher Spec protokolini o'zgartirish, UNIX vaqti bilan salom xabari va AD maydonining AEAD shifrlariga kiritilishi
• Orqaga muvofiqligi uchun SSL yoki RC4 muzokaralarini taqiqlash
• Seans xashidan foydalanishni birlashtirish
• Ro'yxatdan o'tish qatlamining versiya raqamidan foydalanishni bekor qilish va orqaga qarab muvofiqligini yaxshilash uchun raqamni muzlatib qo'yish
• Xavfsizlik bilan bog'liq ba'zi bir algoritm tafsilotlarini ilovadan spetsifikatsiyaga o'tkazish va ClientKeyShare-ni qo'shimchaga o'tkazish
• Qo'shilishi ChaCha20 bilan oqim shifrini Poly1305 xabarni tasdiqlash kodi
• Qo'shilishi Ed25519 va Ed448 raqamli imzo algoritmlari
• Qo'shilishi x25519 va x448 kalit almashinuv protokollari
• Bir nechta yuborish uchun yordam beradi OCSP javoblar
• ServerHello-dan keyin barcha qo'l siqish xabarlarini shifrlaydi

Tarmoq xavfsizligi xizmatlari (NSS), tomonidan ishlab chiqilgan kriptografiya kutubxonasi Mozilla va veb-brauzerida foydalaniladi Firefox, 2017 yil fevral oyida sukut bo'yicha TLS 1.3-ni yoqdi.^[29] Keyinchalik TLS 1.3 yordami qo'shildi - lekin oz sonli foydalanuvchilar uchun moslik muammolari tufayli avtomatik ravishda yoqilmagan^[30] - ga Firefox 52.0, 2017 yil mart oyida chiqarilgan. TLS 1.3 sukut bo'yicha 2018 yil may oyida ishga tushirilishi bilan yoqilgan Firefox 60.0.^[31]

Gugl xrom 2017 yilda qisqa vaqt ichida TLS 1.3-ni standart versiya sifatida o'rnating. Keyin mos kelmaydigan o'rta qutilar tufayli uni standart sifatida olib tashladi. Blue Coat veb-proksi-serverlari.^[32]

IETF 100 davomida Xakaton bo'lib o'tgan Singapur 2017 yilda TLS Group moslashtirish ustida ishladi ochiq manbali dasturlar TLS 1.3 dan foydalanish.^[33][34] TLS guruhi shaxslardan iborat edi Yaponiya, Birlashgan Qirollik va Mavrikiy kiberstorm.mu jamoasi orqali.^[34] Ushbu ish IETF 101 Hackathon-da davom ettirildi London, ^[35] va Monrealdagi IETF 102 Hackathon.^[36]

wolfSSL 2017 yil may oyida chiqarilgan 3.11.1 versiyasi bo'yicha TLS 1.3-dan foydalanishga imkon berdi.^[37] Birinchi tijorat TLS 1.3 dasturi sifatida wolfSSL 3.11.1 18-chi loyihani qo'llab-quvvatladi va endi 28-chi loyihani qo'llab-quvvatlaydi,^[38] oxirgi versiya, shuningdek ko'plab eski versiyalar. TLS 1.2 va 1.3 o'rtasidagi ishlash farqi bo'yicha bir qator bloglar nashr etildi.^[39]

Yilda 2018 yil sentyabr, mashhur OpenSSL loyiha o'zining kutubxonasining 1.1.1 versiyasini chiqardi, unda TLS 1.3-ni qo'llab-quvvatlash "yangi xususiyat" bo'ldi.^[40]

Korxona transport xavfsizligi

The Elektron chegara fondi TLS 1.3 ni maqtadi va variant protokoli haqida tashvish bildirdi Korxona transport xavfsizligi (ETS) TLS 1.3-dagi muhim xavfsizlik choralarini qasddan o'chirib qo'yadi.^[41] ETS - ma'lum bo'lgan nashr etilgan standart ETSI TS103523-3, "Middlebox Security Protocol, Part3: Enterprise Transport Security" va zararli dasturlarni joylashtirish, ma'lumotlarning noqonuniy eksfiltratsiyasi va nazorat qiluvchi auditorlik mandatlariga rioya qilishni aniqlash uchun bank tizimlari kabi mulkiy tarmoqlarda to'liq foydalanishga mo'ljallangan.

Raqamli sertifikatlar

Raqamli sertifikatga ega veb-sayt namunasi

Raqamli sertifikat sertifikatning ko'rsatilgan mavzusi tomonidan ochiq kalitga egalik huquqini tasdiqlaydi va ushbu kalitdan kutilgan foydalanishni bildiradi. Bu boshqalarga (ishonchli partiyalarga) imzolarga yoki tasdiqlangan ochiq kalitga mos keladigan yopiq kalit tomonidan berilgan tasdiqlarga tayanishga imkon beradi.

Sertifikat idoralari

TLS odatda sertifikatlarning haqiqiyligini aniqlash uchun ishonchli uchinchi tomon sertifikat organlari to'plamiga tayanadi. Ishonch odatda foydalanuvchi agenti dasturida tarqatilgan sertifikatlar ro'yxatiga o'rnatiladi,^[42] va ishonchli tomon tomonidan o'zgartirilishi mumkin.

Ga binoan Netcraft, faol TLS sertifikatlarini kuzatadigan, bozorda etakchi sertifikat markazi (CA) bo'ldi Symantec ularning so'rovi boshlanganidan beri (yoki VeriSign autentifikatsiya xizmatlari bo'limini Symantec sotib olmaguncha). 2015 yildan boshlab Symantec Netcraft tomonidan sanab o'tilgan eng ko'p band bo'lgan veb-saytlar tomonidan ishlatilgan sertifikatlarning uchdan bir qismiga va amaldagi sertifikatlarning 44 foiziga to'g'ri keldi.^[43] 2017 yilda Symantec o'zining TLS / SSL biznesini DigiCert-ga sotdi.^[44] Yangilangan hisobotda shunisi ko'rsatildi IdenTrust, DigiCert va Sektigo 2019 yil may oyidan buyon bozor ulushi bo'yicha eng yaxshi sertifikat organlari.^[45]

Tanlash natijasida X.509 sertifikatlar, sertifikat idoralari va ochiq kalitli infratuzilma sertifikat va uning egasi o'rtasidagi munosabatlarni tekshirish, shuningdek sertifikatlarni yaratish, imzolash va haqiqiyligini boshqarish uchun zarurdir. Bu identifikatorlarni a orqali tekshirishdan ko'ra qulayroq bo'lishi mumkin ishonchli veb, 2013 yilgi ommaviy kuzatuv ma'lumotlari sertifikat idoralari xavfsizlik nuqtai nazaridan zaif tomon ekanligi, bu esa imkon berishini yanada kengroq ma'lum qildi o'rtada odam hujumlari (MITM) agar sertifikat idorasi hamkorlik qilsa (yoki buzilgan bo'lsa).^[46][47]

Algoritmlar

Kalit almashinuvi yoki kalit kelishuvi

Mijoz va server TLS bilan himoyalangan ma'lumot almashishni boshlashdan oldin, ular ma'lumotlarni shifrlashda foydalanish uchun shifrlash kaliti va shifrni xavfsiz ravishda almashishi yoki kelishishi kerak (qarang. § shifr ). Kalit almashinuvi / kelishuvi uchun foydalaniladigan usullar qatoriga quyidagilar kiradi: ochiq va yopiq kalitlar RSA (TLS qo'l siqish protokolida TLS_RSA bilan ko'rsatilgan), Diffie-Hellman (TLS_DH), vaqtinchalik Diffie-Hellman (TLS_DHE), egri chiziqli Diffie-Hellman (TLS_ECDH), efemer elliptik egri chiziq Diffie-Hellman (TLS_ECDHE), noma'lum Diffie-Hellman (TLS_DH_anon),^[2] oldindan ulashilgan kalit (TLS_PSK)^[48] va Masofaviy parolni himoyalash (TLS_SRP).^[49]

TLS_DH_anon va TLS_ECDH_anon kalit kelishuv usullari server yoki foydalanuvchini tasdiqlay olmaydi va shuning uchun kamdan-kam hollarda qo'llaniladi, chunki ular zaifdir. o'rtada odam hujumlari. Faqat TLS_DHE va TLS_ECDHE taqdim etadi oldinga maxfiylik.

Almashish / kelishuv paytida ishlatiladigan ochiq kalit sertifikatlari, shuningdek, almashish paytida ishlatiladigan ochiq / xususiy shifrlash kalitlari hajmi va shuning uchun ta'minlangan xavfsizlikning mustahkamligi bilan farq qiladi. 2013 yil iyul oyida, Google endi 1024-bitli ochiq kalitlardan foydalanmasligini va o'z foydalanuvchilariga taqdim etadigan TLS shifrlash xavfsizligini oshirish uchun 2048-bitli kalitlarga o'tishini e'lon qildi, chunki shifrlash kuchi to'g'ridan-to'g'ri bog'liqdir kalit kattaligi.^[4][50]

Shifr

Izohlar

Ma'lumotlarning yaxlitligi

A xabarni tasdiqlash kodi (MAC) ma'lumotlar yaxlitligi uchun ishlatiladi. HMAC uchun ishlatiladi CBC blok shifrlari rejimi. Tasdiqlangan shifrlash (AEAD) kabi GCM rejimi va CCM rejimi AEAD-o'rnatilgan MAC-dan foydalanadi va ishlatmaydi HMAC.^[65] HMAC asosidagi PRF, yoki HKDF TLS bilan qo'l siqish uchun ishlatiladi.

Arizalar va qabul qilish

Ilovalarni loyihalashda TLS odatda Transport Layer protokollari ustida amalga oshiriladi va protokol bilan bog'liq barcha protokollarga oid ma'lumotlarni shifrlaydi. HTTP, FTP, SMTP, NNTP va XMPP.

Tarixiy jihatdan TLS birinchi navbatda ishonchli transport protokollari bilan ishlatilgan Transmissiyani boshqarish protokoli (TCP). Biroq, u shuningdek, masalan, diagrammalarga yo'naltirilgan transport protokollari bilan amalga oshirildi Foydalanuvchi Datagram protokoli (UDP) va Datagram tiqilinchini boshqarish protokoli (DCCP), bu atama yordamida mustaqil ravishda standartlashtirilgan Datagram transport qatlamining xavfsizligi (DTLS).

Veb-saytlar

TLS-dan asosiy foydalanish xavfsizlikni ta'minlashdir Butunjahon tarmog'i trafik orasidagi a veb-sayt va a veb-brauzer HTTP protokoli bilan kodlangan. HTTP trafigini ta'minlash uchun TLS-dan foydalanish HTTPS protokol.^[66]

Izohlar

Veb-brauzerlar

2016 yil aprel oyidan boshlab^[yangilash], barcha asosiy veb-brauzerlarning so'nggi versiyalari TLS 1.0, 1.1 va 1.2-ni qo'llab-quvvatlaydi va ularni sukut bo'yicha yoqadi. Biroq, hammasi ham qo'llab-quvvatlanmaydi Microsoft operatsion tizimlari IE ning so'nggi versiyasini qo'llab-quvvatlash. Bundan tashqari, hozirgi vaqtda ko'plab operatsion tizimlar IE ning bir nechta versiyasini qo'llab-quvvatlamoqda, ammo bu Microsoft-ga ko'ra o'zgargan Internet Explorer-ning umr aylanishiga oid siyosati bilan bog'liq savollar, "2016 yil 12-yanvardan boshlab, faqat Internet Explorer-ning qo'llab-quvvatlanadigan operatsion tizimi uchun mavjud bo'lgan eng so'nggi versiyasi texnik yordam va xavfsizlik yangilanishlarini oladi." Keyin sahifada har bir operatsion tizim uchun ushbu sanada IE-ning so'nggi qo'llab-quvvatlanadigan versiyasi keltirilgan. Keyingi muhim sana operatsion tizim umrining oxiriga yetganda bo'ladi, bu Microsoft-da Windows hayot davri haqidagi ma'lumot varaqasi.

Ma'lum bo'lgan hujumlarni yumshatish hali etarli emas:

• Qarshi yumshatishlar POODLE hujumi: ba'zi brauzerlar SSL 3.0-ga qaytishni oldini oladi; ammo, bu yumshatishni nafaqat mijozlar, balki serverlar ham qo'llab-quvvatlashi kerak. SSL 3.0 ning o'zini o'chirib qo'yish, "anti-POODLE yozuvlarini bo'linishini" amalga oshirish yoki SSL 3.0 da CBC shifrlarini rad etish talab qilinadi.
  • Google Chrome: to'liq (TLS_FALLBACK_SCSV 33-versiyadan boshlab amalga oshiriladi, SSL 3.0-ga qaytish 39-versiyadan o'chirilgan, SSL 3.0-ning o'zi 40-versiyadan boshlab o'chirilgan. SSL 3.0-ning o'zi 44-versiyadan beri o'chirilgan.)
  • Mozilla Firefox: to'liq (SSL 3.0-ning o'zi qo'llab-quvvatlanmaydi) 39-versiya. SSL 3.0 ning o'zi sukut bo'yicha o'chirib qo'yilgan va SSL 3.0 ga qaytish o'chirilgan versiya 34, TLS_FALLBACK_SCSV 35-versiyadan beri amalga oshirilmoqda. ESR-da SSL 3.0 ning o'zi sukut bo'yicha o'chirilgan va TLS_FALLBACK_SCSV ESR 31.3-dan beri qo'llaniladi.)
  • Internet Explorer: qisman (faqat 11-versiyada SSL 3.0 sukut bo'yicha 2015 yil aprel oyidan boshlab o'chirib qo'yilgan. 10 va undan yuqori versiyalar hali ham POODLE-ga qarshi himoyasiz.)
  • Opera: to'liq (TLS_FALLBACK_SCSV 20-versiyadan boshlab, faqat mijoz tomonidan amalga oshirilganda samarali bo'lgan "anti-POODLE yozuvlarni bo'linishi" 25-versiyadan boshlab amalga oshiriladi, SSL 3.0 ning o'zi 27-versiyadan boshlab sukut bo'yicha o'chirib qo'yilgan. SSL 3.0 ni o'zi qo'llab-quvvatlaydi 31-versiyadan boshlab o'chirib tashlanadi.)
  • Safari: to'liq (faqat OS X 10.8 va undan keyingi versiyalarida va iOS 8-da, SSL 3.0-ga qaytish paytida CBC shifrlari rad etiladi, ammo bu RC4-dan foydalanishni anglatadi, bu ham tavsiya etilmaydi. SSL 3.0-ning o'zi OS X-da o'chirilgan 10.11 va undan keyingi versiyalari va iOS 9.)
• Yumshatishga qarshi RC4 hujumlari:
  • Google Chrome RC4-ni o'chirib qo'ydi, faqat 43-versiyadan boshlab. RC4 Chrome 48-dan o'chirilgan.
  • Firefox RC4-ni o'chirib qo'ydi, faqat 36-versiyadan beri ishlamay qoldi. Firefox 44 standart ravishda RC4-ni o'chirib qo'ydi.
  • Opera RC4-ni o'chirib qo'ydi, faqat 30-versiyadan beri. RC4 Opera 35-dan o'chirilgan.
  • Uchun Internet Explorer Windows 7 / Server 2008 R2 va uchun Windows 8 / Server 2012 RC4-ning ustuvorligini eng past darajaga o'rnatdi va shuningdek RC4-ni o'chirib qo'yishi mumkin, bundan tashqari, ro'yxatga olish kitobi sozlamalari orqali nosozliklar bundan mustasno. Internet Explorer 11 Mobile 11 uchun Windows Phone 8.1 RC4-ni o'chirib qo'ying, agar boshqa yoqilgan algoritm ishlamasa. Edge va IE 11 RC4-ni 2016 yil avgust oyida butunlay o'chirib qo'yishadi.
• Yumshatishga qarshi Hujum hujumi:
  • Android brauzeri tarkibiga kiritilgan Android 4.0 va undan katta yoshi hali ham FREAK hujumiga qarshi himoyasiz.
  • Internet Explorer 11 Mobile hali ham FREAK hujumiga qarshi himoyasiz.
  • Google Chrome, Internet Explorer (ish stoli), Safari (ish stoli va mobil) va Opera (mobil) da FREAK yumshatilishlari mavjud.
  • Barcha platformalardagi Mozilla Firefox va Windows-dagi Google Chrome FREAK ta'sir qilmadi.

Izohlar

Kutubxonalar

SSL va TLS dasturlash kutubxonalarining aksariyati bepul va ochiq manbali dasturiy ta'minot.

• Zerikarli, Chrome / Chromium va Android hamda boshqa Google dasturlari uchun OpenSSL vilkasi.
• Botan, C ++ da yozilgan BSD litsenziyalangan kriptografik kutubxona.
• cryptlib: ko'chma ochiq kodli kriptografiya kutubxonasi (TLS / SSL dasturini o'z ichiga oladi)
• Delphi dasturchilar nomlangan kutubxonadan foydalanishlari mumkin Indy ishlatadigan OpenSSL yoki muqobil ravishda hozirda TLS 1.3 ni qo'llab-quvvatlovchi ICS.
• GnuTLS: bepul dastur (LGPL litsenziyalangan)
• Java Secure Socket kengaytmasi: a Java ga kiritilgan dastur Java ish vaqti muhiti Java 7-dan boshlab TLS 1.1 va 1.2-ni qo'llab-quvvatladi (TLS 1.1 / 1.2 dastlab Java 7-da mijoz uchun sukut bo'yicha o'chirib qo'yilgan, ammo 2017 yil yanvar oyida yoqilgan.^[197]) Java 11 TLS 1.3 ni qo'llab-quvvatlaydi.^[198]
• LibreSSL: OpenBSD loyihasining OpenSSL vilkasi.
• MatrixSSL: ikkita litsenziyali dastur
• mbed TLS (ilgari PolarSSL): O'rnatilgan qurilmalar uchun kichik SSL kutubxonasi, ulardan foydalanish qulayligi uchun mo'ljallangan
• Tarmoq xavfsizligi xizmatlari: FIPS 140 tasdiqlangan ochiq manbali kutubxona
• OpenSSL: bepul dastur (ba'zi kengaytmali BSD litsenziyasi)
• RSA BSAFE Micro Edition Suite: TLS-ning ko'p platformali dasturida yozilgan C FIPS tomonidan tasdiqlangan kriptografik moduldan foydalanish
• RSA BSAFE SSL-J: xususiy API va ham ta'minlovchi TLS kutubxonasi JSSE FIPS tomonidan tasdiqlangan kriptografik moduldan foydalangan holda API
• SChannel SSL va TLS dasturlarini amalga oshirish Microsoft Windows uning to'plamining bir qismi sifatida.
• Xavfsiz transport: ishlatiladigan SSL va TLS dasturlari OS X va iOS ularning paketlarining bir qismi sifatida.
• wolfSSL (ilgari CyaSSL): tezligi va hajmiga katta e'tibor qaratgan holda o'rnatilgan SSL / TLS kutubxonasi.

2012 yilda taqdim etilgan qog'oz ACM kompyuter va aloqa xavfsizligi bo'yicha konferentsiya^[224] ozgina dasturlar ushbu SSL kutubxonalaridan ba'zilaridan to'g'ri foydalanganliklarini ko'rsatdi va bu zaifliklarga olib keldi. Mualliflarning fikriga ko'ra

"ushbu zaifliklarning ko'pchiligining asosiy sababi API-larning asosiy SSL kutubxonalariga dahshatli dizayni bilan bog'liq. Ushbu tunnellarning maxfiylik va autentifikatsiya kabi yuqori darajadagi xavfsizlik xususiyatlarini ifoda etish o'rniga, ushbu API-lar SSL protokolining past darajadagi tafsilotlarini ochib beradi. Natijada dasturchilar ko'pincha SSL API-larini noto'g'ri ishlatishadi, ularning ko'p qirrali parametrlari, variantlari, yon ta'siri va qaytish qiymatlarini noto'g'ri talqin qilishadi va tushunmaydilar. "

Boshqa maqsadlar

The Oddiy pochta uzatish protokoli (SMTP) TLS bilan ham himoyalangan bo'lishi mumkin. Ushbu dasturlardan foydalaniladi ochiq kalit sertifikatlari so'nggi nuqtalarning identifikatorini tekshirish uchun.

TLS, shuningdek, a yaratish uchun butun tarmoq to'plamini tunnel qilish uchun ishlatilishi mumkin VPN, bu holat OpenVPN va OpenConnect. Hozirda ko'plab sotuvchilar TLS-ning shifrlash va autentifikatsiya qilish qobiliyatlarini avtorizatsiya bilan nikohga olishgan. 1990-yillarning oxiridan boshlab mijoz / server dasturlarini qo'llab-quvvatlashni ta'minlash uchun veb-brauzerlardan tashqarida mijozlar texnologiyasini yaratishda ham sezilarli o'zgarishlar ro'y berdi. An'anaviy bilan taqqoslaganda IPsec VPN texnologiyalari, TLS xavfsizlik devorida va ba'zi bir o'ziga xos afzalliklarga ega NAT masofadan boshqarish imkoniyatiga ega bo'lgan populyatsiyalar uchun boshqarishni osonlashtiradigan o'tish.

TLS shuningdek, himoya qilishning standart usuli hisoblanadi Sessiyani boshlash protokoli (SIP) dastur signalizatsiyasi. TLS bilan bog'liq bo'lgan SIP signalizatsiyasining autentifikatsiyasi va shifrlanishini ta'minlash uchun foydalanish mumkin VoIP va boshqa SIP-ga asoslangan dasturlar.^[225]

Xavfsizlik

SSL 2.0

SSL 2.0 turli xil xatolarga yo'l qo'ydi:^[226]

• Xuddi shu kriptografik kalitlardan foydalanilgan xabarni tasdiqlash va shifrlash. (SSL 3.0 da MAC sirlari shifrlash kalitlaridan kattaroq bo'lishi mumkin, shuning uchun xabarlar shifrlash kalitlari buzilgan taqdirda ham buzilishga chidamli bo'lib qolishi mumkin.^[5])
• SSL 2.0-da MD5 xash funktsiyasini maxfiy prefiks bilan ishlatadigan zaif MAC konstruktsiyasi mavjud edi uzunlikni kengaytirish hujumlari.
• SSL 2.0 qo'l siqish uchun hech qanday himoyaga ega emas edi, ya'ni o'rtada odam degan ma'noni anglatadi past darajadagi hujum aniqlanmasdan ketishi mumkin.
• SSL 2.0 ma'lumotlarning oxirini ko'rsatish uchun TCP ulanishini yaqin ishlatgan. Bu shuni anglatadiki, qisqartirish hujumlari mumkin edi: tajovuzkor shunchaki TCP FIN-kodini soxtalashtiradi va qabul qiluvchiga ma'lumotlarning noqonuniy oxiri to'g'risida bexabar qoldiradi (SSL 3.0 bu muammoni aniq yopilish to'g'risida ogohlantirish orqali hal qildi).
• SSL 2.0 bitta xizmatni va veb-serverlarda virtual xostingning standart xususiyati bilan to'qnashgan doimiy domen sertifikatini o'z zimmasiga oldi. Bu shuni anglatadiki, aksariyat veb-saytlar SSL-dan foydalanishda deyarli buzilgan.

SSL 2.0 sukut bo'yicha o'chirib qo'yildi Internet Explorer 7,^[227] Mozilla Firefox 2,^[228] Opera 9.5,^[229] va Safari. SSL 2.0-ni qo'llab-quvvatlash (va zaif) 40-bit va 56-bitli shifrlar) 10-versiyadan boshlab Opera-dan butunlay olib tashlandi.^[230][231]

SSL 3.0

SSL 3.0 SSL 2.0-ga SHA-1 asosidagi shifrlarni qo'shish va sertifikat autentifikatsiyasini qo'llab-quvvatlash orqali yaxshilandi.

Xavfsizlik nuqtai nazaridan SSL 3.0 TLS 1.0 ga qaraganda kamroq talab qilinadigan hisoblanadi. SSL 3.0 shifrlangan to'plamlari kalitlarni chiqarish jarayonini zaiflashtiradi; o'rnatilgan asosiy kalitning yarmi MD5 xash funktsiyasiga to'liq bog'liq, bu to'qnashuvlarga chidamli emas va shuning uchun xavfsiz deb hisoblanmaydi. TLS 1.0 ostida o'rnatiladigan asosiy kalit MD5 va SHA-1 ga bog'liq, shuning uchun hozirda uni chiqarish jarayoni zaif deb hisoblanmaydi. Shuning uchun SSL 3.0 dasturlarini FIPS 140-2 ostida tasdiqlash mumkin emas.^[232]

2014 yil oktyabr oyida SSL 3.0 dizaynidagi zaiflik haqida xabar berildi, shu bilan SSL 3.0 bilan ishlaydigan CBC rejimi to'ldirish hujumiga qarshi bo'lib qoldi (qarang #POODLE hujumi ).

TLS

TLS turli xil xavfsizlik choralariga ega:

• Protokolni oldingi (unchalik xavfsiz bo'lmagan) versiyaga yoki kuchsizroq shifrlangan to'plamga tushirilishidan himoya.
• Keyingi Ilova yozuvlarini tartib raqami bilan raqamlash va xabarni tasdiqlash kodlari (MAC).
• Kalit yordamida yaxshilangan xabarlar dayjestidan foydalanish (shuning uchun MAC-ni faqat kalit egasi tekshirishi mumkin). The HMAC ko'p TLS shifrli to'plamlari tomonidan ishlatiladigan qurilish RFC  2104 (SSL 3.0 boshqa xashga asoslangan MAC-dan foydalangan).
• Qo'l uzatishni tugatadigan xabar ("Tugatdi") ikkala tomon ko'rgan barcha qo'l almashish xabarlarining xashini yuboradi.
• The pseudorandom funktsiya kirish ma'lumotlarini ikkiga ajratadi va har birini har xil xeshlash algoritmi bilan ishlaydi (MD5 va SHA-1 ), keyin XOR ularni birgalikda MAC yaratish uchun. Ushbu algoritmlardan biri himoyasiz deb topilsa ham, bu himoyani ta'minlaydi.

TLS / SSL-ga qarshi hujumlar

TLS / SSL-ga qarshi muhim hujumlar quyida keltirilgan.

2015 yil fevral oyida IETF axborot RFMini chiqardi^[233] TLS / SSL-ga qarshi ma'lum bo'lgan turli xil hujumlarni sarhisob qilish.

Qayta muzokaralar hujumi

2009 yil avgust oyida qayta muzokaralar protsedurasining zaifligi aniqlandi, bu SSL 3.0 va TLSning barcha mavjud versiyalariga qarshi ochiq matnli in'ektsiya hujumlariga olib kelishi mumkin.^[234] Masalan, bu https ulanishini o'g'irlashi mumkin bo'lgan tajovuzkorga mijozning veb-server bilan suhbatining boshida o'z so'rovlarini qo'shishiga imkon beradi. Tajovuzkor aslida mijoz-server aloqasini parolini hal qila olmaydi, shuning uchun bu odatdagi o'rtadagi hujumdan farq qiladi. Qisqa muddatli tuzatish, veb-serverlar qayta muzokaralarga ruxsat berishni to'xtatishi kerak, agar ular bundan mustasno bo'lsa, odatda boshqa o'zgarishlarni talab qilmaydi mijoz sertifikati autentifikatsiya ishlatiladi. Xavfsizlikni bartaraf etish uchun TLS uchun qayta muzokara ko'rsatmalarini kengaytirish taklif qilindi. Bu mijoz va serverdan har qanday qayta kelishilgan qo'l siqishlariga avvalgi qo'l uzatishlar haqidagi ma'lumotlarni kiritishi va tekshirishini talab qiladi.^[235] Ushbu kengaytma taklif qilingan standartga aylandi va unga raqam berildi RFC  5746. RFC bir nechta kutubxonalar tomonidan amalga oshirildi.^{[236][237][238]}

Past darajadagi hujumlar: FREAK hujumi va Logjam hujumi

Protokol past darajadagi hujum (shuningdek, versiya orqaga qaytish hujumi deb ataladi) veb-serverni aldab, TLS-ning oldingi versiyalari (masalan, SSLv2) bilan aloqalarni muzokaralar olib borish uchun allaqachon xavfli deb qoldirilgan.

Kabi asl protokollarga avvalgi o'zgartirishlar Soxta boshlash^[239] (Google Chrome tomonidan qabul qilingan va yoqilgan^[240]) yoki Snap Start, xabar berilganidek, cheklangan TLS protokoli pasaytirish xujumlari^[241] yoki mijoz tomonidan serverga yuborilgan shifrlar to'plami ro'yxatiga ruxsat berilgan o'zgartirishlar. Bunda tajovuzkor zaif simmetrik shifrlash algoritmi yoki kuchsiz kalit almashinuvidan foydalanish uchun muzokara olib borgan shifr to'plamini pasaytirishga urinib, shifr to'plamini tanlashga ta'sir ko'rsatishi mumkin.^[242] Da taqdim etilgan qog'oz ACM kompyuter va aloqa xavfsizligi bo'yicha konferentsiya 2012 yilda False Start kengaytmasi xavf ostida ekanligini namoyish etdi: ba'zi hollarda bu tajovuzkorga shifrlash kalitlarini oflayn rejimda tiklashi va shifrlangan ma'lumotlarga kirishiga imkon berishi mumkin.^[243]

Shifrlashni pasaytirish xujumlari serverlar va mijozlarni kriptografik jihatdan zaif tugmachalar yordamida ulanish to'g'risida muzokaralar olib borishga majbur qilishi mumkin. 2014 yilda, a o'rtada odam ta'sir ko'rsatadigan hujum deb topildi OpenSSL stack, sukut bo'yicha Android veb-brauzer va boshqalar Safari brauzerlar.^[244] Hujum serverlarni aldab, kriptografik jihatdan kuchsiz 512 bitli shifrlash kalitlari yordamida TLS ulanish to'g'risida muzokara olib bordi.

Logjam a xavfsizlik ekspluatatsiyasi merosdan foydalanish imkoniyatidan foydalanadigan 2015 yil may oyida topilgan "eksport darajasida" 512-bit Diffie-Hellman 1990 yillarga tegishli guruhlar.^[245] Bu sezgir serverlarni kriptografik jihatdan kuchsiz 512 bitli Diffie-Hellman guruhlariga tushirishga majbur qiladi. Shunda tajovuzkor mijoz va server tomonidan aniqlangan kalitlarni chiqarib tashlashi mumkin Diffie-Hellman kalit almashinuvi.

Protokollararo hujumlar: DROWN

The DOWN hujum zamonaviy SSL / TLS protokoli to'plamlarini qo'llab-quvvatlovchi serverlarga eskirgan, xavfli, SSLv2 protokolini qo'llab-quvvatlashidan foydalangan holda, zamonaviy protokollardan foydalangan holda, ulanishlarga hujum qilish uchun hujum qiladigan ekspluatatsiya.^[246][247] DROWN har qanday aniq dastur xatolaridan ko'ra foydalanilgan protokollarda va server konfiguratsiyasida zaiflikdan foydalanadi. DROWN-ning to'liq tafsilotlari 2016 yil mart oyida ekspluatatsiya uchun tuzatish bilan birga e'lon qilindi. O'sha paytda, eng mashhur 1 million veb-saytlarning 81000 dan ortig'i DROWN hujumiga qarshi bo'lgan TLS bilan himoyalangan veb-saytlar orasida edi.^[247]

HAYVON hujumi

2011 yil 23 sentyabrda tadqiqotchilar Tay Duong va Juliano Rizzo ushbu kontseptsiyaning isbotini namoyish etdilar HAYVON (SSL / TLS-ga qarshi brauzer ekspluatatsiyasi)^[248] yordamida Java ilovasi buzmoq bir xil kelib chiqish siyosati uzoq vaqtdan beri ma'lum bo'lgan cheklovlar shifr bloklarini zanjirlash TLS 1.0 da (CBC) zaiflik:^[249][250] ketma-ket ikkita C0, C1 shifrlangan matn bloklarini kuzatayotgan tajovuzkor keyingi P2 = x ochiq matnli blokni tanlab, P1 tekis matn bloki x ga tengligini tekshirishi mumkin. ${ displaystyle oplus}$ C0 ${ displaystyle oplus}$ C1; CBC operatsiyasiga ko'ra, C2 = E (C1 ${ displaystyle oplus}$ P2) = E (C1 ${ displaystyle oplus}$ x ${ displaystyle oplus}$ C0 ${ displaystyle oplus}$ C1) = E (C0 ${ displaystyle oplus}$ x), agar u x = P1 bo'lsa, u C1 ga teng bo'ladi. Amaliy ekspluatatsiya Buning uchun ilgari namoyish qilinmagan edi zaiflik, dastlab tomonidan kashf etilgan Fillip Rogavey^[251] 2002 yilda. Hujumning zaifligi 2006 yilda TLS 1.1 bilan tuzatilgan edi, ammo TLS 1.1 ushbu hujum namoyishidan oldin keng qabul qilinmagan edi.

RC4 oqim shifrlari sifatida BEAST hujumiga qarshi immunitet mavjud. Shuning uchun, RC4 server tomonidagi BEAST hujumini yumshatish usuli sifatida keng qo'llanilgan. Biroq, 2013 yilda tadqiqotchilar RC4-da ko'proq zaif tomonlarni topdilar. Shundan so'ng server tomonida RC4-ni yoqish endi tavsiya etilmaydi.^[252]

Chrome va Firefox-larning o'zi BEAST hujumiga qarshi emas,^[79][99] ammo, Mozilla ularning yangilangan NSS BEAST-ga o'xshash yumshatish uchun kutubxonalar hujumlar. NSS tomonidan ishlatiladi Mozilla Firefox va Gugl xrom SSL-ni amalga oshirish uchun. Biroz veb-serverlar SSL spetsifikatsiyasining buzilgan dasturiga ega bo'lganligi natijasida ishlamay qolishi mumkin.^[253]

Microsoft 2012 yil 10-yanvar kuni MS12-006 xavfsizlik byulleteni chiqarildi, u Windows Secure Channel (SChannel ) komponent serverning oxiridan shifrlangan tarmoq paketlarini uzatadi.^[254] Windows-ning eski versiyalarida ishlaydigan Internet Explorer (11-versiyadan oldin) foydalanuvchilari (Windows 7, Windows 8 va Windows Server 2008 R2 ) TLS-dan foydalanishni 1.1 yoki undan yuqori darajaga cheklashi mumkin.

olma 1 / n-1 splitni amalga oshirish va uni sukut bo'yicha yoqish orqali BEASTning zaifligini aniqladi OS X Mavericks, 2013 yil 22 oktyabrda chiqarilgan.^[255]

Jinoyat va BREACH hujumlari

HAYVON hujumining mualliflari ham keyinchalik yaratuvchilardir JINO hujumi, bu tajovuzkorga qachon veb-cookies-lar tarkibini tiklashga imkon berishi mumkin ma'lumotlarni siqish TLS bilan birga ishlatiladi.^[256][257] Sirning tarkibini tiklash uchun foydalanilganda autentifikatsiya kukilari, bu tajovuzkorning bajarishiga imkon beradi sessiyani o'g'irlash tasdiqlangan veb-sessiyada.

CRIME hujumi ko'plab hujumlar, shu jumladan TLS bilan cheklanmagan protokollarga va dastur qatlami kabi protokollarga qarshi samarali ishlashi mumkin bo'lgan umumiy hujum sifatida taqdim etilgan. SPDY yoki HTTP, faqat TLS va SPDYga qarshi ekspluatatsiya ko'rsatildi va brauzer va serverlarda asosan engillashtirildi. JINOAT ekspluatatsiyasi HTTP kompressiyasi CRIME mualliflari ushbu zaiflik SPDY va TLS siqilishidan ham kengroq bo'lishi mumkinligi haqida ogohlantirgan bo'lishiga qaramay, umuman yumshatilmagan. 2013 yilda HTTP siqilishiga qarshi yangi jinoyat hujumi, dublyaj qilingan Buzilish, e'lon qilindi. JINOYaT hujumiga asoslanib, BREACH hujumi tajovuzkor jabrlanuvchini aldash sharti bilan 30 soniya ichida (ajratiladigan baytlar soniga qarab) TLS shifrlangan veb-trafikdan kirish ma'lumotlarini, elektron pochta manzillarini yoki boshqa maxfiy ma'lumotlarni olib qo'yishi mumkin. zararli veb-havola yoki foydalanuvchi tashrif buyurgan haqiqiy sahifalarga tarkibni kiritishi mumkin (masalan: tajovuzkor nazorati ostida simsiz tarmoq).^[258] TLS va SSL-ning barcha versiyalari ishlatilgan shifrlash algoritmi yoki shifridan qat'i nazar, BREACH tomonidan xavf ostida.^[259] TLS siqishni yoki SPDY sarlavhasini siqishni o'chirish orqali muvaffaqiyatli himoya qilinishi mumkin bo'lgan oldingi CRIME misollaridan farqli o'laroq, BREACH HTTP kompressiyasidan foydalanadi, uni o'chirib bo'lmaydi, chunki deyarli barcha veb-serverlar foydalanuvchilarga ma'lumot uzatish tezligini yaxshilashga ishonadilar.^[258] Bu TLSning ma'lum cheklovi, chunki u sezgir ochiq matnli hujum himoya qilish uchun mo'ljallangan dastur qatlami ma'lumotlariga qarshi.

To'ldirishda vaqtni hujum qilish

Avvalgi TLS versiyalari to'ldirish oracle hujumi 2002 yilda kashf etilgan. The ning yangi varianti Baxtli o'n uchta hujum, 2013 yilda nashr etilgan.

Ba'zi ekspertlar^[62] shuningdek oldini olish tavsiya etiladi Uch karra CBC. So'nggi qo'llab-quvvatlanadigan shifrlar har qanday dasturni qo'llab-quvvatlash uchun ishlab chiqilganidan beri Windows XP Windows XP-da Internet Explorer kabi SSL / TLS kutubxonasi mavjud RC4 va Triple-DES, va endi RC4 eskirgan (muhokamaga qarang RC4 hujumlari ), bu XP-da ushbu kutubxonadan foydalangan holda biron bir dastur uchun SSL versiyasini qo'llab-quvvatlashni qiyinlashtiradi.

Sifatida chiqarilgan TLS spetsifikatsiyasiga Encrypt-then-MAC kengaytmasi sifatida tuzatish chiqarildi RFC  7366.^[260] Lucky Thirteen hujumini faqat AES_GCM shifrlari yordamida TLS 1.2 da yumshatish mumkin; AES_CBC himoyasiz bo'lib qolmoqda.^{[iqtibos kerak ]}

POODLE hujumi

2014 yil 14 oktyabrda Google tadqiqotchilari SSL 3.0 dizaynidagi zaiflikni e'lon qilishdi CBC ish tartibi SSL 3.0 bilan himoyasiz to'ldirish hujumi (CVE -2014-3566 ). Ular ushbu hujumni nomlashdi PODLE (Oracle-ning pastki darajadagi eski shifrlashda to'ldirilishi). Shifrlangan xabarlarning bir baytini ochish uchun tajovuzkorlar o'rtacha 256 SSL 3.0 so'rovlarini yuborishlari kerak.^[69]

Ushbu zaiflik faqat SSL 3.0-da mavjud bo'lsa-da va aksariyat mijozlar va serverlar TLS 1.0 va undan yuqori versiyasini qo'llab-quvvatlasa ham, agar foydalanuvchi yoki administrator uchun SSL 3.0-ni o'chirib qo'yish imkoniyati berilmagan bo'lsa, barcha yirik brauzerlar o'zlarining ixtiyorlari bilan SSL 3.0-ga tushiradilar. va foydalanuvchi yoki administrator buni amalga oshiradi^{[iqtibos kerak ]}. Shuning uchun, o'rtada odam avval a ni o'tkazishi mumkin versiyani qaytarib olish hujumi va keyin bu zaiflikdan foydalaning.^[69]

Umuman olganda, o'zaro muvofiqlik uchun xavfsizlikni oqilona degradatsiyasidan foydalanib bo'lmaydigan tarzda amalga oshirish qiyin. Bu, ayniqsa parchalanish yuqori bo'lgan domenlarda juda qiyin.^[261]

2014 yil 8-dekabrda POODLE-ning to'ldirish baytlari talablarini to'g'ri bajarmaydigan TLS dasturlariga ta'sir ko'rsatadigan varianti e'lon qilindi.^[262]

RC4 hujumlari

Hujumlarning mavjudligiga qaramay RC4 uning xavfsizligini buzgan holda, RC4 asosida yaratilgan SSL va TLS-dagi shifrlangan to'plamlar SSL va TLS-da ishlatilish uslubiga qarab 2013 yilgacha xavfsiz hisoblanadi. 2011 yilda RC4 to'plami aslida atrofida ishlash sifatida tavsiya etilgan HAYVON hujum.^[263] 2013 yil mart oyida ochilgan hujumning yangi shakllari RC4 ni TLSda sindirish maqsadga muvofiqligini aniq ko'rsatib berdi, bu uning BEAST uchun yaxshi echim emasligini ko'rsatdi.^[68] AlFardan, Bernshteyn, Paterson, Poettering va Shuldt tomonidan hujum stsenariysi taklif qilingan, ular RC4 kalit jadvalida yangi kashf etilgan statistik tarafkashliklardan foydalanganlar.^[264] ko'p sonli TLS shifrlash bilan oddiy matn qismlarini tiklash.^[265][266] 13 × 2 talab qiladigan TLS va SSL-da RC4-ga hujum²⁰ RC4-ni sindirish uchun shifrlash 2013 yil 8-iyulda ochilgan va keyinroq taqdimotda "mumkin" deb ta'riflangan USENIX Xavfsizlik simpoziumi 2013 yil avgustda.^[267][268] 2015 yil iyul oyida hujumning keyingi yaxshilanishi RC4-shifrlangan TLS xavfsizligini engib chiqishni tobora amaliylashtirmoqda.^[269]

Ko'pgina zamonaviy brauzerlar BEAST hujumlarini engish uchun ishlab chiqilgan (Mac OS X 10.7 yoki undan oldingi versiyalar, iOS 6 yoki undan oldingi versiyalar va Windows uchun Safari bundan mustasno; qarang § veb-brauzerlar ), RC4 endi TLS 1.0 uchun yaxshi tanlov emas. O'tmishda BEAST hujumidan ta'sirlangan CBC shifrlari himoya qilishning eng mashhur tanloviga aylandi.^[62] Mozilla va Microsoft, iloji bo'lsa, RC4-ni o'chirishni tavsiya qiladi.^[270][271] RFC  7465 TLS ning barcha versiyalarida RC4 shifrlangan to'plamlaridan foydalanishni taqiqlaydi.

2015 yil 1 sentyabrda Microsoft, Google va Mozilla o'zlarining brauzerlarida RC4 shifrlangan to'plamlari sukut bo'yicha o'chirib qo'yilishini e'lon qilishdi (Microsoft Edge, Internet Explorer 11 Windows 7 / 8.1 / 10 da, Firefox va Chrome ) 2016 yil boshida.^{[272][273][274]}

Qisqartirish hujumi

TLS (tizimdan chiqib ketish) hujumi jabrlanuvchining hisob qaydnomasidan chiqish so'rovlarini bloklaydi, shunda foydalanuvchi bilmagan holda veb-xizmatga kiraveradi. Chiqish to'g'risidagi so'rov yuborilganda, tajovuzkor shifrlanmagan holda ukol qiladi TCP Ulanishni yopish uchun FIN-xabar (jo'natuvchidan boshqa ma'lumot yo'q). Shuning uchun server tizimdan chiqish talabini qabul qilmaydi va g'ayritabiiy tugatish haqida bilmaydi.^[275]

2013 yil iyulda nashr etilgan,^[276][277] hujumi kabi veb-xizmatlarni keltirib chiqaradi Gmail va Hotmail foydalanuvchini brauzerga keyingi kirish huquqiga ega bo'lgan tajovuzkorga kirish va kirish huquqini o'z nazoratiga olishiga imkon berib, foydalanuvchi brauzerining ushbu xizmat bilan avtorizatsiyani saqlab turishini ta'minlagan holda, foydalanuvchini tizimdan muvaffaqiyatli chiqib ketganligi to'g'risida xabardor qiladigan sahifani ko'rsatish. . Hujum jabrlanuvchining kompyuteriga zararli dasturlarni o'rnatishga ishonmaydi; tajovuzkorlar faqat o'zlarini jabrlanuvchi va veb-server o'rtasida joylashtirishlari kerak (masalan, firibgar simsiz ulanish nuqtasini o'rnatish orqali).^[275] Ushbu zaiflik jabrlanuvchining kompyuteriga kirishni talab qiladi, yana bir imkoniyat - FTP-dan foydalanish paytida ma'lumotlar ulanishida ma'lumotlar oqimida noto'g'ri FIN bo'lishi mumkin va agar ogohlantirishlarni almashtirish protokoli qoidalariga rioya qilinmasa, faylni qisqartirish mumkin.

Muqaddas bo'lmagan PAC hujumi

2016 yil o'rtalarida topilgan ushbu hujum, zaif tomonlaridan foydalanmoqda Veb-proksi-serverni avtomatik kashf qilish protokoli (WPAD) veb-foydalanuvchi TLS-ga ulangan veb-havola orqali kirishga urinayotgan URL manzilini ochish uchun.^[278] URLni oshkor qilish nafaqat veb-saytga kirganligi sababli, balki ba'zida foydalanuvchilarning haqiqiyligini tekshirish uchun URL manzillaridan foydalanilganligi sababli ham foydalanuvchining shaxsiy hayotini buzishi mumkin. Hujjatlarni almashish xizmatlari, masalan, Google va Dropbox, shuningdek, foydalanuvchiga URL-ga kiritilgan xavfsizlik belgisini yuborish orqali ishlaydi. Bunday URL-larga ega bo'lgan tajovuzkor jabrlanuvchining hisobi yoki ma'lumotlariga to'liq kirish huquqiga ega bo'lishi mumkin.

Ekspluatatsiya deyarli barcha brauzerlar va operatsion tizimlarga qarshi ishlaydi.

Sweet32 hujumi

Sweet32 hujumi CBC rejimida ishlatiladigan TLS-da ishlatilgan barcha 64-bitli blok shifrlarni tug'ilgan kungi hujum va a o'rtada hujum yoki zararli moddalarni kiritish JavaScript veb-sahifaga. O'rtada odam hujumi yoki JavaScript in'ektsiyasining maqsadi tajovuzkorga tug'ilgan kungi hujumni o'rnatish uchun etarli miqdordagi trafikni olishiga imkon berishdir.^[279]

Amalga oshirishda xatolar: Heartbleed bug, BERserk hujumi, Cloudflare xatosi

The Yurak qoni bug - bu mashhur SSL / TLS dasturiga xos bo'lgan jiddiy zaiflik OpenSSL 1.0.1 dan 1.0.1f versiyalariga ta'sir qiluvchi kriptografik dasturiy ta'minot. 2014 yil aprel oyida xabar qilingan ushbu zaiflik tajovuzkorlarga o'g'irlashga imkon beradi shaxsiy kalitlar odatda himoyalangan bo'lishi kerak bo'lgan serverlardan.^[280] Heartbleed xatosi Internetdagi har qanday kishiga OpenSSL dasturining himoyasiz versiyalari bilan himoyalangan tizimlarning xotirasini o'qish imkoniyatini beradi. Bu bilan bog'liq bo'lgan maxfiy shaxsiy kalitlarni buzadi jamoat guvohnomalari xizmat ko'rsatuvchi provayderlarni aniqlash va trafikni, foydalanuvchilarning ismlari va parollarini va haqiqiy tarkibni shifrlash uchun ishlatiladi. Bu tajovuzkorlarga aloqa vositalarini tinglash, xizmatlar va foydalanuvchilarning ma'lumotlarini to'g'ridan-to'g'ri o'g'irlash va xizmatlar va foydalanuvchilarga taqlid qilish imkoniyatini beradi.^[281] Zaiflik a bufer ortiqcha o'qilgan SSL yoki TLS protokoli spetsifikatsiyasidagi nuqson o'rniga OpenSSL dasturidagi xato.

2014 yil sentyabr oyida Daniel Bleyxenbaxerniki PKCS # 1 v1.5 RSA Signature Forgery zaifligi^[282] Intel Security Advanced Threat Research tomonidan e'lon qilindi. "BERserk" deb nomlangan ushbu hujum, ba'zi SSL dasturlarida ochiq kalit imzolarining to'liq bo'lmagan ASN.1 uzunlikdagi dekodlanishining natijasidir va ochiq kalit imzosini soxtalashtirib, o'rtada odam hujum qilishga imkon beradi.^[283]

2015 yil fevral oyida ommaviy axborot vositalari yashirin oldindan o'rnatish haqida xabar berganlaridan keyin Superfish ba'zi Lenovo noutbuklarida reklama dasturlari,^[284] tadqiqotchi ta'sirlangan Lenovo mashinalarida ishonchli ildiz sertifikatini xavfli deb topdi, chunki kalitlarga firma nomi Komodia yordamida parol sifatida osongina kirish mumkin edi.^[285] Komodia kutubxonasi ota-ona nazorati va kuzatuvi uchun mijozlar tomonidan TLS / SSL trafigini to'xtatish uchun ishlab chiqilgan, ammo u ko'plab reklama dasturlarida, shu jumladan Superfish-da ishlatilgan, ko'pincha kompyuter foydalanuvchisi bilmagan holda yashirin ravishda o'rnatilgan. O'z navbatida, bular mumkin bo'lmagan kiruvchi dasturlar buzilgan ildiz sertifikatini o'rnatdi, bu tajovuzkorlarga veb-trafikni to'liq boshqarish va yolg'on veb-saytlarni haqiqiyligini tasdiqlash imkonini beradi.

2016 yil may oyida Daniyaning HTTPS tomonidan himoyalangan o'nlab veb-saytlariga tegishli ekanligi haqida xabar berilgan edi Visa Inc. xakerlarga zararli kod va qalbaki tarkibni tashrif buyuruvchilarning brauzerlariga kiritishga imkon beradigan hujumlarga qarshi himoyasiz edi.^[286] Hujumlar ta'sir ko'rsatgan serverlarda ishlatilgan TLS dasturi tasodifiy raqamlarni noto'g'ri qayta ishlatganligi sababli ishladi (nonces ) faqat bir marta ishlatilishini nazarda tutgan holda, ularning har birini ta'minlash TLS bilan qo'l siqish noyobdir.^[286]

2017 yil fevral oyida HTMLni ajratish uchun foydalanilgan koddagi bitta noto'g'ri yozilgan belgidan kelib chiqqan holda amalga oshirishda xatolik buferni to'ldirish xatosini yaratdi Cloudflare serverlar. Ta'siri jihatidan 2014 yilda kashf qilingan Heartbleed xatosiga o'xshash, bu haddan tashqari xato, keng tarqalgan Bulutli qon, ruxsatsiz uchinchi shaxslarga serverlarda ishlaydigan dasturlarning xotirasidagi ma'lumotlarni o'qishga ruxsat bergan - bular TLS bilan himoyalangan bo'lishi kerak bo'lgan ma'lumotlar.^[287]

Hujumlarga qarshi zaif veb-saytlarni o'rganish

2019 yil avgust holatiga ko'ra^[yangilash], Ishonchli Internet Harakati, TLS hujumlari ta'siriga tushadigan veb-saytlarning nisbatini taxmin qildi.^[67]

Oldinga sir

Oldinga sir kriptografik tizimlarning xususiyati bo'lib, u ochiq va yopiq kalitlar to'plamidan olingan sessiya kaliti kelajakda yopiq kalitlardan biri buzilgan taqdirda buzilmasligini ta'minlaydi.^[288] Oldindan maxfiyliksiz, agar serverning shaxsiy kaliti buzilgan bo'lsa, ushbu server sertifikatidan foydalangan holda kelajakdagi barcha TLS-shifrlangan seanslari emas, balki uni ishlatgan har qanday o'tgan sessiyalar ham buziladi (albatta, ushbu o'tgan sessiyalar ushlangan va saqlangan) uzatish vaqtida).^[289] TLSni amalga oshirish, efemerdan foydalanishni talab qilib, maxfiylikni ta'minlashi mumkin Diffie-Hellman kalit almashinuvi sessiya kalitlarini o'rnatish uchun va ba'zi bir e'tiborga molik TLS dasturlari faqat shunday qiladi: masalan, Gmail va foydalanadigan boshqa Google HTTPS xizmatlari OpenSSL.^[290] Biroq, TLS-ni qo'llab-quvvatlaydigan ko'plab mijozlar va serverlar (shu jumladan brauzerlar va veb-serverlar) bunday cheklovlarni amalga oshirish uchun tuzilmagan.^[291][292] Amalda, agar veb-xizmat Diffie-Hellman kalit almashinuvini to'g'ridan-to'g'ri maxfiylikni amalga oshirish uchun ishlatmasa, ushbu xizmatga va undan olingan barcha shifrlangan veb-trafik uchinchi tomon tomonidan ochilishi mumkin, agar u serverning asosiy (shaxsiy) kalitini olsa; masalan, sud qarori bilan.^[293]

Diffie-Hellman kalit almashinuvi amalga oshirilgan joyda ham server tomonida sessiyalarni boshqarish mexanizmlari kelajakdagi maxfiylikka ta'sir qilishi mumkin. Dan foydalanish TLS sessiyasi chiptalari (a TLS kengaytmasi) sessiyaning AES128-CBC-SHA256 tomonidan boshqa har qanday kelishilgan TLS parametrlaridan qat'i nazar, himoya qilinishiga olib keladi, shu jumladan maxfiylik shifrlari va uzoq umr ko'rgan TLS seans chiptalari kalitlari oldinga sirni amalga oshirish urinishlarini mag'lub etadi.^{[294][295][296]} Stenford Universitetining 2014 yildagi tadqiqotlari shuni ko'rsatdiki, so'rovda qatnashgan 473.802 TLS serverlarning 82.9% vaqtinchalik maxfiylikni qo'llab-quvvatlash uchun vaqtinchalik Diffie-Hellman (DHE) kalit almashinuvini joylashtirgan Diffie-Hellman parametrlari zaif. Ushbu zaif parametr tanlovi serverlar taqdim etishni istagan oldingi maxfiylik samaradorligini buzishi mumkin.^[297]

2011 yil oxiridan boshlab Google o'z foydalanuvchilariga sukut bo'yicha TLS bilan maxfiylikni taqdim etdi Gmail xizmat, shu bilan birga Google Docs va boshqa xizmatlar qatorida shifrlangan qidiruv.^[298]2013 yil noyabr oyidan boshlab, Twitter o'z xizmatidan foydalanuvchilarga TLS bilan maxfiylikni taqdim etdi.^[299] 2019 yil avgust holatiga ko'ra^[yangilash], about 80% of TLS-enabled websites are configured to use cipher suites that provide forward secrecy to most web browsers.^[67]

TLSni ushlab qolish

TLS interception (or HTTPS interception if applied particularly to that protocol) is the practice of intercepting an encrypted data stream in order to decrypt it, read and possibly manipulate it, and then re-encrypt it and send the data on its way again. This is done by way of a "transparent proxy ": the interception software terminates the incoming TLS connection, inspects the HTTP plaintext, and then creates a new TLS connection to the destination.^[300]

TLS / HTTPS interception is used as an axborot xavfsizligi measure by network operators in order to be able to scan for and protect against the intrusion of malicious content into the network, such as kompyuter viruslari va boshqalar zararli dastur.^[300] Such content could otherwise not be detected as long as it is protected by encryption, which is increasingly the case as a result of the routine use of HTTPS and other secure protocols.

A significant drawback of TLS / HTTPS interception is that it introduces new security risks of its own. Because it provides a point where network traffic is available unencrypted, attackers have an incentive to attack this point in particular in order to gain access to otherwise secure content. The interception also allows the network operator, or persons who gain access to its interception system, to perform o'rtada odam hujumlari against network users. A 2017 study found that "HTTPS interception has become startlingly widespread, and that interception products as a class have a dramatically negative impact on connection security".^[300]

Protokol tafsilotlari

The TLS protocol exchanges yozuvlar, which encapsulate the data to be exchanged in a specific format (see below). Each record can be compressed, padded, appended with a xabarni tasdiqlash kodi (MAC), or encrypted, all depending on the state of the connection. Each record has a tarkib turi field that designates the type of data encapsulated, a length field and a TLS version field. The data encapsulated may be control or procedural messages of the TLS itself, or simply the application data needed to be transferred by TLS. The specifications (cipher suite, keys etc.) required to exchange application data by TLS, are agreed upon in the "TLS handshake" between the client requesting the data and the server responding to requests. The protocol therefore defines both the structure of payloads transferred in TLS and the procedure to establish and monitor the transfer.

TLS bilan qo'l siqish

When the connection starts, the record encapsulates a "control" protocol – the handshake messaging protocol (tarkib turi 22). This protocol is used to exchange all the information required by both sides for the exchange of the actual application data by TLS. It defines the format of messages and the order of their exchange. These may vary according to the demands of the client and server – i.e., there are several possible procedures to set up the connection. This initial exchange results in a successful TLS connection (both parties ready to transfer application data with TLS) or an alert message (as specified below).

Asosiy TLS qo'l siqish

A typical connection example follows, illustrating a qo'l siqish where the server (but not the client) is authenticated by its certificate:

1. Negotiation phase:
   • A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested shifrlangan suitlar and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID. If the client can use Ilova-qatlam protokoli bo'yicha muzokaralar, it may include a list of supported application protokollar, kabi HTTP / 2.
   • The server responds with a Server salom message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a session ID. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS version 1.1 and the server supports version 1.2, version 1.1 should be selected; version 1.2 should not be selected.
   • The server sends its Sertifikat message (depending on the selected cipher suite, this may be omitted by the server).^[301]
   • The server sends its ServerKeyExchange message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE, ECDHE and DH_anon cipher suites.^[2]
   • The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
   • The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
   • The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data (sessiya tugmachalari kabi IV, nosimmetrik shifrlash kalit, MAC kalit^[302]) for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom funktsiya.
2. The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record-level protocol with content type of 20.
   • The client sends an authenticated and encrypted Tugadi message, containing a hash and MAC over the previous handshake messages.
   • The server will attempt to decrypt the client's Tugadi message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)."
   • The server sends its authenticated and encrypted Tugadi xabar.
   • The client performs the same decryption and verification procedure as the server did in the previous step.
4. Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be authenticated and optionally encrypted exactly like in their Tugadi xabar. Otherwise, the content type will return 25 and the client will not authenticate.

Mijoz tomonidan tasdiqlangan TLS qo'l siqish

Quyidagi to'liq example shows a client being authenticated (in addition to the server as in the example above) via TLS using certificates exchanged between both peers.

1. Negotiation Phase:
   • A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.
   • The server responds with a Server salom message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. The server may also send a session id as part of the message to perform a resumed handshake.
   • The server sends its Sertifikat message (depending on the selected cipher suite, this may be omitted by the server).^[301]
   • The server sends its ServerKeyExchange message (depending on the selected cipher suite, this may be omitted by the server). This message is sent for all DHE, ECDHE and DH_anon ciphersuites.^[2]
   • The server sends a CertificateRequest message, to request a certificate from the client so that the connection can be mutually authenticated.
   • The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
   • The client responds with a Sertifikat message, which contains the client's certificate.
   • The client sends a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
   • The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.
   • The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data ("session keys") for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.
2. The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated). " The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
   • Finally, the client sends an encrypted Tugadi message, containing a hash and MAC over the previous handshake messages.
   • The server will attempt to decrypt the client's Tugadi message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted if encryption was negotiated). "
   • The server sends its own encrypted Tugadi xabar.
   • The client performs the same decryption and verification procedure as the server did in the previous step.
4. Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their Tugadi xabar.

TLS bilan qo'l siqish qayta tiklandi

Public key operations (e.g., RSA) are relatively expensive in terms of computational power. TLS provides a secure shortcut in the handshake mechanism to avoid these operations: resumed sessions. Resumed sessions are implemented using session IDs or session tickets.

Apart from the performance benefit, resumed sessions can also be used for bitta tizimga kirish, as it guarantees that both the original session and any resumed session originate from the same client. This is of particular importance for the FTP over TLS/SSL protocol, which would otherwise suffer from a man-in-the-middle attack in which an attacker could intercept the contents of the secondary data connections.^[303]

TLS 1.3 qo'l siqish

The TLS 1.3 handshake was condensed to only one round trip compared to the two round trips required in previous versions of TLS/SSL.

First the client sends a clientHello message to the server that contains a list of supported ciphers in order of the client's preference and makes a guess on what key algorithm will be used so that it can send a secret key to share if needed. By making a guess at what key algorithm will be used, the server eliminates a round trip. After receiving the clientHello, the server sends a serverHello with its key, a certificate, the chosen cipher suite and the finished message.

After the client receives the server's finished message, it now is coordinated with the server on which cipher suite to use.^[304]

Sessiya identifikatorlari

In an ordinary to'liq handshake, the server sends a session id qismi sifatida Server salom xabar. The client associates this session id with the server's IP address and TCP port, so that when the client connects again to that server, it can use the session id to shortcut the handshake. In the server, the session id maps to the cryptographic parameters previously negotiated, specifically the "master secret". Both sides must have the same "master secret" or the resumed handshake will fail (this prevents an eavesdropper from using a session id). The random data in the ClientHello va Server salom messages virtually guarantee that the generated connection keys will be different from in the previous connection. In the RFCs, this type of handshake is called an qisqartirilgan handshake. It is also described in the literature as a qayta ishga tushirish handshake.

1. Negotiation phase:
   • A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods. Included in the message is the session id from the previous TLS connection.
   • The server responds with a Server salom message, containing the chosen protocol version, a random number, cipher suite and compression method from the choices offered by the client. If the server recognizes the session id sent by the client, it responds with the same session id. The client uses this to recognize that a resumed handshake is being performed. If the server does not recognize the session id sent by the client, it sends a different value for its session id. This tells the client that a resumed handshake will not be performed. At this point, both the client and server have the "master secret" and random data to generate the key data to be used for this connection.
2. The server now sends a ChangeCipherSpec record, essentially telling the client, "Everything I tell you from now on will be encrypted." The ChangeCipherSpec is itself a record-level protocol and has type 20 and not 22.
   • Finally, the server sends an encrypted Tugadi message, containing a hash and MAC over the previous handshake messages.
   • The client will attempt to decrypt the server's Tugadi message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
3. Finally, the client sends a ChangeCipherSpec, telling the server, "Everything I tell you from now on will be encrypted. "
   • The client sends its own encrypted Tugadi xabar.
   • The server performs the same decryption and verification procedure as the client did in the previous step.
4. Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be encrypted exactly like in their Tugadi xabar.

Sessiya chiptalari

RFC  5077 extends TLS via use of session tickets, instead of session IDs. It defines a way to resume a TLS session without requiring that session-specific state is stored at the TLS server.

When using session tickets, the TLS server stores its session-specific state in a session ticket and sends the session ticket to the TLS client for storing. The client resumes a TLS session by sending the session ticket to the server, and the server resumes the TLS session according to the session-specific state in the ticket. The session ticket is encrypted and authenticated by the server, and the server verifies its validity before using its contents.

One particular weakness of this method with OpenSSL is that it always limits encryption and authentication security of the transmitted TLS session ticket to AES128-CBC-SHA256, no matter what other TLS parameters were negotiated for the actual TLS session.^[295] This means that the state information (the TLS session ticket) is not as well protected as the TLS session itself. Of particular concern is OpenSSL's storage of the keys in an application-wide context (SSL_CTX), i.e. for the life of the application, and not allowing for re-keying of the AES128-CBC-SHA256 TLS session tickets without resetting the application-wide OpenSSL context (which is uncommon, error-prone and often requires manual administrative intervention).^[296][294]

TLS yozuvi

This is the general format of all TLS records.

Content type

This field identifies the Record Layer Protocol Type contained in this record.

Legacy version

This field identifies the major and minor version of TLS prior to TLS 1.3 for the contained message. For a ClientHello message, this need not be the eng yuqori version supported by the client. For TLS 1.3 and later, this must to be set 0x0303 and application must send supported versions in an extra message extension block.