TLS 1.3 негизиндеги домен фронту

тааныштыруу

TLS 1.3 негизиндеги домен фронту
Cisco, BlueCoat, FireEye сыяктуу атактуу өндүрүүчүлөрдүн заманбап корпоративдик мазмунду чыпкалоо системалары улуттук деңгээлде активдүү ишке ашырылып жаткан алардын күчтүүрөөк аналогдору - DPI системалары менен көп окшоштуктарга ээ. Экөөнүн тең ишинин маңызы кирүүчү жана чыккан интернет-трафикти текшерүү жана кара/ак тизмелердин негизинде интернетке кошулууга тыюу салуу чечимин кабыл алуу болуп саналат. Жана экөө тең өз иштеринин негиздеринде окшош принциптерге таянгандыктан, аларды айланып өтүүнүн ыкмалары да көп жалпылыкка ээ болот.

DPI жана корпоративдик системаларды натыйжалуу айланып өтүүгө мүмкүндүк берген технологиялардын бири - бул домендик технология. Анын маңызы биз бөгөттөлгөн ресурска барып, жакшы репутацияга ээ башка коомдук домендин артына жашынабыз, аны эч кандай система бөгөттөбөйт, мисалы google.com.

Бул технология жөнүндө буга чейин бир топ макалалар жазылган жана көптөгөн мисалдар келтирилген. Бирок, популярдуу жана жакында талкууланган DNS-over-HTTPS жана шифрленген-SNI технологиялары, ошондой эле TLS 1.3 протоколунун жаңы версиясы домендик фронттун башка вариантын карап чыгууга мүмкүндүк берет.

Технологияны түшүнүү

Биринчиден, кимдин ким экенин жана мунун баары эмне үчүн керек экенин ар бир адам түшүнүшү үчүн бир аз негизги түшүнүктөрдү аныктайлы. Биз eSNI механизмин айтып өттүк, анын иштеши андан ары талкууланат. eSNI (шифрленген Server Name Indication) механизми SNIдин коопсуз версиясы, TLS 1.3 протоколу үчүн гана жеткиликтүү. Негизги идея - башка нерселер менен катар суроо-талап кайсы доменге жөнөтүлгөнү тууралуу маалыматты шифрлөө.

Эми иш жүзүндө eSNI механизми кандай иштээрин карап көрөлү.

Заманбап DPI чечими менен бөгөттөлгөн интернет-ресурсубуз бар дейли (мисалы, белгилүү торрент трекер rutracker.nl программасын алалы). Торрент трекеринин веб-сайтына кирүүгө аракет кылганда, биз провайдердин ресурстун бөгөттөлгөндүгүн көрсөткөн стандарттык тактасын көрөбүз:

TLS 1.3 негизиндеги домен фронту

RKN веб-сайтында бул домен чындыгында токтотуу тизмелеринде көрсөтүлгөн:

TLS 1.3 негизиндеги домен фронту

Сиз whois сураганыңызда, домендин өзү Cloudflare булут провайдеринин артында "катылган" экенин көрө аласыз.

TLS 1.3 негизиндеги домен фронту

Бирок РКНнын “адистеринен” айырмаланып, Beeline компаниясынын техникалык жактан тереңирээк кызматкерлери (же биздин атактуу регулятордун ачуу тажрыйбасынан сабак алышкан) IP дареги боюнча сайтка акылсыздык менен тыюу салышкан жок, бирок домендик аталышты токтотуу тизмесине кошуп коюшкан. Эгер сиз ошол эле IP даректин артында башка кайсы домендер жашырылганын карасаңыз, алардын бирине кирип, кирүү бөгөттөлбөгөнүн көрсөңүз, муну оңой текшере аласыз:

TLS 1.3 негизиндеги домен фронту

Бул кантип болот? Провайдердин DPI'и менин браузерим кайсы доменде экенин кайдан билет, анткени бардык байланыштар https протоколу аркылуу ишке ашат жана биз Beeline'дан https сертификаттарынын алмаштырылганын байкай элекпиз? Ал көзү ачыкпы же мени ээрчип жүрүшкөнбү?

Келгиле, бул суроого wireshark аркылуу трафикти карап жооп бергенге аракет кылалы

TLS 1.3 негизиндеги домен фронту

