TLS 1.3 კვლავ აგზავნის სერვერის სახელს ღია ტექსტით

მსმენელის TLS 1.3-ზე განახლება ცვლის იმას, რისი წაკითხვაც დამკვირვებელს შეუძლია, მაგრამ არა იმდენად, რამდენსაც ვერსიის ნომერი მიანიშნებს. ClientHello კვლავ მოძრაობს ნებისმიერი დაშიფვრის შეთანხმებამდე და ჩვეულებრივ კავშირში მოთხოვნილი სერვერის სახელი იქ ღია ტექსტად დგას. Encrypted Client Hello არის მექანიზმი, რომელიც მას მალავს, და ეს ცალკე განლაგებაა საკუთარი წინაპირობებით. შეასრულეთ ეს ოთხი ნაბიჯი, სანამ დაწერთ პოლიტიკას, რომელიც ორიდან ერთ ქცევას ითვალისწინებს.

რას ამჟღავნებს ხელის ჩამორთმევა სინამდვილეში

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

ECH-ის სპეციფიკაცია, RFC 9849 ცვლის ამას შიდა ClientHello-ის დაშიფვრით თანამშრომელი სერვერისთვის. გარე ხელის ჩამორთმევა რჩება და ატარებს საჯარო სახელს, რომელსაც ქსელი ხედავს, ამიტომ განლაგებას კვლავ სჭირდება გარე იდენტობა, რომელიც შუამავლებისთვის აზრს შეიცავს. ეს გარე სახელი ის ნაწილია, რომელსაც ადამიანები გამოტოვებენ, როცა ელიან, რომ კავშირი ანონიმური გახდება. ეს არის საფარი სახელი, არა დამალული სახელი, და ის უნდა გადაწყდეს და ავთენტიფიცირდეს როგორც ნებისმიერი სხვა.

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

წაიკითხეთ ClientHello ვარაუდის ნაცვლად

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

openssl s_client -connect app.plant.example:443 -servername app.plant.example -tls1_3 </dev/null> 2>/dev/null | head -20
sudo tcpdump -ni eth0 -c 40 'tcp port 443' -w /tmp/tls.pcap
tshark -r /tmp/tls.pcap -Y 'tls.handshake.extensions_server_name' -T fields -e tls.handshake.extensions_server_name

პირველი ბრძანება ასრულებს ხელის ჩამორთმევას და აჩვენებს შეთანხმებულ პარამეტრებს, მათ შორის პროტოკოლის ვერსიას და თქვენ მიერ მოთხოვნილ სახელს. მეორე იჭერს რეალური კავშირის პირველ პაკეტებს, ხოლო მესამე ამოიღებს SNI ველს ამ ჩაწერიდან. თუ ველი შევსებულია, თქვენ მიერ იმიტირებულ დამკვირვებელს შეუძლია მისი წაკითხვა.

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

ECH გაფართოებას მოეკიდეთ როგორც მტკიცებას, არა როგორც მტკიცებულებას

ClientHello-ში ECH გაფართოების დანახვა არ ნიშნავს, რომ კავშირმა ECH გამოიყენა. კლიენტები GREASE ECH-ს აგზავნიან, როცა გამოსაყენებელი კონფიგურაცია არ აქვთ, სწორედ იმისთვის, რომ მათი ხელის ჩამორთმევები ერთგვაროვნად გამოიყურებოდეს. გაფართოება არსებობს, შიდა hello სატყუარაა და ნამდვილი სახელი კვლავ წაკითხვადია.

dig +short HTTPS app.plant.example
openssl s_client -connect app.plant.example:443 -tls1_3 -status </dev/null> 2>/dev/null | grep -i -E 'ech|status_request'

პირველი ბრძანება აჩვენებს, აქვეყნებს თუ არა წყარო HTTPS რესურსის ჩანაწერს ECH კონფიგურაციის პარამეტრით, და ასე სწავლობენ კლიენტები გასაღებს. მეორე ეძებს ხელის ჩამორთმევის სტატუსის ინფორმაციას, თუმცა კლიენტის წარმატების შეტყობინება უფრო ძლიერი მტკიცებულებაა. მიღებაა მთავარი: სერვერს, რომელსაც შესაბამისი გასაღები არ აქვს, არ შეუძლია შიდა hello-ს გაშიფვრა და კავშირი უკან იხევს.

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

ჩაწერეთ დამკვირვებლის ფარგლები პოლიტიკაში

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

თუ კონტროლი დამოკიდებულია SNI-ის წაკითხვაზე, გამოსცადეთ, როგორ იქცევიან განლაგებული კლიენტები, როცა ECH ხელმისაწვდომია და როცა არა. შემდეგ ჩაწერეთ თავსებადობის შედეგი, რადგან ფილტრი, რომელიც ჩუმად წყვეტს შესაბამისობას, უარესია, ვიდრე ის, რომელიც არასდროს განლაგებულა.

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