HSTS: afzalliklari, xavflari va xavfsiz joriy etish

HSTS: xavfsizlik foydasi va joriy etish xavfi

HSTS — sozlash eng oson HTTP xavfsizlik mexanizmlaridan biri. Shu bilan birga, uni haddan tashqari qat’iy tarzda joriy qilish ham juda oson.

HTTP Strict Transport Security yoki HSTS brauzerga ma’lum bir domenga faqat HTTPS orqali murojaat qilish kerakligini bildiradi. Brauzer bu siyosatni bir marta eslab qolganidan keyin, http://example.com manzilini ochishga urinish xavfsiz bo‘lmagan HTTP so‘rovi yuborilishidan oldin HTTPS’ga o‘tkaziladi. HSTS, shuningdek, foydalanuvchiga ushbu host uchun sertifikat xatolarini chetlab o‘tishga ruxsat bermaydi. (rfc-editor.org)

Xavfsizlik nuqtai nazaridan foydasi sezilarli: HSTS HTTPS downgrade va SSL stripping hujumlari imkoniyatini kamaytiradi. Ammo joriy etish xavfi ham muhim: uzoq max-age, includeSubDomains yoki HSTS preloading noto‘g‘ri sozlangan yoki faqat HTTP orqali ishlaydigan hostlarni HTTPS muammosi tuzatilmaguncha foydalanuvchilar uchun yopib qo‘yishi mumkin.

Qisqa javob

HSTS — brauzerga ma’lum vaqt davomida domen uchun faqat HTTPS ishlatishni buyuradigan HTTP response header.

Odatdagi siyosat quyidagicha ko‘rinadi:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Bu yerda max-age=31536000 brauzer HSTS siyosatini taxminan bir yil davomida eslab turishini anglatadi. includeSubDomains esa ushbu siyosatni subdomenlarga ham tatbiq qiladi. Brauzerlar HSTS header’ni faqat xavfsiz ulanish orqali qabul qiladi; oddiy HTTP orqali kelgan HSTS header e’tiborga olinmaydi. (rfc-editor.org)

HSTS HTTPS joriy etilishini kuchaytiradi. U HTTPS, TLS sertifikatlari, redirect yoki to‘g‘ri server konfiguratsiyasining o‘rnini bosmaydi.

Asosiy faktlar

Parametr	Nima qiladi	Asosiy xavf
`max-age`	HSTS siyosatini ma’lum soniyaga saqlaydi	Xatolar siyosat muddati tugaguncha ta’sir qilishi mumkin
`includeSubDomains`	HSTS’ni subdomenlarga ham qo‘llaydi	Faqat HTTP orqali ishlaydigan subdomenlar ochilmay qolishi mumkin
`preload`	Brauzerlarning preload dasturlarida qatnashish niyatini bildiradi	Butun domen uchun uzoqroq muddatli majburiyat yaratadi
`max-age=0`	Dinamik o‘rganilgan HSTS siyosatini olib tashlaydi	Brauzer bu qiymatni olish uchun avval saytga xavfsiz ulanishi kerak

RFC 6797 max-age va includeSubDomains direktivalarini belgilaydi. preload mexanizmi esa HSTS spetsifikatsiyasining o‘ziga emas, brauzer ekotizimiga tegishli qo‘shimcha imkoniyatdir. (rfc-editor.org)

HSTS nega muhim?

HTTP foydalanuvchilarini HTTPS’ga yo‘naltiradigan saytni ko‘rib chiqamiz:

http://example.com
        ↓
301 redirect
        ↓
https://example.com

Bunday redirect odatiy foydalanuvchini HTTPS’ga olib boradi, ammo dastlabki HTTP so‘rovi baribir shifrlanmagan bo‘ladi. Tarmoqni nazorat qilayotgan hujumchi HTTPS ulanish o‘rnatilishidan oldin unga aralashishi mumkin. MDN buni SSL stripping hali ham mumkin bo‘lgan birinchi ulanish oynasi sifatida tushuntiradi. (developer.mozilla.org)

Brauzer HSTS siyosatini o‘rganganidan keyin jarayon o‘zgaradi:

User requests http://example.com
        ↓
Browser sees stored HSTS policy
        ↓
Browser changes request to HTTPS
        ↓
HTTPS connection

Xavfsiz bo‘lmagan so‘rov yuborilmaydi.

