HTTPS ва SVCB DNS ёзуви: браузерга уланишни олдиндан айтиш

Браузер сайтни очишдан олдин бир нечта иш қилади: DNS'дан IP манзилни сўрайди, серверга уланади, шифрлаш бўйича келишади ва шундан кейингина саҳифани сўрайди. Кўп ҳолларда браузер сервернинг HTTP/3'ни қўллашини ёки сайтнинг фақат HTTPS орқали ишлашини биринчи уланишдан кейингина билиб олади. 2023 йилда RFC 9460 сифатида стандартлаштирилган SVCB ва HTTPS ёзувлари бу маълумотларни DNS'нинг ўзида, уланишдан олдин бериш имконини яратади. Натижада биринчи уланиш тезроқ ва хавфсизроқ бўлиши мумкин.

SVCB ва HTTPS ёзувлари ўртасидаги фарқ

SVCB, яъни "service binding", исталган хизмат учун умумий ёзув тури ҳисобланади. HTTPS эса унинг веб учун мўлжалланган махсус кўринишидир: формати бир хил, лекин у фақат https схемасидаги сайтлар учун ишлатилади ва номи олдига қўшимча префикс талаб қилмайди. Амалда сайт эгалари деярли ҳар доим HTTPS туридаги ёзув билан ишлайди, SVCB эса бошқа протоколлар, масалан шифрланган DNS хизматлари учун қўлланади.

Ёзув уч қисмдан иборат: устуворлик, мақсад номи ва параметрлар. Устуворлик 0 бўлса, бу "AliasMode", яъни тахаллус режими: ёзув фақат бошқа номга йўналтиради. Устуворлик 1 ва ундан катта бўлса, бу "ServiceMode": ёзув уланиш параметрларини беради. Мақсад номи сифатида нуқта ёзилса, бу "шу номнинг ўзи" деган маънони англатади.

Ёзув қандай кўринади

Қуйидаги мисолда example.uz сайти HTTP/3 ва HTTP/2'ни қўллашини эълон қилади ва браузерга IP манзиллар бўйича ишора беради. Иккинчи қаторда эса домен апекси учун тахаллус режими кўрсатилган: бу ҳолда сайтнинг ўзи CDN номига йўналтирилади. Апексда CNAME қўйиш тақиқлангани учун бу имконият айниқса қизиқарли, лекин браузерларнинг тахаллус режимини қўллаб-қувватлаши ҳали бир хил эмас.

example.uz.   3600  IN  HTTPS  1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10
misol.uz.     3600  IN  HTTPS  0 cdn.example.net.

Асосий параметрлар қуйидагилар. alpn сервер қўллайдиган протоколлар рўйхати, h3 HTTP/3'ни, h2 эса HTTP/2'ни билдиради. port ностандарт порт учун ишлатилади. ipv4hint ва ipv6hint IP манзиллар бўйича ишора бўлиб, браузерга A ва AAAA жавобини кутмасдан уланишни бошлаш имконини беради. ech параметри эса шифрланган Client Hello, яъни ECH учун калит маълумотларини тарқатади ва браузер қайси сайтга уланаётганини тармоқдаги кузатувчидан яширишга ёрдам беради.

Амалий фойдаси нимада

Биринчи фойда HTTP/3 билан боғлиқ. Одатда браузер сервер HTTP/3'ни қўллашини Alt-Svc сарлавҳасидан билади, яъни аввал HTTP/2 орқали уланади ва фақат кейинги сўровларда QUIC'га ўтади. HTTPS ёзуви бўлса, браузер HTTP/3'ни биринчи уланишданоқ синаб кўриши мумкин. Бу айниқса мобил тармоқларда, йўқотишлар кўп бўлган шароитда сезиларли бўлади.

