Cipher suite — TLS ulanishida key agreement, autentifikatsiya, simmetrik shifrlash va message authentication uchun qo‘llanadigan algoritmlar to‘plamini ifodalovchi nomlangan konfiguratsiya. TLS 1.2 va undan oldingi versiyalarda suite nomi ko‘p komponentni birga bildiradi. TLS 1.3da esa suite faqat AEAD cipher va hashni belgilaydi; key exchange hamda certificate signature algoritmlari alohida kelishiladi.
TLS 1.2 nomi
Masalan, quyidagi suite tarkibini nomidan o‘qish mumkin:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE ephemeral elliptic-curve Diffie–Hellman key agreementini, RSA server certificate signature turini, AES_128_GCM authenticated encryptionni, SHA256 esa handshake PRF hashini bildiradi. Bu suite RSA bilan trafficni shifrlaydi degani emas; RSA serverni autentifikatsiya qiladi, AES data’ni shifrlaydi.
Eski TLS_RSA_WITH_AES_... suite’da RSA key transport ishlatilgan va forward secrecy yo‘q. Server private key keyinchalik o‘g‘irlansa, yozib olingan handshake’dan premaster secret ochilishi mumkin. ECDHE har sessiya uchun ephemeral key ishlatib, uzoq muddatli certificate key compromise’idan oldingi sessiyalarni himoya qiladi.
TLS 1.3 nomi
TLS 1.3 misoli:
TLS_AES_128_GCM_SHA256
Bu nom AEAD sifatida AES-128-GCM va HKDF/transcript uchun SHA-256ni bildiradi. X25519 yoki P-256 key share, RSA-PSS yoki ECDSA certificate signature’i boshqa extensionlar orqali negotiation qilinadi. TLS 1.3 faqat forward-secret key exchange va AEAD sxemalarni qoldirgan.
TLS_CHACHA20_POLY1305_SHA256 AES apparat tezlashtirishi bo‘lmagan qurilmalarda samarali bo‘lishi mumkin. Server va client qo‘llaydigan umumiy suite tanlanadi. Ba’zi serverlar client hardware signalini to‘liq bilmaydi; browser preference tartibi ham performance tanloviga ta’sir qiladi.
Zaif suite’lar
Export-grade cipherlar tarixiy qonuniy cheklovlar sabab qisqa key ishlatgan va bugun butunlay xavfli. RC4 statistik biaslarga ega. 3DES 64 bit block size sabab ko‘p data’da birthday collision xavfiga duch keladi. CBC suite’lar to‘g‘ri implementatsiyada ishlashi mumkin, ammo padding oracle va murakkab encrypt-then-MAC tarixiga ega; AEAD sodda va xavfsizroq profil beradi.
NULL encryption maxfiylik bermaydi, anonymous Diffie–Hellman esa server identitysini tasdiqlamaydi. Static DH yoki ECDH certificate’lar forward secrecy bermasligi mumkin. Konfiguratsiya faqat mashhur “HIGH” nomiga emas, aniq ruxsat etilgan suite ro‘yxati va protocol versionga tayanadi.
Tanlash va server siyosati
TLS 1.2da server o‘z preference tartibini yoki client tartibini tanlashi mumkin. Birinchi umumiy suite ishlatiladi. Juda katta legacy ro‘yxat compatibilityni oshiradi, lekin downgrade va audit yuzasini kengaytiradi. Faqat real qo‘llab-quvvatlanadigan client platformalari uchun kerakli profil saqlanadi.
Security level algoritmlarning eng zaif komponenti bilan cheklanadi. AES-256 ishlatib, SHA-1 signature yoki 1024 bit RSA certificate qo‘llash butun ulanishni 256 bit xavfsiz qilmaydi. Certificate key, signature, key exchange group, hash va AEAD muvofiq darajada tanlanadi.
Kuzatuv
Handshake loglari negotiated TLS version, suite, group va signature algorithmni metadata sifatida qayd etishi mumkin, lekin session secretni yozmaydi. Metrikalar eski suite’dan foydalanuvchi clientlar ulushini ko‘rsatib, ularni o‘chirish qarorini asoslaydi. Tashqi scanner faqat internet endpointini, service mesh yoki backend TLS esa alohida konfiguratsiyani ko‘rsatadi.
Library va server yangilanganda default suite ro‘yxati o‘zgarishi mumkin. Konfiguratsiya testlari minimal version va taqiqlangan algoritmlarni tekshiradi. Browser, API client va embedded qurilma bilan interoperability sinovi certificate chain va ALPNni ham qamrab oladi.
Bog‘liq tushunchalar
TLS, AEAD, ECDHE, AES-GCM, ChaCha20-Poly1305, Forward secrecy, Handshake