Скриншот адегенде браузер сервердин IP дарегин DNS аркылуу ала турганын, андан кийин бара турган сервер менен стандарттуу TCP кол алышып, андан кийин браузер сервер менен SSL байланышын түзүүгө аракет кылаарын көрсөтүп турат. Бул үчүн, ал ачык текстте баштапкы домендин атын камтыган SSL Client Hello пакетин жөнөтөт. Бул талаа туташууну туура багыттоо үчүн cloudflare фронталдык серверине талап кылынат. Бул жерде DPI провайдери бизди кармап, байланышыбызды үзөт. Ошол эле учурда, биз провайдерден эч кандай тактарды албайбыз жана сайт өчүрүлгөн же жөн эле иштебей тургандай стандарттык браузер катасын көрөбүз:

TLS 1.3 негизиндеги домен фронту

Эми нускамада жазылгандай, браузерде eSNI механизмин иштетели Firefox :
Бул үчүн биз Firefox конфигурация барагын ачабыз жөнүндө: тарам жана төмөнкү орнотууларды иштетиңиз:

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

Андан кийин, биз орнотуулар cloudflare веб-сайтында туура иштеп жатканын текшеребиз. байланыш жана келгиле, торрент трекерибиз менен трюкту дагы бир жолу сынап көрөлү.

TLS 1.3 негизиндеги домен фронту

Voila. Биздин сүйүктүү трекер VPN же прокси серверлери жок ачылды. Эми эмне болгонун көрүү үчүн Wiresharkтагы трафиктин таштандысын карап көрөлү.

TLS 1.3 негизиндеги домен фронту

Бул жолу, ssl кардары hello пакети көздөгөн доменди ачык камтыбайт, бирок анын ордуна пакетте жаңы талаа пайда болду - encrypted_server_name - бул жерде rutracker.nl мааниси камтылган жана cloudflare frontend сервери гана муну чечмелей алат талаа. Эгер ошондой болсо, анда DPI провайдеринин колун жууп, мындай трафикке уруксат берүүдөн башка аргасы жок. Шифрлөө менен башка варианттар жок.

Ошентип, биз технология браузерде кантип иштээрин карап чыктык. Эми аны конкреттүү жана кызыктуу нерселерге колдонууга аракет кылалы. Биринчиден, биз ошол эле тармалга TLS 1.3 менен иштөө үчүн eSNI колдонууну үйрөтөбүз жана ошол эле учурда eSNI негизиндеги домен фронтунун өзү кантип иштээрин көрөбүз.

eSNI менен доменди иштетүү

Curl https протоколу аркылуу туташуу үчүн стандарттуу openssl китепканасын колдонгондугуна байланыштуу, биринчи кезекте биз ошол жерде eSNI колдоосун камсыз кылышыбыз керек. Openssl мастер бутактарында азырынча eSNI колдоосу жок, ошондуктан атайын openssl бутагын жүктөп алып, компиляциялап, орнотуубуз керек.

Биз репозиторийди GitHubдан клондоп, адаттагыдай эле компиляциялайбыз:

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

Андан кийин, биз репозиторийди curl менен клондойбуз жана компиляцияланган openssl китепканабызды колдонуп анын компиляциясын конфигурациялайбыз:

$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni

$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug

Бул жерде openssl жайгашкан бардык каталогдорду туура көрсөтүү маанилүү (биздин учурда бул /opt/openssl/) жана конфигурация процесси катасыз өтөөрүнө ынануу керек.

Эгер конфигурация ийгиликтүү болсо, биз сызыкты көрөбүз:

ЭСКЕРТҮҮ: esni ESNI иштетилген, бирок ЭКСПЕРИМЕНТтик деп белгиленген. Этияттык менен колдонуңуз!

$ make

Пакетти ийгиликтүү кургандан кийин, curl конфигурациялоо жана иштетүү үчүн opensslден атайын bash файлын колдонобуз. Ыңгайлуу болуу үчүн аны curl менен каталогго көчүрөлү:

cp /opt/openssl/esnistuff/curl-esni 

жана DNS жана TLS пакеттерин Wiresharkта бир эле учурда жаздыруу менен, cloudflare серверине https өтүнүчүн жөнөтүңүз.

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

Сервердин жообунда, openssl жана curl'ден көптөгөн мүчүлүштүктөрдү оңдоо маалыматынан тышкары, биз cloudflareден 301 коду менен HTTP жообун алабыз.

HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/

бул биздин өтүнүчүбүздүн көздөгөн серверине ийгиликтүү жеткирилгенин, угулганын жана иштетилгенин көрсөтөт.

Эми Wiresharkтагы трафиктин таштандысын карап көрөлү, б.а. Бул учурда DPI провайдери эмне көрдү.

