შეიძლება სერვერის სერტიფიკატების ჯაჭვმა კლიენტის ნდობის საცავი გააუქმოს?

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

ვალიდაცია ხდება კლიენტზე, კლიენტის წამყვანებით

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

ამრიგად, სრული ჯაჭვი ამტკიცებს, რომ სერვერს ნაწილები აქვს. ის არ ამტკიცებს, რომ კლიენტი მათ მიიღებს.

იმის სანახავად, თუ რას აგზავნის სერვერი სინამდვილეში, გაუშვით openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts და დათვალეთ სერტიფიკატები გამოსავალში. იქ არასრული ჯაჭვი სერვერის მხრიდან შესწორებაა. სრული ჯაჭვი კითხვას კლიენტსა და მის წამყვანებთან გადააქვს, სადაც სერვერს ხმა არ აქვს.

რას ცვლის სინამდვილეში TLS-ის შემოწმება

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

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

VPN-ის დასრულება HTTPS-ის გაშიფვრა არ არის

VPN ფენა პაკეტებს გადაიტანს კლიენტსა და კარიბჭეს შორის. მისი მოცილება, ან მისი კონფიგურაციის წაკითხვა, არ ამჟღავნებს შიგნით არსებულ HTTPS დატვირთვას.

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

დააყენეთ მოლოდინები იმ კომპონენტში, რომელსაც აკონტროლებთ

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

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

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