ძირითადი აუთენტიფიკაცია HTTPS-ით IPsec-ის წინააღმდეგ: რას იცავს თითოეული

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

საკონტროლო პუნქტი პირველი: ეს არის ის სერვერი, რომელსაც სურდათ ესაუბრათ

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

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

საკონტროლო პუნქტი მეორე: რა მოძრაობს რეალურად 401 გაცვლაში

HTTP ძირითადი აუთენტიფიკაცია აგზავნის მომხმარებლის იდენტიფიკატორსა და პაროლს სათაურში, Base64-ით დაშიფრულს, როგორც აღწერილია RFC 7617-ში. Authorization: Basic dXNlcjpwYXNz არის ფორმა; კოდირება შეიძლება შებრუნდეს ნებისმიერის მიერ, ვისაც შეუძლია მოთხოვნის წაკითხვა, ამიტომ მთელი საიდუმლოება მოდის ქვემოთ მდებარე ტრანსპორტიდან. curl -v აჩვენებს როგორც WWW-Authenticate: Basic გამოწვევას, ისე სათაურს, რომელსაც უკან აგზავნით.

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

სად დგას IPsec გვირაბი ამ გზაზე

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

შერჩევა ის ნაწილია, რომელზეც ადამიანები წაექცევიან. პოლიტიკაზე დაფუძნებული გვირაბები იყენებენ ტრაფიკის სელექტორებს, ხშირად წვდომის კონტროლის სიების სახით გამოხატულს, რათა გადაწყვიტონ, რომელი პაკეტები შედის გვირაბში. მარშრუტზე დაფუძნებული გვირაბები სამაგიეროდ იყენებენ ვირტუალურ ინტერფეისს და მარშრუტიზაციის ცხრილს. Linux-ში ip xfrm policy აჩვენებს სელექტორებს და ip xfrm state აჩვენებს დამყარებულ უსაფრთხოების ასოციაციებს; ქსელური ფარის მოწყობილობაში ეკვივალენტია გვირაბის SA ცხრილი პლუს პაკეტების მაძიებელი.

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

წაიკითხეთ მარცხი იმ დონეზე, რომელმაც შეატყობინა

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

გამოიყენეთ მტკიცებულებები, რომლებსაც თითოეული დონე აწარმოებს: ბრაუზერის ქსელური პანელი სტატუსებისა და სათაურებისთვის, openssl s_client -connect host:443 სერტიფიკატების ჯაჭვისთვის, კარიბჭის SA მრიცხველები და ჟურნალები გვირაბის ტრაფიკისთვის, და აპლიკაციის ჟურნალი ანგარიშის გადაწყვეტილებისთვის. როცა ორი დონე ერთდროულად იტყობინება შეცდომებს, ჯერ ქვედა გაასწორეთ, რადგან მკვდარ გვირაბს ადვილად შეუძლია დაფაროს აუთენტიფიკაციის მარცხი და პირიქით.

დაასახეთ ერთი სერვისი თავიდან ბოლომდე

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

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

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