OpenVPN EC ED-ის წინააღმდეგ: რატომ არ არიან ეს სახელები სიძლიერის კიბე
EC, ED, ECDHE და auth სხვადასხვა კითხვას პასუხობენ. სანამ რამეს შეადარებთ ან შეცვლით, დაალაგეთ OpenVPN პროფილი თითოეული სახელის საქმის მიხედვით.
მოათავსეთ ec, ed, ecdh, ecdsa, auth და TLS-ის შიფრების სია გვერდიგვერდ ერთ პროფილში და ფაილი დაიწყებს ექვსპოზიციიანი სიძლიერის ღილაკის მსგავსად გამოჩენას. მაგრამ ასე არ არის. ყოველი სახელი განსხვავებულ კითხვას პასუხობს და ორი პროფილი, რომლებიც ერთ-ერთში განსხვავდებიან, სულაც არ არიან ერთმანეთზე ძლიერები ან სუსტები. სახელების მათი საქმის მიხედვით დალაგებას დაახლოებით ხუთი წუთი სჭირდება და ხელს უშლის ცუდ შესწორებათა უმეტესობას, რომლებსაც ადამიანები მომუშავე კონფიგურაციაში აკეთებენ.
ქვემოთ მოცემული დალაგება იწყება თავად დაბნეულობით და შემდეგ მიემართება გარეთ, პროფილის იმ ნაწილებისკენ, რომლებიც ნამდვილად წყვეტენ, რა იცავს თქვენს ტრაფიკს. ყოველი განყოფილება რიგრიგობით იღებს ერთ არასწორ კითხვას და აჩვენებს, რასთან არის სახელი სინამდვილეში მიბმული.
ორი ასო, ორი განსხვავებული კითხვა
ყველაზე მეტ კამათს იწვევს წყვილი EC და ED და კამათი ჩვეულებრივ ვარაუდობს, რომ ისინი ერთ კითხვაზე მეტოქე პასუხები არიან. ისინი ერთ ღერძზეც კი არ არიან. EC აღწერს მათემატიკის ოჯახს: ელიფსური მრუდის კრიპტოგრაფიას, სადაც უსაფრთხოება მოდის მრუდზე დისკრეტული ლოგარითმის სირთულიდან და არა დიდ სასრულ ველში.
ED აღწერს მრუდის ფორმას ამ ოჯახის შიგნით. Twisted Edwards მრუდები წარმოდგენაა, რომელიც არჩეულია სიჩქარისა და რამდენიმე იმპლემენტაციის შეცდომისადმი გამძლეობის გამო, და Ed25519 არის ის სახელი, რომელსაც ადამიანები ჩვეულებრივ გულისხმობენ. მრუდი არ არის ელიფსური მრუდის კრიპტოგრაფიის კონკურენტი; ის ელიფსური მრუდის ჩაწერის ერთ-ერთი გზაა. ED-ის წაკითხვა როგორც "უფრო ახალი, უფრო ძლიერი EC" პირველი არასწორი მოსახვევია და ყველაფერი მის შემდეგ, როგორც წესი, არასწორია იმავე მიმართულებით.
ხელმოწერა და გაცვლა ცალკე საქმეებია
მას შემდეგ, რაც ოჯახის კითხვა გადაწყდება, დარჩენილი სახელები ორ სვეტად იყოფა, რომლებიც არასდროს ანაცვლებენ ერთმანეთს. ერთი სვეტი ხელს აწერს, მეორე თანხმდება საერთო საიდუმლოზე.
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
EdDSA და ECDSA ორივე ხელს აწერს, მაგრამ ისინი სხვადასხვა სქემებია განსხვავებული გასაღების ფორმატებით, ამიტომ ერთისთვის გაცემული სერტიფიკატი მეორის სახით გამოუსადეგარია. EdDSA განსაზღვრულია მრუდების მცირე სიმრავლისთვის; P-256 მათ შორის არ არის, ამიტომ P-256 სერტიფიკატი მოწმდება ECDSA-ით და არასდროს Ed25519-ით.
გაცვლის სვეტს არ აქვს EdDH სახელის ეკვივალენტი. ეფემერული შეთანხმება Curve25519 გასაღებზე არის X25519 და ეს არის ECDH გარკვეული მრუდით, ზუსტად ისე, როგორც P-256-ის შემთხვევაში. Ed25519 მკაცრად ნიშნავს ხელმოწერის სქემას, თუმცა სახელი თავისუფლად გამოიყენება გაცვლისთვის, რადგან ორი მრუდი დაკავშირებულია: ხელმოწერისთვის გამოყენებული Edwards ფორმა და X25519-ისთვის გამოყენებული Montgomery ფორმა ერთსა და იმავე ფუძე ჯგუფს აღწერენ.
რატომ არ აქვს EC პროფილს dh ფაილი
dh ფაილი შეიცავს წინასწარ გენერირებულ პარამეტრებს სასრული ველის Diffie-Hellman-ისთვის და ეს პარამეტრები არსებობს იმიტომ, რომ დიდი მარტივი რიცხვი და გენერატორი საიდანღაც უნდა მოვიდეს. ელიფსური მრუდის გაცვლას ისინი არ სჭირდება: დასახელებული მრუდი პარამეტრების სიმრავლეა და ორივე მხარემ ის უკვე იცის. ეს არის სრული მიზეზი, თუ რატომ შეიძლება EC პროფილმა გამოტოვოს დირექტივა.
ორი სიტუაცია მაინც წარმოქმნის dh ხაზს პროფილში, რომელიც სხვაგვარად თანამედროვე ჩანს. პირველია მეორე მსმენელი ან უფრო ძველი პარტნიორი, რომელიც ნამდვილად აწარმოებს მოლაპარაკებას სასრული ველის ჯგუფებზე. მეორეა RSA ეპოქის შაბლონიდან კოპირებული და არასდროს წაშლილი ნაშთი ტექსტი. პროფილი, რომელიც გაცვლისთვის მრუდს ასახელებს და მაინც ტვირთავს 2048-ბიტიან dh ფაილს, ამის გაკეთების გამო უფრო უსაფრთხო არ ხდება; ის ატარებს გამოუყენებელ არტეფაქტს.
TLS 1.3-მა გასაღების გაცვლა სახელიდან მოხსნა
შეადარეთ TLS_AES_256_GCM_SHA384 და TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 და მოკლე სახელი დაქვეითებად გამოიყურება. ეს გადარქმევაა და მიზეზი სტრუქტურულია: TLS 1.3-მა მოხსნა სტატიკური RSA და სასრული ველის Diffie-Hellman გასაღების გაცვლა, ამიტომ ეფემერული ელიფსური მრუდის გაცვლა ერთადერთი დარჩენილი არა-PSK ვარიანტია. მისი დასახელება ყოველ კომპლექტში იმავე ფაქტს ათეულჯერ გაიმეორებდა.
სერტიფიკატის ტიპი სახელიდან დაკავშირებული მიზეზით გაქრა. 1.3-ში სერტიფიკატი ადასტურებს ხელის ჩამორთმევის ხელმოწერას და არა გასაღების შეთანხმებას, ამიტომ ის აღარ ირჩევს კომპლექტს. სწორედ ამიტომ არსებობს კონფიგურაციაში 1.3-ისთვის ცალკე შიფრთა სია: კომპლექტები გადაერქვა და გადაჯგუფდა, არ დასუსტებულან.
ერთი შედეგი ღიად ღირს ითქვას. ECDHE გასაღების გაცვლის ალგორითმია და არასდროს შიფრი. "ელიფსურად" აღწერილი კომპლექტი რაღაცას ამბობს იმაზე, თუ როგორ მივიდნენ ორი მხარე საერთო გასაღებამდე, და არაფერს იმაზე, თუ რა შიფრავს შემდეგ სასარგებლო დატვირთვას.
auth პაკეტებს ადასტურებს და არა დატვირთვას
auth დირექტივა ირჩევს HMAC კონდენსატს, რომელიც პაკეტებს ადასტურებს, და მისი ისტორიული ნაგულისხმევი მნიშვნელობა SHA1-ია. არა-AEAD მონაცემთა შიფრით OpenVPN კონდენსატს შიფრტექსტზე ითვლის და უმატებს მას, ეს არის დაშიფვრა-შემდეგ-MAC წყობა, რომელიც ბალიშთან მანიპულირებას არაპრაქტიკულს ხდის.
აქ მითი ისაა, რომ auth-ის SHA512-მდე აწევა ტუნელს ამაგრებს. ეს დაშიფვრის სიძლიერეს არ ზრდის და თუ შეთანხმებული მონაცემთა შიფრი AEAD რეჟიმია, როგორიცაა AES-256-GCM, კონდენსატი მონაცემთა პაკეტებზე საერთოდ არ გამოიყენება. GCM ტეგი მათ უკვე ადასტურებს და auth მნიშვნელობა რჩება საკონტროლო არხის HMAC-ისთვის და ჯერ კიდევ გამოყენებული ნებისმიერი არა-AEAD შიფრისთვის.
ამრიგად დირექტივა მნიშვნელოვანია, მაგრამ უფრო ვიწრო ადგილას მნიშვნელოვანია, ვიდრე მისი პოზიცია ფაილში მიანიშნებს. იმის შემოწმება, თუ რომელი შიფრი იყო რეალურად შეთანხმებული, გეუბნებათ, საერთოდ ხომ არ ვრცელდება ის.
წაიკითხეთ პროფილი სვეტებად და არა რიგებად
სამი კითხვა სუფთად ჰყოფს ფენებს და თითოეულ მათგანს შეთანხმებული სესიის სხვადასხვა ნაწილი პასუხობს. რომელი შიფრი იცავს სასარგებლო დატვირთვას? რომელი ტეგი ან კონდენსატი იძლევა გარანტიას თითოეულ პაკეტზე და გამოყენებულ შიფრს საერთოდ სჭირდება ის? ვისმა სერტიფიკატმა დახურა ხელის ჩამორთმევა და დამატებით დაცულია თუ არა საკონტროლო არხი tls-auth-ით ან tls-crypt-ით?
EC ან ED ეტიკეტში არაფერი წყვეტს ამ სამიდან არც ერთს და კომპლექტის სახელი მარტო თავისითაც არ წყვეტს არც ერთ მათგანს. შეთანხმებული შედეგი ერთადერთი მტკიცებულებაა, ამიტომ წაიკითხეთ ის და ნუ გამოიტანთ სიძლიერეს ლექსიკიდან:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logპირველი ბრძანება გეუბნებათ, თუ რომელ ხელმოწერის სქემას იყენებს თქვენი სერტიფიკატი სინამდვილეში, და ეს არის ერთადერთი საიმედო გზა იმის გასაგებად, მუშაობთ თუ არა ECDSA-ით თუ Ed25519-ით. მეორე აჩვენებს საკონტროლო არხის იმ ხაზს, რომელიც კლიენტმა სესიისთვის ჩაწერა, მათ შორის TLS ვერსიას და იმ კომპლექტს, რომელზეც შეჩერდა. თუ პროფილის შესწორება ამ ორი გამონატანიდან ერთითაც ვერ გამართლდება, ეს სავარაუდოდ სახელის და არა თვისების ცვლილებაა.