Muhim farq shunda: HTTP’dan HTTPS’ga redirect HTTP so‘rovi serverga yetib borgandan keyin ishlaydi, HSTS esa brauzerga so‘rovni yuborishdan oldin lokal ravishda HTTPS’ga o‘tkazish imkonini beradi.

INTERNAL LINK: HTTPS va TLS qanday ishlaydi

HSTS qanday ishlaydi?

HTTPS javobi quyidagini o‘z ichiga olsa:

Strict-Transport-Security: max-age=31536000

brauzer ushbu hostni HSTS host sifatida saqlaydi. max-age qiymati brauzer header’ni olgan paytdan boshlab hisoblanadigan siyosatning amal qilish muddati sifatida ishlaydi. Keyingi mos HTTP so‘rovlari HTTPS’ga o‘tkaziladi. Har bir yangi HSTS javobi amal qilish muddatini yangilashi mumkin. (rfc-editor.org)

Yana bir muhim xususiyat bor: HSTS host uchun TLS sertifikat xatolarini chetlab o‘tib bo‘lmaydi. Odatda sertifikat ogohlantirishi ko‘rsatilganda, foydalanuvchida ba’zan baribir davom etish imkoniyati bo‘lishi mumkin. HSTS bu yo‘lni ataylab olib tashlaydi, chunki foydalanuvchiga xatoni chetlab o‘tishga ruxsat berish xavfsizlik siyosatining ma’nosini yo‘qqa chiqaradi. (developer.mozilla.org)

Hujum paytida bu foydali, ammo infratuzilmadagi xato vaqtida jiddiy muammoga aylanishi mumkin.

Joriy etish xavfi

HSTS bilan bog‘liq eng katta xatolardan biri — eng qat’iy konfiguratsiyani boshlang‘ich sozlama deb qabul qilish.

Quyidagi domen tuzilmasini tasavvur qiling:

example.com
www.example.com
api.example.com
legacy.example.com
internal.example.com

Faraz qilaylik, legacy.example.com hali ham faqat HTTP orqali ishlaydi. Parent domenda quyidagi siyosatni birdaniga yoqish xavfli bo‘ladi:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Bu siyosatni olgan brauzer example.com ostidagi subdomenlar uchun ham HTTPS talab qila boshlashi mumkin. Agar legacy.example.com to‘g‘ri HTTPS xizmatini taqdim eta olmasa, foydalanuvchilar unga kira olmay qolishi mumkin.

Shuning uchun includeSubDomains faqat tegishli subdomenlar ro‘yxati tekshirilib, ularda HTTPS ishlashi tasdiqlangandan keyin yoqilishi kerak. MDN bu direktiva hali HTTPS’ni qo‘llamaydigan subdomenlarga kirishni bloklab qo‘yishi mumkinligini alohida ogohlantiradi. (developer.mozilla.org)

Xavfsizroq joriy etish

HSTS’ni birdaniga qat’iy sozlashdan ko‘ra bosqichma-bosqich joriy qilish xavfsizroq.

Avval asosiy domen HTTPS orqali to‘g‘ri ishlashini tekshiring. Keyin qisqa HSTS muddatidan boshlang, masalan:

Strict-Transport-Security: max-age=300

Bu siyosat uchun besh daqiqalik muddat beradi.

Sertifikat yangilanishi, redirectlar, CDN xatti-harakati, ilova route’lari, xato javoblari va boshqa infratuzilma qismlarini tekshirgandan keyin muddatni bosqichma-bosqich oshiring:

Strict-Transport-Security: max-age=86400

Keyin qo‘shimcha tekshiruvlardan so‘ng:

Strict-Transport-Security: max-age=31536000

includeSubDomains’ni faqat kerakli subdomenlar daraxtining barcha qismlarida HTTPS ishonchli ishlaganda qo‘shing.

Bunday bosqichma-bosqich oshirish RFC 6797 talabi emas, balki SeoNest’ning joriy etish bo‘yicha tavsiyasidir. HSTS preload xizmatining joriy ko‘rsatmalari ham domenni preload uchun yuborishdan oldin max-age qiymatini bosqichma-bosqich oshirishni tavsiya qiladi. (hstspreload.org)

HSTS Preloading

Oddiy HSTS’ning bir cheklovi bor: brauzer odatda siyosatni bilishi uchun avval HSTS header’ni olishi kerak. Shu sababli yangi brauzer profilida dastlabki ulanish oynasi saqlanib qoladi.

