Vai servera sertifikātu ķēde var ignorēt klienta uzticības krātuvi?

Pārlūks rāda sertifikāta brīdinājumu vietnē, kuras ķēde ir pilna, un pirmais instinkts ir labot serveri. Parasti serveris uzrāda tieši to, ko vajadzētu. Klients izlemj, kuras enkurus tas pieņem, un nekāds starpposma sertifikātu izvietojums nevar mainīt šo lēmumu no savienojuma otras puses. Šī robeža izskaidro lielāko daļu tā, kas izskatās pēc sertifikāta problēmas.

Validācija notiek klientā, ar klienta enkuriem

Ceļa validācija ņem uzrādītos sertifikātus un veido ķēdi līdz uzticības enkuram, kas validācijas sistēmai jau ir. RFC 5280 apraksta šo modeli, un tas enkura izvēli nodod vietējai implementācijai, nevis serverim. Lietotne var tam virsū pievienot savu politiku: fiksētu atslēgu, uzņēmuma uzticības krātuvi, vai stingrāku identitātes pārbaudi. Servera sūtītais sertifikātu saraksts ir pierādījums, kas tiek piedāvāts šim procesam, nekad ne norādījums tam.

Tātad pilna ķēde pierāda, ka serverim ir daļas. Tā nepierāda, ka klients tās pieņems.

Lai redzētu, ko serveris faktiski sūta, palaidiet openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts un saskaitiet sertifikātus izvadā. Nepilna ķēde tur ir servera puses labojums. Pilna ķēde pārvieto jautājumu pie klienta un tā enkuriem, kur serverim nav balss.

Ko TLS pārbaude faktiski maina

Pārbaudes ierīce pārtrauc klienta puses TLS sesiju un atver atsevišķu sesiju uz īsto pakalpojumu. Pēc tam klients validē ierīces sertifikātu, kuram jābūt ķēdē līdz enkuram, kam klients uzticas. Tāpēc pārvaldītās ierīces saņem pārbaudes sakni caur ierīču pārvaldību, un tāpēc personīga ierīce bez tās rāda brīdinājumu.

Izkārtojums ir apzināts un vietējs. Nekas oriģinālā servera ķēdē nevar piespiest nepārvaldītu pārlūku pieņemt aizstājējidentitāti, un nekas tajā neliedz pārvaldītai ierīcei to darīt.

VPN pārtraukšana nav HTTPS atšifrēšana

VPN slānis pārvadā paketes starp klientu un vārteju. Tā noņemšana vai konfigurācijas lasīšana neatklāj iekšienē esošo HTTPS kravu.

TLS sesija joprojām notiek starp pārlūku un tīmekļa serveri, ar tiem pašiem validācijas noteikumiem, ja vien kaut kas to skaidri nepārtrauc. Abu slāņu sajaukšana rada pieprasījumu VPN administratoram piegādāt sertifikātu, lai gan attiecīgais sertifikāts pieder pārbaudes starpniekam vai pašai vietnei. Pajautājiet, kurš komponents uzrāda sertifikātu, pirms maināt jebkuru uzticības krātuvi.

Nosakiet gaidas komponentā, kuru kontrolējat

Ja pārvaldāt lietotni un tās klientu, kopīgi definējiet gaidīto pakalpojuma identitāti, pieņemtos izdevējus un jebkuru fiksēšanas vai klienta autentifikācijas prasību. Plānojiet atjaunošanu un atkopšanu tā, lai likumīga sertifikāta maiņa nekļūtu par pārtraukumu. Ja pārvaldāt tikai publisko serveri, dokumentējiet, kādu autentifikāciju pieprasāt un kuras klientu vides atbalstāt. Vēlamās ķēdes sūtīšana nesertificē svešinieka ierīci.

Pārvaldītā aparatūrā nesaderību risiniet ar lietotnes un tīkla īpašniekiem. Validācijas izslēgšana, neizskaidrotas saknes pievienošana vai mēģinājums pārdzīvot pārbaudes politiku neizveido iecerētās vienlīdzīgās attiecības.

Pārbaudiet rezultātu tīrā klienta profilā, nevis mašīnā, kur izņēmums jau pievienots. Tā ir vienīgā pārbaude, kas parāda, ko pieredzēs jauna ierīce.