STARTTLS — dastlab oddiy matnli protocol connectionini shu ulanish ichida TLS bilan himoyalangan kanalga ko‘tarish buyrug‘i. SMTP, IMAP, POP3, LDAP va boshqa protokollarda uchraydi. Client server imkoniyatlarini ko‘radi, STARTTLS yuboradi, TLS handshake bajaradi va keyingi protocol almashinuvi shifrlangan kanal ichida davom etadi.
SMTP oqimi
SMTP client TCP connection ochib server greetingini oladi va EHLO yuboradi. Server capability ro‘yxatida STARTTLS’ni e’lon qilsa client buyruq beradi. Server tayyor javobidan keyin TLS handshake boshlanadi.
TLS o‘rnatilgach client yana EHLO yuborishi kerak, chunki capability va authentication usullari himoyalangan sessiyada boshqacha bo‘lishi mumkin. Credential TLSdan oldin yuborilmaydi.
| Bosqich | Mazmuni |
|---|---|
| Plain greeting | Protocol session boshlanadi |
| Capability | STARTTLS mavjudligi aniqlanadi |
| STARTTLS | TLSga o‘tish so‘raladi |
| Handshake | Certificate va session key |
| Yangi capability | Himoyalangan sessiya qayta e’lon qilinadi |
| Protocol data | Shifrlangan almashinuv |
Opportunistic va majburiy rejim
Server-to-server SMTP’da opportunistic TLS keng ishlatiladi: STARTTLS mavjud bo‘lsa shifrlanadi, yo‘q bo‘lsa mail yetkazilishi uchun plain davom etishi mumkin. Bu passiv kuzatuvni kamaytiradi, ammo active downgrade hujumiga qarshi yetarli emas.
Client submission yoki credential ishlatiladigan IMAP’da TLS majburiy bo‘lishi kerak. STARTTLS yo‘q, handshake yoki certificate validation xato bo‘lsa connection to‘xtaydi. “TLS imkoni bo‘lsa” va “TLS bo‘lmasa xizmat yo‘q” siyosatlari aniq farqlanadi.
Downgrade hujumi
Tarmoqdagi hujumchi server capability javobidan STARTTLS satrini olib tashlashi mumkin. Opportunistic client plain davom etsa shifrlash bekor bo‘ladi. SMTP uchun MTA-STS domenning TLS talabini HTTPS policy orqali, DANE esa DNSSEC bilan himoyalangan TLSA yozuvi orqali bildiradi.
Oldingi muvaffaqiyatli TLSni eslab qolish va keyingi yo‘qolishda alert berish ham downgrade’ni aniqlashga yordam beradi. Biroq policy authoritative manbaga tayanishi kerak.
Certificate tekshiruvi
TLS faqat encryption emas, server identity’sini ham tekshirishi kerak. Client certificate chain ishonchli CAga borishini, amal qilish muddatini va hostname mosligini tekshiradi. “Har qanday certificate qabul qilinsin” active man-in-the-middle hujumiga yo‘l beradi.
SMTP MX hosti bilan certificate name mosligini talqin qilish web HTTPSdan murakkab bo‘lishi mumkin. MTA-STS policy MX patternlarni belgilaydi; DANE certificate yoki public key’ni TLSA bilan bog‘laydi.
Portlar va implicit TLS
STARTTLS explicit upgrade bo‘lib, connection plain protocol bilan boshlanadi. Implicit TLS’da esa TCP ochilishi bilan TLS handshake boshlanadi. SMTP submission uchun 587 STARTTLS bilan, 465 implicit TLS bilan ishlatilishi mumkin. IMAP’da 143 STARTTLS, 993 implicit TLS; POP3’da 110 STARTTLS, 995 implicit TLS odatiy.
Client port va mode’ni aralashtirsa server greetingini TLS deb yoki TLS bytesni plain text deb talqin qilib connection ishlamaydi. Konfiguratsiyada transport turi aniq ko‘rsatiladi.
Xatolar va monitoring
Handshake failure protocol version, cipher, expired certificate, hostname, SNI yoki clock muammosidan kelishi mumkin. Log remote host, TLS version va xavfsiz error kategoriyasini ko‘rsatadi, ammo session key yoki credentialni yozmaydi.
Monitoring TLS success rate, plain fallback, certificate expiry va policy violationni kuzatadi. Mail queue’da faqat “connection failed” emas, STARTTLS sabab kodi ajratiladi. Strict policy’dagi vaqtinchalik TLS xatosi retry qilinadi, doimiy noto‘g‘ri policy esa operator aralashuvini talab qiladi.
Bog‘liq tushunchalar
TLS, SMTP, IMAP, POP3, MTA-STS, DANE, Certificate validation