HSTS preloading bu muammoni HSTS domenlari ro‘yxatini brauzer bilan birga yetkazish orqali hal qiladi. Chromium hujjatlarida Chrome shunday preload ro‘yxatini yuritishi va boshqa brauzerlar ham unga asoslangan ro‘yxatlardan foydalanishi qayd etilgan. (chromium.org)

hstspreload.org’dagi joriy talablar orasida haqiqiy sertifikat, HTTP ishlatilsa ayni hostda HTTP’dan HTTPS’ga redirect, barcha subdomenlarda HTTPS qo‘llab-quvvatlanishi, includeSubDomains, preload va kamida 31536000 soniyalik max-age mavjud. (hstspreload.org)

Preload uchun mos odatiy header quyidagicha:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Ammo preloading’ni shunchaki yoqib qo‘yish kerak emas. Preload xizmati loyihalarda preload’ni default holatda yoqmaslikni aniq ogohlantiradi va ro‘yxatdan chiqarish sekin kechishi mumkinligini ta’kidlaydi. Uning joriy ko‘rsatmalari HSTS’ning o‘zini tavsiya qiladi, HSTS preloading’ga esa ehtiyotkorroq yondashadi. (hstspreload.org)

Nginx misoli

Nginx uchun:

add_header Strict-Transport-Security "max-age=31536000" always;

always parametri Nginx’ga response status’idan qat’i nazar header’ni qo‘shishni buyuradi. Nginx’da add_header uchun maxsus inheritance qoidalari ham mavjud, shuning uchun ichki server yoki location konfiguratsiyalarini alohida tekshirish kerak; header hamma joyda avtomatik meros bo‘ladi deb hisoblamaslik lozim. (nginx.org)

Brauzer ishonadi degan umidda HSTS’ni faqat HTTP ishlaydigan endpoint’dan yubormang. Brauzerlar xavfsiz bo‘lmagan HTTP orqali kelgan HSTS header’larini ataylab e’tiborga olmaydi. (developer.mozilla.org)

Joriy etishni tekshirish

HTTPS response header’larini to‘g‘ridan-to‘g‘ri tekshiring:

curl -I https://example.com

curl -I HTTP response header’larini oladi va Strict-Transport-Security haqiqatan ham mavjudligini tekshirish imkonini beradi. (curl.se)

Quyidagini qidiring:

Strict-Transport-Security: max-age=31536000

Shuningdek, redirectlar, xato javoblari, muhim subdomenlar va sertifikatlarning haqiqiyligini tekshiring. Agar includeSubDomains ishlatmoqchi bo‘lsangiz, faqat apex domain’ni tekshirish yetarli emas.

Keng tarqalgan noto‘g‘ri tushunchalar

HSTS serverda HTTP’ni HTTPS’ga redirect qiladi. To‘liq unday emas. Siyosat brauzerga ma’lum bo‘lgach, brauzer xavfsiz bo‘lmagan HTTP ulanishini yaratishdan oldin so‘rovni HTTPS’ga o‘tkazishi mumkin.

HSTS muddati o‘tgan sertifikatni tuzatadi. Yo‘q. HSTS sertifikat xatolariga munosabatni yanada qat’iy qiladi. Shu sababli buzilgan sertifikat HSTS bilan himoyalangan saytni sertifikat muammosi hal qilinmaguncha butunlay ochilmaydigan holatga olib kelishi mumkin.

Header’ni olib tashlash HSTS’ni darhol o‘chiradi. Yo‘q. Oldin saqlangan siyosat uning max-age muddati tugaguncha faol qoladi. Brauzer HTTPS orqali max-age=0 qiymatini muvaffaqiyatli olganda, dinamik HSTS siyosati olib tashlanadi. (rfc-editor.org)

Har bir HTTPS sayt darhol preload ishlatishi kerak. HSTS va HSTS preloading — ikki alohida qaror. Preloading kuchliroq operatsion majburiyat yaratadi va uni faqat butun domen namespace’i sinchiklab tekshirilgandan keyin qo‘llash kerak.

SeoNest tavsiyasi

HSTS’ni HTTPS allaqachon barqaror ishlayotganidan keyin yoqing. Uni beqaror HTTPS joriy etilishini xavfsiz qilish vositasi sifatida ishlatmang.

Asosiy hostname va qisqa max-age bilan boshlang. Sertifikatlar, redirectlar, CDN xatti-harakati, ilova xatolari va sertifikat yangilash avtomatizatsiyasini tekshiring. max-age’ni bosqichma-bosqich oshiring. includeSubDomains’ni faqat tegishli subdomenlarni tekshirganingizdan keyin qo‘shing. Preloading’ni oddiy HTTP header’dan tashqariga chiqadigan oqibatlari sababli alohida infratuzilmaviy qaror sifatida ko‘ring.

