Може ли ланац сертификата сервера да поништи складиште поверења клијента?
Пун ланац је доказ, а не упутство. Провера се обавља на клијенту са његовим сопственим сидрима, тако да ниједан сервер не може да наметне одлуку о поверењу.
Прегледач приказује упозорење о сертификату на сајту чији је ланац пун, и први инстинкт је поправити сервер. Обично сервер приказује управо оно што треба. Клијент одлучује која сидра прихвата, и никакав распоред посредних сертификата не може да промени ту одлуку са другог краја везе. Та граница објашњава већину онога што изгледа као проблем са сертификатом.
Провера се обавља на клијенту, са сидрима клијента
Провера путање узима приказане сертификате и гради ланац до сидра поверења које систем за проверу већ има. RFC 5280 описује тај модел и смешта избор сидра у локалну имплементацију, а не на сервер. Апликација може да дода своју политику поврх тога: фиксиран кључ, корпоративно складиште поверења, или строжу проверу идентитета. Списак сертификата који сервер шаље је доказ понуђен том процесу, никада упутство њему.
Дакле, пун ланац доказује да сервер има делове. Не доказује да ће их клијент прихватити.
Да бисте видели шта сервер заиста шаље, покрените openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts и пребројте сертификате у излазу. Непотпун ланац тамо је исправка на страни сервера. Пун ланац премешта питање на клијента и његова сидра, где сервер нема глас.
Шта TLS провера заиста мења
Уређај за проверу завршава TLS сесију на страни клијента и отвара одвојену сесију ка стварној услузи. Клијент затим проверава сертификат уређаја, који мора да се ланчано повеже до сидра коме клијент верује. Зато управљани уређаји добијају корен провере кроз управљање уређајима, и зато лични уређај без њега приказује упозорење.
Распоред је намеран и локалан. Ништа у ланцу оригиналног сервера не може да присили неуправљани прегледач да прихвати заменски идентитет, и ништа у њему не спречава управљани уређај да то уради.
Завршетак VPN-а није дешифровање HTTPS-а
VPN слој преноси пакете између клијента и мрежног пролаза. Његово уклањање, или читање његове конфигурације, не открива HTTPS терет унутра.
TLS сесија се и даље одвија између прегледача и веб сервера, са истим правилима провере, осим ако је нешто експлицитно не заврши. Мешање два слоја ствара захтев администратору VPN-а да обезбеди сертификат, док сертификат у питању припада инспекцијском проксију или самом сајту. Питајте која компонента приказује сертификат пре него што промените било које складиште поверења.
Поставите очекивања у компоненти коју контролишете
Ако управљате апликацијом и њеним клијентом, заједно дефинишите очекивани идентитет услуге, прихваћене издаваоце и сваки захтев за фиксирање или клијентску аутентификацију. Планирајте обнову и опоравак тако да легитимна промена сертификата не постане прекид. Ако управљате само јавним сервером, документујте какву аутентификацију захтевате и која клијентска окружења подржавате. Слање пожељног ланца не цертификује уређај странца.
На управљаној опреми некомпатибилност решавајте кроз власнике апликације и мреже. Искључивање верификације, додавање необјашњеног корена или покушај да се надживи инспекцијска политика не успостављају предвиђени однос страна.
Тестирајте резултат на чистом клијентском профилу, а не на машини на коју је већ додат изузетак. То је једина провера која показује шта ће нови уређај доживети.