დომენის ფრონტინგი TLS 1.3-ზე დაფუძნებული

შესავალი

თანამედროვე კორპორატიული შინაარსის ფილტრაციის სისტემებს ისეთი ცნობილი მწარმოებლებისგან, როგორებიცაა Cisco, BlueCoat, FireEye, საკმაოდ ბევრი საერთო აქვთ მათ უფრო მძლავრ კოლეგებთან - DPI სისტემებთან, რომლებიც აქტიურად დანერგილია ეროვნულ დონეზე. ორივეს მუშაობის არსი არის შემომავალი და გამავალი ინტერნეტ ტრაფიკის შემოწმება და შავ/თეთრი სიების საფუძველზე გადაწყვეტილების მიღება ინტერნეტთან კავშირის აკრძალვის შესახებ. და რადგან ორივე მათგანი ეყრდნობა მსგავს პრინციპებს თავიანთი მუშაობის საფუძვლებში, მათი გვერდის ავლების მეთოდებსაც ბევრი საერთო ექნებათ.

ერთ-ერთი ტექნოლოგია, რომელიც საშუალებას გაძლევთ საკმაოდ ეფექტურად გადალახოთ როგორც DPI, ასევე კორპორატიული სისტემები, არის domain-fronting ტექნოლოგია. მისი არსი იმაში მდგომარეობს, რომ ჩვენ მივდივართ დაბლოკილ რესურსზე, ვიმალებით სხვა, კარგი რეპუტაციის მქონე საჯარო დომენის მიღმა, რომელსაც, ცხადია, არც ერთი სისტემა არ დაბლოკავს, მაგალითად google.com.

ამ ტექნოლოგიის შესახებ უკვე დაიწერა საკმაოდ ბევრი სტატია და მოყვანილია მრავალი მაგალითი. თუმცა, პოპულარული და ახლახან განხილული DNS-over-HTTPS და დაშიფრული-SNI ტექნოლოგიები, ისევე როგორც TLS 1.3 პროტოკოლის ახალი ვერსია, შესაძლებელს ხდის განიხილოს დომენის ფრონტინგის სხვა ვარიანტი.

ტექნოლოგიის გააზრება

პირველ რიგში, მოდით განვსაზღვროთ ცოტა ძირითადი ცნებები, რათა ყველამ გაიგოს ვინ არის ვინ და რატომ არის ეს ყველაფერი საჭირო. ჩვენ აღვნიშნეთ eSNI მექანიზმი, რომლის ფუნქციონირებას შემდგომში განვიხილავთ. eSNI (დაშიფრული სერვერის სახელის მითითება) მექანიზმი არის SNI-ის უსაფრთხო ვერსია, ხელმისაწვდომი მხოლოდ TLS 1.3 პროტოკოლისთვის. მთავარია დაშიფვრა, სხვა საკითხებთან ერთად, ინფორმაცია იმის შესახებ, თუ რომელ დომენში იგზავნება მოთხოვნა.

ახლა ვნახოთ, როგორ მუშაობს eSNI მექანიზმი პრაქტიკაში.

ვთქვათ, გვაქვს ინტერნეტ რესურსი, რომელიც დაბლოკილია თანამედროვე DPI გადაწყვეტით (მაგალითად, ავიღოთ ცნობილი ტორენტის ტრეკერი rutracker.nl). როდესაც ჩვენ ვცდილობთ წვდომას ტორენტ ტრეკერის ვებსაიტზე, ჩვენ ვხედავთ პროვაიდერის სტანდარტულ სტატიას, რომელიც მიუთითებს, რომ რესურსი დაბლოკილია:

RKN ვებსაიტზე ეს დომენი რეალურად არის ჩამოთვლილი გაჩერების სიებში:

როდესაც თქვენ კითხულობთ whois-ს, ხედავთ, რომ თავად დომენი არის „დამალული“ ღრუბლოვანი პროვაიდერის Cloudflare-ის მიღმა.

მაგრამ RKN-ის „სპეციალისტებისგან“ განსხვავებით, ბილაინის უფრო ტექნიკურად განათლებულმა თანამშრომლებმა (ან ჩვენი ცნობილი მარეგულირებლის მწარე გამოცდილებით ასწავლეს) სისულელედ არ აკრძალეს საიტი IP მისამართით, არამედ დაამატეს დომენის სახელი გაჩერების სიაში. თქვენ შეგიძლიათ მარტივად გადაამოწმოთ ეს, თუ დააკვირდებით, რა სხვა დომენები იმალება იმავე IP მისამართის მიღმა, ეწვიეთ ერთ-ერთ მათგანს და დაინახავთ, რომ წვდომა არ არის დაბლოკილი:

როგორ ხდება ეს? როგორ იცის პროვაიდერის DPI რომელ დომენზეა ჩემი ბრაუზერი, რადგან ყველა კომუნიკაცია ხდება https პროტოკოლის მეშვეობით და ჩვენ ჯერ არ შევნიშნეთ ბილაინის https სერთიფიკატების ჩანაცვლება? ის ნათელმხილველია თუ მე მომყვებიან?

