Kan en servercertifikatkæde tilsidesætte klientens tillidslager?

En browser viser en certifikatadvarsel på et websted, hvis kæde er fuldstændig, og den første impuls er at rette serveren. Normalt præsenterer serveren præcis det, den skal. Klienten afgør, hvilke ankre den accepterer, og intet arrangement af mellemliggende certifikater kan ændre den beslutning fra den anden ende af forbindelsen. Den grænse forklarer det meste af det, der ligner et certifikatproblem.

Valideringen kører på klienten, med klientens ankre

Stivalidering tager de præsenterede certifikater og bygger en kæde til et tillidsanker, som valideringssystemet allerede har. RFC 5280 beskriver den model, og den placerer ankerudvælgelsen hos den lokale implementering frem for hos serveren. En applikation kan tilføje sin egen politik ovenpå: en fastgjort nøgle, et virksomhedstillidslager, eller et strengere identitetstjek. Den certifikatliste, en server sender, er bevis tilbudt den proces, aldrig en instruks til den.

Så en fuldstændig kæde beviser, at serveren har delene. Den beviser ikke, at klienten vil acceptere dem.

For at se, hvad serveren faktisk sender, kør openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts og tæl certifikaterne i outputtet. En ufuldstændig kæde der er en rettelse på serversiden. En fuldstændig kæde flytter spørgsmålet til klienten og dens ankre, hvor serveren ingen stemme har.

Hvad TLS-inspektion faktisk ændrer

Et inspektionsapparat afslutter TLS-sessionen på klientsiden og åbner en separat session til den rigtige tjeneste. Klienten validerer derefter apparatets certifikat, som skal kæde til et anker, klienten stoler på. Derfor modtager administrerede enheder inspektionsroden via enhedsadministration, og derfor viser en personlig enhed uden den en advarsel.

Arrangementet er bevidst og lokalt. Intet i den oprindelige servers kæde kan tvinge en uadministreret browser til at acceptere den substituerede identitet, og intet i den forhindrer en administreret enhed i at gøre det.

VPN-terminering er ikke HTTPS-dekryptering

Et VPN-lag transporterer pakker mellem en klient og en gateway. At fjerne det eller læse dets konfiguration afslører ikke en HTTPS-nyttelast indeni.

TLS-sessionen kører stadig mellem browseren og webserveren, med de samme valideringsregler, medmindre noget udtrykkeligt afslutter den. At forveksle de to lag skaber en anmodning til VPN-administratoren om at levere certifikatet, mens certifikatet i spørgsmål tilhører en inspektionsproxy eller selve webstedet. Spørg, hvilken komponent der præsenterer certifikatet, før du ændrer et tillidslager.

Sæt forventningerne i den komponent, du styrer

Hvis du driver applikationen og dens klient, skal du definere den forventede tjenesteidentitet, de accepterede udstedere og eventuelle krav om fastgørelse eller klientautentificering samlet. Planlæg fornyelse og gendannelse, så en legitim certifikatændring ikke bliver et afbrud. Hvis du kun driver den offentlige server, skal du dokumentere, hvilken autentificering du kræver, og hvilke klientmiljøer du understøtter. At sende en foretrukket kæde certificerer ikke en fremmeds enhed.

På administreret udstyr skal du løse inkompatibilitet gennem applikations- og netværksejerne. Deaktivering af validering, tilføjelse af en uforklaret rod eller forsøg på at overleve en inspektionspolitik etablerer ikke det tilsigtede peer-forhold.

Test resultatet på en ren klientprofil, ikke på maskinen, hvor en undtagelse allerede er tilføjet. Det er det eneste tjek, der viser, hvad en ny enhed vil opleve.