OpenVPN-ის ჟურნალი: საკონტროლო არხის შიფრი და მონაცემთა არხის შიფრი
ჟურნალში DHE-RSA-AES256-SHA აღწერს TLS-ის საკონტროლო არხს და არა შიფრს, რომელიც თქვენს ტრაფიკს იცავს. იპოვეთ მონაცემთა არხის ცალკე შედეგი.
ჟურნალის სტრიქონი, რომელშიც მოხსენიებულია DHE-RSA-AES256-SHA, არ არის მთლიანი კავშირის შეჯამება. ის ეკუთვნის TLS-ის ხელის ჩამორთმევას, რომელიც საკონტროლო არხს იცავს, ხოლო გვირაბის შიგნით ტრაფიკი შეიძლება სულ სხვა რამით დაშიფრული იყოს. მისი VPN-ის მონაცემთა შიფრად წარმოდგენა ის შეცდომაა, რომელიც უნდა აირიდოთ.
მნიშვნელოვანია ორი შედეგი და ისინი სხვადასხვა კითხვას პასუხობენ. ერთი საკონტროლო არხისთვის შეთანხმებული TLS-ის კრებულია, მეორე კი გვირაბის მიერ გადატანილი პაკეტების მონაცემთა შიფრი.
ორი შედეგი, ორი კითხვა
საკონტროლო არხი ატარებს ხელის ჩამორთმევას და წყვილებს შორის მართვის შეტყობინებებს. მის შიფრს TLS-ის სტეკი ირჩევს, ამიტომ სახელი TLS-ის კონვენციებს მიჰყვება. მონაცემთა არხი ატარებს მომხმარებლის ტრაფიკს და კონფიგურირდება OpenVPN-ის საკუთარი შიფრის მოლაპარაკებით.
გადაწყვიტეთ, რომელ კითხვას პასუხობთ, სანამ რომელიმე სტრიქონს წაიკითხავთ. დაშიფრულია თუ არა გვირაბი და ძლიერია თუ არა ხელის ჩამორთმევა, ერთი და იგივე კითხვა არ არის.
სასარგებლოა ჟურნალის ის ამონაწერი, რომელიც ორივე სტრიქონს აჩვენებს. წაიკითხეთ საკონტროლო სტრიქონი TLS-ის ვერსიისა და კრებულისთვის, ხოლო მონაცემთა სტრიქონი იმ ალგორითმისთვის, რომელიც ტვირთს რეალურად იცავს.
გაშიფრეთ TLS-ის კრებულის სახელი მის კონტექსტში
OpenSSL-ის სტილის ისტორიულ სახელში, როგორიცაა DHE-RSA-AES256-SHA, თითოეული კომპონენტი განსხვავებულ გადაწყვეტილებას აღწერს. DHE არის დროებითი Diffie-Hellman გასაღების შეთანხმება, RSA არის ავთენტიფიკაციის მეთოდი, AES256 არის AES-256 CBC რეჟიმში TLS-ის ჩანაწერებისთვის, და SHA არის SHA-1-ზე დაფუძნებული ჩანაწერის MAC.
ბოლო კომპონენტი სერტიფიკატის თითის ანაბეჭდი არ არის და მისი ასე წაკითხვა გავრცელებული შეცდომაა. სახელი თავისთავად არ გეუბნებათ პროტოკოლის ვერსიას, რადგან TLS 1.3 სულ სხვა დასახელების სქემას იყენებს. TLS_AES_256_GCM_SHA384 მიჰყვება იმ უფრო ახალ ფორმას, სადაც ბოლო ჰეში კრებულის აგების ნაწილია და არა MAC-ის არჩევანი. კომპონენტებად წაკითხვა მხოლოდ ძველ დასახელების სტილს გამოიყენეთ.
OpenSSL-ის კრებულების ცნობარი ამ სახელებს მათ განმარტებებს უკავშირებს, თუ რომელიმე კომპონენტი უცნობია.
წაიკითხეთ მონაცემთა არხის შედეგი გადატანილი ტრაფიკისთვის
გადატანილი ტრაფიკისთვის წაიკითხეთ მონაცემთა არხის სტრიქონი იმავე სესიიდან. კონფიგურაციაში data-ciphers სია დაშვებული ნაკრებია და არა მტკიცება, რომ რომელიმე კონკრეტული ალგორითმი შეთანხმდა. ჟურნალი არჩევანს იწერს, კონფიგურაცია კი მენიუს ინახავს.
AEAD შიფრი, როგორიცაა AES-GCM, საკუთარ მთლიანობის შემოწმებას ატარებს, ამიტომ ცალკე მონაცემთა არხის HMAC ამ გზის ნაწილი არ არის.
auth დირექტივა არ აუმჯობესებს TLS-ს, სერტიფიკატებს ან მონაცემთა შიფრს. ის ირჩევს digest-ს პროტოკოლის იმ ნაწილებისთვის, რომლებიც ჯერ კიდევ იყენებენ მას, ხოლო AEAD მონაცემთა შიფრით ცალკე მონაცემთა HMAC კონფიგურირებადი არ არის.
შეინახეთ იდენტობის შემოწმებები შიფრის შედეგის გარეთ
სერტიფიკატის ხელმოწერის ალგორითმი, ნდობის ჯაჭვის ვალიდაცია და წყვილის სახელის შემოწმება კიდევ სამი თვისებაა, რომლებზეც შიფრის სახელი არაფერს ამბობს. ვადაგასული სერტიფიკატი ვერ გაივლის, რამდენადაც ძლიერი არ უნდა იყოს კრებული. არასწორი სერვერის სახელი იმავენაირად ვერ გაივლის. პროფილში digest-ის პარამეტრის გასწორება არც ერთს არ არემონტებს.
ეს შემოწმებები შეინახეთ მიმოხილვის ჩანაწერებში შიფრის შედეგის გვერდით და არა მასში გაერთიანებული.
ჩაწერეთ მიმდინარე სესიის შეთანხმებული შედეგები
აიღეთ მიმდინარე კავშირის შედეგები და მათთან ერთად ჩაწერეთ კლიენტისა და სერვერის ვერსიები. მხოლოდ დამატებადი ჟურნალი შეიძლება შეიცავდეს ძველი სესიის სტრიქონს და მისი მიმდინარედ ციტირება იწვევს იმას, რომ გამოსწორებული პრობლემა თითქოს გრძელდება.
პოლიტიკის მიმოხილვისთვის კონფიგურაციის მფლობელს გადაეცით შეთანხმებული TLS-ის ვერსია და კრებული, არჩეული მონაცემთა შიფრი და სერტიფიკატის ვალიდაციის პარამეტრები ერთად. შეცვალეთ ეს ფენა, შემდეგ წაიკითხეთ ახალი ჟურნალი ახალი შეთანხმებული მნიშვნელობების დასადასტურებლად.