შევეცადოთ ამ კითხვაზე პასუხის გაცემა Wireshark-ის მეშვეობით ტრაფიკის დათვალიერებით

სკრინშოტი აჩვენებს, რომ ჯერ ბრაუზერი იღებს სერვერის IP მისამართს DNS-ის საშუალებით, შემდეგ ხდება სტანდარტული TCP ხელის ჩამორთმევა დანიშნულების სერვერთან და შემდეგ ბრაუზერი ცდილობს დაამყაროს SSL კავშირი სერვერთან. ამისათვის ის აგზავნის SSL Client Hello პაკეტს, რომელიც შეიცავს წყაროს დომენის სახელს წმინდა ტექსტში. ეს ველი საჭიროა cloudflare frontend სერვერის მიერ კავშირის სწორად მარშრუტირებისთვის. ეს არის სადაც პროვაიდერი DPI გვაჭერს, არღვევს ჩვენს კავშირს. ამავდროულად, ჩვენ არ ვღებულობთ პროვაიდერისგან რაიმე ნაკვთს და ვხედავთ ბრაუზერის სტანდარტულ შეცდომას, თითქოს საიტი გამორთულია ან უბრალოდ არ მუშაობს:

ახლა მოდით გავააქტიუროთ eSNI მექანიზმი ბრაუზერში, როგორც ეს წერია ინსტრუქციებში Firefox :
ამისათვის ჩვენ ვხსნით Firefox-ის კონფიგურაციის გვერდს შესახებ: config და გაააქტიურეთ შემდეგი პარამეტრები:

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

ამის შემდეგ ჩვენ შევამოწმებთ, რომ პარამეტრები სწორად მუშაობს cloudflare ვებსაიტზე. ლინკები და მოდით კვლავ ვცადოთ ეს ხრიკი ჩვენი ტორენტ ტრეკერით.

ვოილა. ჩვენი საყვარელი ტრეკერი გაიხსნა VPN ან პროქსი სერვერების გარეშე. მოდით ახლა გადავხედოთ სატრანსპორტო ნაგავსაყრელს wireshark-ში, რათა დავინახოთ რა მოხდა.

ამჯერად, ssl კლიენტის hello პაკეტი აშკარად არ შეიცავს დანიშნულების დომენს, მაგრამ ამის ნაცვლად, პაკეტში გამოჩნდა ახალი ველი - encrypted_server_name - აქ არის rutracker.nl-ის მნიშვნელობა და მხოლოდ cloudflare frontend სერვერს შეუძლია ამის გაშიფვრა. ველი. და თუ ასეა, მაშინ პროვაიდერ DPI-ს სხვა არჩევანი არ აქვს გარდა ხელების დაბანისა და ასეთი ტრაფიკის დაშვებისა. დაშიფვრის სხვა ვარიანტები არ არის.

ასე რომ, ჩვენ გადავხედეთ, თუ როგორ მუშაობს ტექნოლოგია ბრაუზერში. ახლა ვცადოთ მისი გამოყენება უფრო კონკრეტულ და საინტერესო საკითხებზე. და პირველ რიგში, ჩვენ ვასწავლით იგივე curl-ს eSNI-ის გამოყენებას TLS 1.3-თან მუშაობისთვის და ამავდროულად ვნახავთ, თუ როგორ მუშაობს eSNI-ზე დაფუძნებული დომენის ფრონტინგი.

დომენის ფრონტინგი eSNI-ით

გამომდინარე იქიდან, რომ curl იყენებს სტანდარტულ openssl ბიბლიოთეკას https პროტოკოლით დასაკავშირებლად, უპირველეს ყოვლისა, ჩვენ უნდა მივაწოდოთ eSNI მხარდაჭერა. ჯერ არ არის eSNI მხარდაჭერა openssl master ფილიალებში, ამიტომ ჩვენ უნდა გადმოვწეროთ სპეციალური 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 ჩართულია, მაგრამ მონიშნულია EXPERIMENTAL. გამოიყენეთ სიფრთხილით!

$ make

პაკეტის წარმატებით აშენების შემდეგ, ჩვენ გამოვიყენებთ სპეციალურ bash ფაილს, რომელიც შედის openssl-ში, curl-ის კონფიგურაციისა და გასაშვებად. მოდით დავაკოპიროთ იგი დირექტორიაში curl-ით მოხერხებულობისთვის:

cp /opt/openssl/esnistuff/curl-esni 

და გააკეთეთ ტესტი https მოთხოვნა cloudflare სერვერზე, DNS და TLS პაკეტების ერთდროულად ჩაწერა Wireshark-ში.

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