TLS 1.3 негизиндеги домен фронту

Көрүнүп тургандай, curl адегенде cloudflare сервери үчүн жалпыга ачык eSNI ачкычы үчүн DNS серверине кайрылган - _esni.cloudflare.com дарегине TXT DNS сурамы (топтом №13). Андан кийин, openssl китепканасын колдонуп, curl SNI талаасы мурунку кадамда алынган ачык ачкыч менен шифрленген cloudflare серверине TLS 1.3 сурам жөнөттү (пакет №22). Бирок, eSNI талаасынан тышкары, SSL-hello пакети ошондой эле кадимки - ачык SNI менен талааны камтыйт, аны биз каалаган тартипте көрсөтө алабыз (бул учурда - www.hello-rkn.ru).

Бул ачык SNI талаасы cloudflare серверлери тарабынан иштетилгенде эч кандай эсепке алынган эмес жана DPI провайдери үчүн маска катары гана кызмат кылган. Cloudflare сервери биздин ssl-hello пакетибизди кабыл алды, eSNI шифрин чечти, ал жерден баштапкы SNIди чыгарып, эч нерсе болбогондой иштетти (eSNI иштеп жатканда бардыгын так пландалгандай кылды).

Бул учурда DPI көз карашы менен кармала турган бир гана нерсе - _esni.cloudflare.com сайтына негизги DNS өтүнүчү. Бирок биз DNS өтүнүчүн бул механизмдин ичинен кантип иштээрин көрсөтүү үчүн гана ачык кылдык.

Акыры килемди DPI астынан алып чыгуу үчүн, биз буга чейин айтылган DNS-over-HTTPS механизмин колдонобуз. Бир аз түшүндүрмө - DOH бул HTTPS аркылуу DNS өтүнүчүн жөнөтүү аркылуу ортодогу адамдын чабуулунан коргоого мүмкүндүк берген протокол.

Сурамды кайра аткаралы, бирок бул жолу биз DNS эмес, https протоколу аркылуу ачык eSNI ачкычтарын алабыз:

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

Сурамдын трафик таштандысы төмөндөгү скриншотто көрсөтүлгөн:

TLS 1.3 негизиндеги домен фронту

Көрүнүп тургандай, curl адегенде mozilla.cloudflare-dns.com серверине DoH протоколу (https серверине 104.16.249.249 туташуу) аркылуу SNI шифрлөө үчүн ачык ачкычтардын маанилерин, андан кийин көздөгөн жерге кире турганын көрүүгө болот. сервер, домендин артына жашынган www.hello-rkn.ru.

Жогорудагы DoH чечүүчү mozilla.cloudflare-dns.com тышкары, биз башка популярдуу DoH кызматтарын колдоно алабыз, мисалы, атактуу жаман корпорациядан.
Төмөнкү суроону иштетели:

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

Ошондо биз жооп алабыз:

< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH

TLS 1.3 негизиндеги домен фронту

Бул учурда, биз DoH чечүүчү dns.google аркылуу бөгөттөлгөн rutracker.nl серверине кайрылдык (бул жерде эч кандай ката жок, азыр атактуу корпорациянын өзүнүн биринчи деңгээлдеги домени бар) жана башка домен менен жаап алдык, ал катуу түрдө бардык DPI үчүн өлүм азабы астында бөгөт коюуга тыюу салынган. Алынган жооптун негизинде биздин өтүнүчүбүз ийгиликтүү иштетилгенин түшүнө аласыз.

Провайдердин DPI биз жабуу катары берген ачык SNIге жооп берерин кошумча текшерүү катары, биз башка тыюу салынган ресурстун, мисалы, дагы бир "жакшы" торрент трекеринин жамынуусу менен rutracker.nl дарегине сурам жөнөтө алабыз:

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

Серверден жооп албайбыз, анткени... биздин өтүнүч DPI тутуму тарабынан бөгөттөлөт.

Биринчи бөлүккө кыскача корутунду

Ошентип, биз openssl жана curl аркылуу eSNI функционалдуулугун көрсөтө алдык жана eSNI негизинде домендик фронтингдин иштешин сынай алдык. Ошо сыяктуу эле, биз башка домендердин "жумшак астында" иштөө үчүн openssl китепканасын колдонгон сүйүктүү куралдарыбызды ылайыкташтыра алабыз. Бул тууралуу кененирээк биздин кийинки макалаларыбызда.

Source: www.habr.com

Комментарий кошуу