Kan ei server-sertifikatkjede overstyre tillitslageret til klienten?

Ein nettlesar viser ei sertifikatåtvaring på ein nettstad der kjeda er fullstendig, og den første impulsen er å reparere serveren. Vanlegvis presenterer serveren nøyaktig det han skal. Klienten avgjer kva anker han godtek, og inga ordning av mellomliggjande sertifikat kan endre den avgjerda frå den andre enden av sambandet. Den grensa forklarer det meste av det som ser ut som eit sertifikatproblem.

Valideringa køyrer på klienten, med ankera til klienten

Stivalidering tek dei presenterte sertifikata og byggjer ei kjede til eit tillitsanker som valideringssystemet allereie har. RFC 5280 skildrar den modellen, og han legg ankerutveljinga hos den lokale implementasjonen framfor hos serveren. Ein applikasjon kan leggje sin eigen policy oppå: ein festa nøkkel, eit bedriftstillitslager, eller ein strengare identitetskontroll. Sertifikatlista ein server sender, er prov som blir tilbode den prosessen, aldri ei instruks til han.

Så ei fullstendig kjede provar at serveren har delane. Ho provar ikkje at klienten vil godta dei.

For å sjå kva serveren faktisk sender, køyr openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts og tel sertifikata i utdataa. Ei ufullstendig kjede der er ei retting på serversida. Ei fullstendig kjede flyttar spørsmålet til klienten og ankera hans, der serveren ikkje har noka stemme.

Kva TLS-inspeksjon faktisk endrar

Eit inspeksjonsapparat avsluttar TLS-økta på klientsida og opnar ei separat økt til den verkelege tenesta. Klienten validerer då sertifikatet til apparatet, som må kjede til eit anker klienten stolar på. Difor får administrerte einingar inspeksjonsrota gjennom einingadministrasjon, og difor viser ei personleg eining utan ho ei åtvaring.

Ordninga er medvite og lokal. Ingenting i kjeda til den opphavlege serveren kan tvinge ein uadministrert nettlesar til å godta den erstatta identiteten, og ingenting i ho hindrar ei administrert eining i å gjere det.

VPN-terminering er ikkje HTTPS-dekryptering

Eit VPN-lag transporterer pakkar mellom ein klient og ein gateway. Å fjerne det, eller lese konfigurasjonen, avdekkjer ikkje ei HTTPS-nyttelast inni.

TLS-økta går framleis mellom nettlesaren og webserveren, med dei same valideringsreglane, med mindre noko avsluttar ho uttrykkeleg. Å forveksle dei to laga skapar ein førespurnad til VPN-administratoren om å levere sertifikatet, medan sertifikatet i spørsmålet høyrer til ein inspeksjonsproxy eller nettstaden sjølv. Spør kva komponent som presenterer sertifikatet, før du endrar eit tillitslager.

Set forventningane i komponenten du kontrollerer

Viss du driftar applikasjonen og klienten hans, definer den forventa tenesteidentiteten, dei godtekne utferdarane og eventuelle krav om festing eller klientautentisering samla. Planlegg fornying og gjenoppretting slik at ei legitim sertifikatendring ikkje blir eit avbrot. Viss du berre driftar den offentlege serveren, dokumenter kva autentisering du krev og kva klientmiljø du støttar. Å sende ei føretrekt kjede sertifiserer ikkje eininga til ein framand.

På administrert utstyr må du løyse inkompatibilitet gjennom applikasjons- og nettverkseigarane. Deaktivering av validering, tilføying av ei uforklart rot eller forsøk på å overleve ein inspeksjonspolicy etablerer ikkje det tiltenkte peer-tilhøvet.

Test resultatet på ein rein klientprofil, ikkje på maskina der eit unntak allereie er lagt til. Det er den einaste kontrollen som viser kva ei ny eining vil oppleve.