Poate un lanț de certificate al serverului să suprascrie depozitul de încredere al clientului?

Un browser afișează un avertisment de certificat pe un site al cărui lanț este complet, iar primul instinct este să reparăm serverul. De obicei serverul prezintă exact ce ar trebui. Clientul decide ce ancore acceptă, iar nicio aranjare a certificatelor intermediare nu poate schimba această decizie de la celălalt capăt al conexiunii. Această limită explică majoritatea a ceea ce pare a fi o problemă de certificat.

Validarea rulează la client, cu ancorele clientului

Validarea căii ia certificatele prezentate și construiește un lanț până la o ancoră de încredere pe care sistemul de validare o are deja. RFC 5280 descrie acest model și așează alegerea ancorei la implementarea locală, nu la server. O aplicație poate adăuga propria politică peste: o cheie fixată, un depozit de încredere al întreprinderii, sau o verificare de identitate mai strictă. Lista de certificate pe care o trimite un server este o dovadă oferită acelui proces, niciodată o instrucțiune adresată lui.

Așadar, un lanț complet dovedește că serverul are piesele. Nu dovedește că clientul le va accepta.

Pentru a vedea ce trimite de fapt serverul, rulați openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts și numărați certificatele din ieșire. Un lanț incomplet acolo este o corecție pe partea serverului. Un lanț complet mută întrebarea la client și la ancorele sale, unde serverul nu are vot.

Ce schimbă de fapt inspecția TLS

Un dispozitiv de inspecție termină sesiunea TLS pe partea clientului și deschide o sesiune separată către serviciul real. Clientul validează apoi certificatul dispozitivului, care trebuie să se înlănțuie până la o ancoră în care clientul are încredere. De aceea dispozitivele administrate primesc rădăcina de inspecție prin administrarea dispozitivelor și de aceea un dispozitiv personal fără ea afișează un avertisment.

Aranjamentul este deliberat și local. Nimic din lanțul serverului original nu poate forța un browser neadministrat să accepte identitatea substitută, și nimic din el nu împiedică un dispozitiv administrat să facă acest lucru.

Terminarea VPN nu este decriptare HTTPS

Un strat VPN transportă pachete între un client și o poartă. Eliminarea lui, sau citirea configurației sale, nu expune o încărcătură HTTPS în interior.

Sesiunea TLS rulează în continuare între browser și serverul web, cu aceleași reguli de validare, dacă ceva nu o termină în mod explicit. Confundarea celor două straturi produce o cerere către administratorul VPN de a furniza certificatul, în timp ce certificatul în cauză aparține unui proxy de inspecție sau site-ului însuși. Întrebați ce componentă prezintă certificatul înainte de a schimba orice depozit de încredere.

Stabiliți așteptările în componenta pe care o controlați

Dacă operați aplicația și clientul ei, definiți împreună identitatea de serviciu așteptată, emitenții acceptați și orice cerință de fixare sau autentificare a clientului. Planificați reînnoirea și recuperarea astfel încât o schimbare legitimă de certificat să nu devină o întrerupere. Dacă operați doar serverul public, documentați ce autentificare cereți și ce medii de client acceptați. Trimiterea unui lanț preferat nu certifică dispozitivul unui necunoscut.

Pe echipamente administrate, rezolvați incompatibilitatea prin responsabilii aplicației și ai rețelei. Dezactivarea verificării, adăugarea unei rădăcini neexplicate sau încercarea de a depăși o politică de inspecție nu stabilesc relația de parteneri dorită.

Testați rezultatul pe un profil de client curat, nu pe mașina pe care s-a adăugat deja o excepție. Este singura verificare care arată ce va experimenta un dispozitiv nou.