სერვერის პასუხში, openssl-დან და curl-დან გამართვის უამრავი ინფორმაციის გარდა, ჩვენ მივიღებთ HTTP პასუხს 301 კოდით cloudflare-დან.

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 ამ შემთხვევაში.

ჩანს, რომ curl პირველად მიმართა DNS სერვერს საჯარო eSNI გასაღებისთვის cloudflare სერვერისთვის - TXT DNS მოთხოვნა _esni.cloudflare.com-ზე (პაკეტი No. 13). შემდეგ, openssl ბიბლიოთეკის გამოყენებით, curl-მა გაგზავნა TLS 1.3 მოთხოვნა cloudflare სერვერზე, რომელშიც SNI ველი დაშიფრული იყო წინა ეტაპზე მიღებული საჯარო გასაღებით (პაკეტი #22). მაგრამ, გარდა eSNI ველისა, SSL-hello პაკეტი ასევე მოიცავდა ველს ჩვეულებრივი - ღია SNI, რომელიც შეგვიძლია დავაკონკრეტოთ ნებისმიერი თანმიმდევრობით (ამ შემთხვევაში - www.hello-rkn.ru).

ეს ღია SNI ველი არანაირად არ იყო გათვალისწინებული cloudflare სერვერების მიერ დამუშავებისას და მხოლოდ პროვაიდერის DPI-ს ნიღბად ემსახურებოდა. Cloudflare სერვერმა მიიღო ჩვენი ssl-hello პაკეტი, გაშიფრა eSNI, ამოიღო ორიგინალური SNI იქიდან და დაამუშავა ისე, თითქოს არაფერი მომხდარა (ეს ყველაფერი ზუსტად ისე გააკეთა, როგორც დაგეგმილი იყო eSNI-ის შემუშავებისას).

ერთადერთი, რაც ამ შემთხვევაში შეიძლება დაიჭიროთ DPI-ს თვალსაზრისით, არის პირველადი DNS მოთხოვნა _esni.cloudflare.com-ზე. მაგრამ ჩვენ გავაკეთეთ DNS მოთხოვნა ღია მხოლოდ იმის საჩვენებლად, თუ როგორ მუშაობს ეს მექანიზმი შიგნიდან.

ხალიჩის საბოლოოდ ამოსაღებად DPI-დან, ჩვენ ვიყენებთ უკვე ნახსენებ DNS-over-HTTPS მექანიზმს. მცირე ახსნა - DOH არის პროტოკოლი, რომელიც საშუალებას გაძლევთ დაიცვათ ადამიანი შუაში შეტევისგან DNS მოთხოვნის გაგზავნით HTTPS-ზე.

მოდით კვლავ შევასრულოთ მოთხოვნა, მაგრამ ამჯერად ჩვენ მივიღებთ საჯარო eSNI გასაღებებს https პროტოკოლით და არა DNS-ით:

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

მოთხოვნის ტრაფიკის ნაგავსაყრელი ნაჩვენებია ქვემოთ მოცემულ ეკრანის სურათზე:

ჩანს, რომ 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

ამ შემთხვევაში, ჩვენ მივმართეთ დაბლოკილ rutracker.nl სერვერს, DoH გადამწყვეტი dns.google (აქ არ არის შეცდომა, ახლა ცნობილ კორპორაციას აქვს თავისი პირველი დონის დომენი) და თავი დავიფარეთ სხვა დომენით, რომელიც მკაცრად არის. აკრძალულია ყველა DPI-ის დაბლოკვა სიკვდილის ტკივილის დროს. მიღებული პასუხიდან გამომდინარე, გესმით, რომ ჩვენი მოთხოვნა წარმატებით დამუშავდა.

როგორც დამატებითი შემოწმება, რომ პროვაიდერის DPI პასუხობს ღია SNI-ს, რომელსაც ჩვენ გადავცემთ საფარის სახით, ჩვენ შეგვიძლია მოვთხოვოთ rutracker.nl-ს სხვა აკრძალული რესურსის საფარქვეშ, მაგალითად, სხვა „კარგი“ ტორენტ ტრეკერით:

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

ჩვენ არ მივიღებთ პასუხს სერვერისგან, რადგან... ჩვენი მოთხოვნა დაიბლოკება DPI სისტემის მიერ.

მოკლე დასკვნა პირველი ნაწილის შესახებ

ამრიგად, ჩვენ შევძელით eSNI-ის ფუნქციონირების დემონსტრირება openssl-ისა და curl-ის გამოყენებით და გამოვცადეთ დომენის ფრონტინგის მოქმედება eSNI-ზე დაფუძნებული. ანალოგიურად, ჩვენ შეგვიძლია ჩვენი საყვარელი ხელსაწყოების ადაპტირება, რომლებიც იყენებენ openssl ბიბლიოთეკას სხვა დომენების „ნიღბის ქვეშ“ მუშაობისთვის. ამის შესახებ მეტი დეტალები ჩვენს შემდეგ სტატიებში.

წყარო: www.habr.com