რატომ არ აღწერს AES-256 VPN-ის დაშიფვრის კრებულს
კრებული ასრულებს ოთხ როლს: მასიური დაშიფვრა, მთლიანობა, გასაღების დაყენება და პარტნიორის ავთენტიფიკაცია. შიფრის სახელი მხოლოდ ერთ მათგანს ფარავს, ერთ დონეზე.
იკითხეთ, რა დაშიფვრას იყენებს VPN და პასუხი ჩვეულებრივ ერთი სიტყვით მოდის: AES-256, ან ChaCha20, ან იქნებ WireGuard. ეს პასუხი ასახელებს ერთი დონის ერთ კომპონენტს, მაშინ როცა კავშირს რეალურად იცავს ოთხი სხვადასხვა როლის შემსრულებელი ალგორითმების ერთობლიობა. კომპონენტისა და განლაგების არევა ამ საუბრებში ყველაზე გავრცელებული შეცდომაა და წარმოშობს შედარებებს, რომლებიც ვერ გადაწყდება.
ოთხი საქმე ერთ კავშირში
მასიური დაშიფვრა ღია ტექსტს მონაცემთა არხისთვის დაშიფრულ ტექსტად აქცევს და მისი გასაღები გამოითვლება, არა გადაიცემა. მთლიანობის დაცვა ცვლილებას ამჩნევს, რაც ცალკე საქმეა, თუნდაც ერთი კონსტრუქცია ორივეს აკეთებდეს. გასაღების დაყენება ქმნის საერთო ტრაფიკის მასალას, ხოლო პარტნიორის ავთენტიფიკაცია წყვეტს, ვინ არის მეორე მხარეს. თუ ერთი მათგანი აკლია, კავშირი დაცული არ არის, რაც არ უნდა ძლიერი იყოს დარჩენილი ნაწილი.
ზოგიერთი ნახაზი ორ როლს ერთში აერთიანებს. AES-GCM და ChaCha20-Poly1305 ავთენტიფიცირებული დაშიფვრის კონსტრუქციებია, ამიტომ კონფიდენციალურობა და მთლიანობა ერთად მოდის; AES-CBC ასეთი არ არის და საჭიროებს ცალკე შეტყობინების ავთენტიფიკაციის კოდს საკუთარი გასაღებით. ამიტომ წინადადების დამოუკიდებელი რიცხვების ტომრად წაკითხვა არასწორად კითხულობს წყვილებად დაპროექტებულებს.
როლები სხვადასხვა დონეზეა განლაგებული, ამიტომ ერთი და იგივე სიტყვა ორ პროდუქტში სხვადასხვას ნიშნავს. ბლოკური შიფრი ESP-ში და ბლოკური შიფრი TLS-ში ერთი და იგივე პრიმიტივია სხვადასხვა მოლაპარაკებაში, სხვადასხვა მოთხოვნით. ამიტომ პრიმიტივის ხსენება მისი რეჟიმისა და დონის გარეშე შეიძლება უარესი იყოს, ვიდრე არაფრის ხსენება.
რატომ თითქმის არაფერს ამბობს შიფრის სახელი
ერთი წუთით სერიოზულად მიიღეთ გამოთქმა AES-256: ის აღნიშნავს ბლოკურ შიფრს და გასაღების ზომას. არაფერს ამბობს მუშაობის რეჟიმზე, მთლიანობის უზრუნველყოფაზე, გასაღებების დაყენების ან პარტნიორის ავთენტიფიკაციის წესზე. ორ პროდუქტს შეუძლია ორივემ გამოაცხადოს AES-256 და განსხვავდებოდეს ყველა სხვა რამეში, მათ შორის ერთი არაავთენტიფიცირებული რეჟიმით და მეორე AEAD რეჟიმითა და თანამედროვე გასაღების გაცვლით.
TLS 1.3-მა ეს გამიჯვნა სტანდარტში შეიტანა, რაც სასარგებლო შესწორებაა ყველასთვის, ვინც ძველი ლექსიკა ისწავლა. მისი შიფრული კრებულები მხოლოდ AEAD-ს და ჰეშს ასახელებენ, ხოლო გასაღების გაცვლის ჯგუფები და ხელმოწერის ალგორითმები ცალკე პარამეტრებად ითარგმნება. ამიტომ TLS 1.3-ის კრებულის სახელი შეუდარებელია TLS 1.2-ის კრებულის სახელთან თანაბარ პირობებში, თუმცა ორივე კონფიგურაციის ფაილის ერთსა და იმავე ველში ჩანს. აუდიტორი, რომელიც ორ სტრიქონს პირდაპირ ადარებს, იღებს დასკვნას, რომელსაც პროტოკოლი არ უჭერს მხარს. წაიკითხეთ აგრეთვე შეთანხმებული ჯგუფი და ხელმოწერის პარამეტრები, თორემ შედარება არასრულია.
WireGuard საპირისპირო გზას ირჩევს და მოლაპარაკებას თითქმის მთლიანად აშორებს: პროტოკოლი ფიქსირებულ ალგორითმთა კრებულს განსაზღვრავს, ამიტომ ორი იმპლემენტაცია ან ერთად მუშაობს, ან არა. ეს ლეგიტიმური დიზაინის არჩევანია და იმასაც ნიშნავს, რომ კითხვას, რომელ კრებულს ათანხმებს WireGuard, შედარების ღირსი პასუხი არ აქვს. თუ აუდიტს აკეთებთ, წაიკითხეთ სპეციფიკაცია ერთხელ და შემდეგ აუდიტი გაუკეთეთ მის გარშემო გასაღების მართვას და არა მოლაპარაკებას.
დონე განსაზღვრავს ლექსიკას
IPsec-ის განლაგება ორჯერ აწარმოებს მოლაპარაკებას: IKE-ის წინადადება საკონტროლო არხისთვის და ESP-ის გარდაქმნა მონაცემებისთვის, და ორივე ლეგიტიმურად შეიძლება განსხვავდებოდეს. პირველის წაკითხვა და ვარაუდი, რომ ის მეორეს აღწერს, აუდიტის დროს დაბნეულობის ჩვეულებრივი წყაროა, რადგან კონფიგურაციის ფაილი ორივეს ახსენებს და საინტერესო მეორეა.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
ერთ ბიბლიოთეკაში ხელმისაწვდომი სახელი ავტომატურად არ ინერგება სხვა მონაცემთა გზისთვის. ამიტომ მტკიცება, რომ ჩვენი პროდუქტი მხარს უჭერს AES-256-ს, უფრო სუსტია, ვიდრე ჟღერს, და ამიტომ თავსებადობის პრობლემა ჩვეულებრივ გვარდება შენარჩუნებული კვეთის მოძებნით და არა ორივე მხარეს ყველა ძველი ალგორითმის ჩართვით.
TLS 1.3-ის სპეციფიკაცია ამ გამიჯვნის ყველაზე ნათელი გამოქვეყნებული მაგალითია, რადგან კრებულს წყვილად განსაზღვრავს და დანარჩენს საკუთარ მოლაპარაკებაში გადააქვს. როცა ეს ფორმა ნაცნობია, IPsec-ის წინადადება და WireGuard-ის ერთი ფიქსირებული კრებული ერთი და იმავე იდეის ვარიანტებად იკითხება.
წაიკითხეთ შეთანხმებული შედეგი და შემდეგ გაჩერდით
კონფიგურირებული წინადადება არ არის მტკიცებულება იმისა, თუ რა აირჩიეს ორმა პარტნიორმა. ცოცხალი სესია ატარებს პასუხს და ნებისმიერ ჩვეულებრივ იმპლემენტაციას შეუძლია მისი შეტყობინება პაკეტების დაჭერის გარეშე.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showგამოსავალში წაიკითხეთ შერჩეული ალგორითმები და არა შემოთავაზებული სია. თუ პასუხი უფრო სუსტია, ვიდრე პოლიტიკა ვარაუდობდა, შესწორება ერთი მხარის წინადადების კონფიგურაციაშია, და შეუთანხმებლობა თანამედროვე იმპლემენტაციებში ჩვეულებრივ ჩავარდნილ მოლაპარაკებად ჩანს და არა ჩუმ დაქვეითებად.
შემდეგ გაიხსენეთ, რას არ ფარავს კრებული. მარშრუტები, აპლიკაციის ნებართვები, ჟურნალირება და შენახვა ცალკე გადაწყვეტილებებია საკუთარი განხილვით, და თავსებადი კრიპტოგრაფიული განლაგება მათზე არაფერს ამბობს. შიფრის განხილვა ღირს, მაგრამ ის უფრო ვიწრო კითხვას პასუხობს, ვიდრე ის, რასაც ადამიანების უმეტესობა რეალურად სვამს.
შეინარჩუნეთ ლექსიკა ზუსტი და არგუმენტი მოკლდება. კრებული დონეზე არსებული როლების ერთობლიობაა, შიფრი ერთი კომპონენტია, და შეთანხმებული შედეგი ერთადერთია, რაც აღწერს იმ კავშირს, რომელიც რეალურად გაქვთ. დანარჩენი ყველაფერი შედარებაში მშვენიერებაა.