WSS გვირაბის დაშიფვრა TLS-ის დამამთავრებელზე წყდება, აპლიკაციაში არა

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

ორი ფენა, რომლებიც ერთს ჰგავს

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

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

დიზაინი A: ტრანსპორტი ერთადერთი დაშიფვრაა

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

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

დიზაინი B: დატვირთვა თავის გასაღებებს ატარებს

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

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

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

თვალყური ადევნეთ, სად ჩნდება სინამდვილეში ღია ტექსტი

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

ss -tnp | grep -E ':(443|8443)\b'
ip -br link show type tun
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief
tcpdump -ni tun0 -c 5 -X

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

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

გადახედეთ ნდობას, რომელიც სინამდვილეში მიეცით

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

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

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