Kan ’n sertifikaatketting van die bediener die kliënt se vertrouensbewaarplek oorheers?

’n Blaaier wys ’n sertifikaatwaarskuwing op ’n webwerf waarvan die ketting volledig is, en die eerste instink is om die bediener reg te maak. Gewoonlik bied die bediener net dit wat hy moet. Die kliënt besluit watter ankers hy aanvaar, en geen rangskikking van tussenliggende sertifikate kan daardie besluit van die ander kant van die verbinding verander nie. Daardie grens verklaar die meeste van wat na ’n sertifikaatprobleem lyk.

Validasie loop op die kliënt, met die kliënt se ankers

Padvalidering neem die aangebode sertifikate en bou ’n ketting na ’n vertrouensanker wat die valideringstelsel reeds het. RFC 5280 beskryf daardie model, en dit plaas ankerkeuse by die plaaslike implementering eerder as by die bediener. ’n Toepassing kan sy eie beleid daarboop voeg: ’n vasgepen sleutel, ’n ondernemingsvertrouensbewaarplek, of ’n strenger identiteitskontrole. Die sertifikaatlys wat ’n bediener stuur, is bewys wat aan daardie proses gebied word, nooit ’n opdrag aan hom nie.

Dus bewys ’n volledige ketting dat die bediener die stukke het. Dit bewys nie dat die kliënt hulle sal aanvaar nie.

Om te sien wat die bediener werklik stuur, voer openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts uit en tel die sertifikate in die uitset. ’n Onvolledige ketting daar is ’n regstelling aan die bedienerkant. ’n Volledige ketting skuif die vraag na die kliënt en sy ankers, waar die bediener geen stem het nie.

Wat TLS-inspeksie werklik verander

’n Inspeksietoestel beëindig die kliëntkant se TLS-sessie en open ’n aparte sessie na die werklike diens. Die kliënt valideer dan die toestel se sertifikaat, wat na ’n anker moet lei wat die kliënt vertrou. Dit is waarom bestuurde toestelle die inspeksiewortel deur toestelbestuur ontvang, en waarom ’n persoonlike toestel sonder dit ’n waarskuwing wys.

Die reëling is doelbewus en plaaslik. Niks in die oorspronklike bediener se ketting kan ’n onbestuurde blaaier dwing om die vervangende identiteit te aanvaar nie, en niks daarin verhoed ’n bestuurde toestel om dit te doen nie.

VPN-beëindiging is nie HTTPS-dekripsie nie

’n VPN-laag dra pakkette tussen ’n kliënt en ’n poort. Om dit te verwyder, of om sy konfigurasie te lees, stel nie ’n HTTPS-lading daarbinne bloot nie.

Die TLS-sessie loop steeds tussen die blaaier en die webbediener, met dieselfde validasiereëls, tensy iets dit uitdruklik beëindig. Om die twee lae te verwar, lei tot ’n versoek dat die VPN-administrateur die sertifikaat verskaf, terwyl die sertifikaat in kwessie aan ’n inspeksieproxy of aan die webwerf self behoort. Vra watter komponent die sertifikaat aanbied voordat enige vertrouensbewaarplek verander word.

Stel verwagtinge in die komponent wat jy beheer

As jy die toepassing en sy kliënt bestuur, definieer die verwagte diensidentiteit, die aanvaarde uitreikers en enige vaspenning- of kliëntverifikasievereiste saam. Beplan hernuwing en herstel so dat ’n wettige sertifikaatverandering nie ’n onderbreking word nie. As jy net die openbare bediener bestuur, dokumenteer watter verifikasie jy vereis en watter kliëntomgewings jy ondersteun. Om ’n voorkeurketting te stuur sertifiseer nie ’n vreemdeling se toestel nie.

Op bestuurde toerusting, los onverenigbaarheid deur die toepassing- en netwerkeienaars op. Om verifikasie te deaktiveer, ’n onverklaarde wortel by te voeg, of te probeer om ’n inspeksiebeleid te oorleef, vestig nie die beoogde eweknieverhouding nie.

Toets die resultaat op ’n skoon kliëntprofiel, nie op die masjien waar reeds ’n uitsondering bygevoeg is nie. Dit is die enigste kontrole wat wys wat ’n nuwe toestel sal ervaar.