Maqsad eng qat’iy ko‘rinadigan header’ni sozlash emas. Maqsad — infratuzilmangiz ishonchli tarzda bajara oladigan HTTPS siyosatini yaratish.

FAQ

HSTS SEO’ni yaxshilaydimi?

HSTS birinchi navbatda transport xavfsizligi mexanizmidir. Ushbu maqolada foydalanilgan manbalarda Google HSTS’ning o‘zini to‘g‘ridan-to‘g‘ri ranking factor sifatida hujjatlashtirmagan. Shuning uchun uning qiymatini taxminiy ranking foydasi bilan emas, asosan HTTPS xavfsizligi va joriy etish ishonchliligi nuqtai nazaridan baholash kerak.

HSTS birinchi tashrifga ta’sir qiladimi?

Oddiy, dinamik tarzda o‘rganiladigan HSTS sayt siyosatini hali bilmaydigan brauzerni to‘liq himoya qila olmaydi. Preloading ro‘yxatga kiritilgan domenlar uchun ushbu dastlabki bo‘shliqni yo‘q qilishi mumkin. (developer.mozilla.org)

HSTS’ni o‘chirsa bo‘ladimi?

Dinamik tarzda saqlangan siyosat uchun server quyidagini yuborishi mumkin:

Strict-Transport-Security: max-age=0

Bu HTTPS orqali yuborilishi kerak. Shundan keyin brauzer RFC 6797’da belgilanganidek, ushbu host uchun saqlangan HSTS siyosatini olib tashlaydi. (rfc-editor.org)

API’larda HSTS ishlatish kerakmi?

Agar API hostname’ga HSTS’ni qo‘llaydigan user agent’lar murojaat qilsa, u ham xuddi shu transport siyosatining afzalliklaridan foydalanishi mumkin. Parent domenda includeSubDomains ishlatish kerakmi yoki yo‘qmi, baribir kengroq domen daraxtining HTTPS’ga tayyorligiga bog‘liq.

Yakuniy xulosa

HSTS brauzerlarga kelajakdagi ulanishlarda HTTPS’ni majburiy ishlatishni buyurib, oddiy HTTP’dan HTTPS’ga redirect’dagi muhim zaiflikni yopadi. Uning kuchi siyosatning saqlanib qolishida: brauzer uni eslab qoladi va xavfsiz bo‘lmagan fallback’ga ruxsat bermaydi.

Ammo aynan shu doimiylik joriy etish xavfini ham yaratadi.

HSTS’dan ongli ravishda foydalaning. Avval HTTPS’ni barqaror qiling, boshqarish oson bo‘lgan max-age bilan boshlang, qamrovni faqat testlardan keyin kengaytiring va includeSubDomains hamda preloading’ni oddiy header parametrlari emas, balki infratuzilmaviy majburiyatlar sifatida ko‘ring.

Manbalar

RFC Editor — RFC 6797: HTTP Strict Transport Security (HSTS), November 2012. HSTS ishlov berish jarayoni, max-age, includeSubDomains, amal qilish muddati va siyosatni olib tashlash xatti-harakatini belgilaydi. (rfc-editor.org)
MDN Web Docs — Strict-Transport-Security header. Brauzerlarning amaliy xatti-harakati, sintaksis, sertifikatlar bilan ishlash, subdomenlar va preload konteksti. (developer.mozilla.org)
MDN Web Docs — Transport Layer Security. HTTPS upgrade xatti-harakati, SSL stripping va dinamik tarzda o‘rganiladigan HSTS’ning birinchi ulanish cheklovi. (developer.mozilla.org)
Chromium — HTTP Strict Transport Security. Chromium’dagi HSTS xatti-harakati va brauzer preload ro‘yxatlari haqida tavsif. (chromium.org)
HSTS Preload List Submission — hstspreload.org. Joriy preload talablari, operatsion ogohlantirishlar va domen yuborish bo‘yicha ko‘rsatmalar. (hstspreload.org)
NGINX — ngx_http_headers_module. add_header, always va header inheritance bo‘yicha rasmiy hujjatlar. (nginx.org)
curl — Tutorial. HTTP header’larini tekshirish uchun -I / --head ishlatish bo‘yicha rasmiy hujjat. (curl.se)