Иккинчи фойда хавфсизликка оид. Стандартга кўра, HTTPS ёзуви мавжуд бўлса, мижоз http:// манзилини автоматик равишда https://'га ўтказиши керак. Бу HSTS каби ишлайди ва фойдаланувчи биринчи марта оддий HTTP орқали кирганда ҳам шифрланмаган сўров юборилмайди. Учинчи фойда ECH: у фақат HTTPS ёзуви орқали тарқатилади, шунинг учун бу ёзувсиз ECH ишламайди.

Реал мисол: онлайн курс платформаси

Тошкентдаги онлайн таълим платформаси видеодарсларни асосан мобил фойдаланувчиларга беради. Серверда Nginx орқали HTTP/3 аллақачон ёқилган эди, лекин статистикага кўра биринчи ташрифда уланишларнинг деярли барчаси HTTP/2'да қолаётган эди. Администратор аввал HTTP/3 ҳақиқатан ишлашини текширди, кейин домен учун alpn="h3,h2" параметрли HTTPS ёзувини қўшди. Шундан кейин ёзувни қўллаб-қувватлайдиган браузерлар биринчи уланишдан HTTP/3'ни ишлата бошлади. Nginx'даги тегишли созлама қуйидагича бўлади:

server {
    listen 443 ssl;
    listen 443 quic reuseport;
    http2 on;
    server_name example.uz;
    add_header Alt-Svc 'h3=":443"; ma=86400';
    # ssl_certificate ...
}

HTTP/3 UDP протоколида ишлайди, шунинг учун хавфсизлик деворида UDP 443-порт очиқ бўлиши керак: sudo ufw allow 443/udp. Бусиз ёзув браузерга HTTP/3'ни ваъда қилади, сервер эса унга жавоб бермайди.

Нотўғри созлашнинг хавфлари

Биринчи хавф автоматик HTTPS'га ўтиш билан боғлиқ. Агар сайтда ишлайдиган SSL сертификати бўлмаса ёки баъзи субдоменлар фақат HTTP'да ишласа, HTTPS ёзуви қўшилгандан кейин улар қўллаб-қувватлайдиган браузерларда очилмай қолади. Шунинг учун ёзувни фақат сертификати тўғри ишлайдиган номларга қўшинг. Let's Encrypt сертификати автоматик янгиланиб туриши ҳам муҳим.

Иккинчи хавф эскирган ишоралар. Сервер IP манзили ўзгарганда A ёзуви янгиланади, лекин ipv4hint эсдан чиқиб қолиши осон. Браузер ишорадаги эски манзилга уланишга уриниб, вақт йўқотади. Агар IP тез-тез ўзгарса, ишора параметрларини умуман ёзмаган маъқул, улар мажбурий эмас. Учинчи хавф alpn'да серверда йўқ протоколни эълон қилиш: браузер захира йўлга ўтади, аммо бу биринчи уланишни тезлаштириш ўрнига секинлаштиради.

Ёзувни қўшиш ва текшириш

HTTPS ёзуви нисбатан янги тур бўлгани учун ҳамма DNS панеллари уни қўллаб-қувватламайди. Баъзи CDN хизматлари эса уни автоматик эълон қилади. sayt.uz кабинетидаги DNS бўлимида бу тур мавжудлигини кўриб чиқинг ёки техник ёрдам орқали аниқланг. Қўшилгандан кейин ёзувни dig билан текширинг. Эски dig версиялари HTTPS турини номидан танимаса, унинг рақами бўйича сўраш мумкин:

dig example.uz HTTPS +short
dig example.uz TYPE65 +short
curl --http3 -I https://example.uz

Охирги буйруқ фақат HTTP/3 қўллаб-қувватланадиган curl версиясида ишлайди. HTTPS ёзуви бўлмаган ёки уни танимайдиган мижозлар одатдагидек A ва AAAA ёзувлари орқали уланишда давом этади, шунинг учун тўғри созланган ёзув ҳеч кимга зарар етказмайди, фақат қўллаб-қувватловчиларга тезлик ва хавфсизлик қўшади.