Kan en server-sertifikatkjede overstyre klientens tillitslager?

En nettleser viser en sertifikatadvarsel på et nettsted der kjeden er fullstendig, og den første impulsen er å reparere serveren. Vanligvis presenterer serveren nøyaktig det den skal. Klienten bestemmer hvilke ankere den godtar, og ingen ordning av mellomliggende sertifikater kan endre den beslutningen fra den andre enden av forbindelsen. Den grensen forklarer det meste av det som ser ut som et sertifikatproblem.

Valideringen kjører på klienten, med klientens ankere

Stivalidering tar de presenterte sertifikatene og bygger en kjede til et tillitsanker som valideringssystemet allerede har. RFC 5280 beskriver den modellen, og den plasserer ankerutvelgelsen hos den lokale implementasjonen fremfor hos serveren. En applikasjon kan legge sin egen policy på toppen: en festet nøkkel, et bedriftsstillitslager, eller en strengere identitetskontroll. Sertifikatlisten en server sender, er bevis som tilbys den prosessen, aldri en instruks til den.

Så en fullstendig kjede beviser at serveren har delene. Den beviser ikke at klienten vil godta dem.

For å se hva serveren faktisk sender, kjør openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts og tell sertifikatene i utdataene. En ufullstendig kjede der er en rettelse på serversiden. En fullstendig kjede flytter spørsmålet til klienten og dens ankere, der serveren ikke har noen stemme.

Hva TLS-inspeksjon faktisk endrer

Et inspeksjonsapparat avslutter TLS-økten på klientsiden og åpner en separat økt til den virkelige tjenesten. Klienten validerer deretter apparatets sertifikat, som må kjede til et anker klienten stoler på. Derfor mottar administrerte enheter inspeksjonsroten gjennom enhetsadministrasjon, og derfor viser en personlig enhet uten den en advarsel.

Ordningen er bevisst og lokal. Ingenting i den opprinnelige serverens kjede kan tvinge en uadministrert nettleser til å godta den erstattede identiteten, og ingenting i den hindrer en administrert enhet i å gjøre det.

VPN-terminering er ikke HTTPS-dekryptering

Et VPN-lag transporterer pakker mellom en klient og en gateway. Å fjerne det, eller lese konfigurasjonen, avdekker ikke en HTTPS-nyttelast inni.

TLS-økten går fortsatt mellom nettleseren og webserveren, med de samme valideringsreglene, med mindre noe avslutter den uttrykkelig. Å forveksle de to lagene skaper en forespørsel til VPN-administratoren om å levere sertifikatet, mens sertifikatet i spørsmålet tilhører en inspeksjonsproxy eller nettstedet selv. Spør hvilken komponent som presenterer sertifikatet, før du endrer et tillitslager.

Sett forventningene i komponenten du kontrollerer

Hvis du drifter applikasjonen og klienten, definer den forventede tjenesteidentiteten, de aksepterte utstederne og eventuelle krav om festing eller klientautentisering samlet. Planlegg fornyelse og gjenoppretting slik at en legitim sertifikatendring ikke blir et avbrudd. Hvis du bare drifter den offentlige serveren, dokumenter hvilken autentisering du krever og hvilke klientmiljøer du støtter. Å sende en foretrukket kjede sertifiserer ikke en fremmeds enhet.

På administrert utstyr må du løse inkompatibilitet gjennom applikasjons- og nettverkseierne. Deaktivering av validering, tilføyelse av en uforklart rot eller forsøk på å overleve en inspeksjonspolicy etablerer ikke det tiltenkte peer-forholdet.

Test resultatet på en ren klientprofil, ikke på maskinen der et unntak allerede er lagt til. Det er den eneste kontrollen som viser hva en ny enhet vil oppleve.