Voiko palvelimen varmenteketju ohittaa asiakkaan luottamusvaraston?

Selain näyttää varoituksen varmenteesta sivustolla, jonka ketju on täydellinen, ja ensimmäinen vaisto on korjata palvelin. Yleensä palvelin esittää juuri sen, mitä sen pitääkin. Asiakas päättää, mitkä ankkurit se hyväksyy, eikä mikään välivarmenteiden järjestely voi muuttaa tätä päätöstä yhteyden toisesta päästä. Tämä raja selittää suurimman osan siitä, mikä näyttää varmenteen ongelmalta.

Validointi tapahtuu asiakkaassa, asiakkaan ankkureilla

Polun validointi ottaa esitetyt varmenteet ja rakentaa ketjun luottamusankkuriin, joka validoivalla järjestelmällä on jo. RFC 5280 kuvaa tämän mallin ja sijoittaa ankkurin valinnan paikalliseen toteutukseen eikä palvelimeen. Sovellus voi lisätä oman käytäntönsä sen päälle: kiinnitetty avain, yrityksen luottamusvarasto, tai tiukempi henkilöllisyyden tarkistus. Palvelimen lähettämä varmenteiden luettelo on todiste, joka tarjotaan tälle prosessille, ei koskaan käsky sille.

Täydellinen ketju siis todistaa, että palvelimella on osat. Se ei todista, että asiakas hyväksyy ne.

Nähdäksesi, mitä palvelin todella lähettää, suorita openssl s_client -connect app.example.net:443 -servername app.example.net -showcerts ja laske tulosteen varmenteet. Epätäydellinen ketju siellä on palvelinpuolen korjaus. Täydellinen ketju siirtää kysymyksen asiakkaalle ja sen ankkureille, missä palvelimella ei ole ääntä.

Mitä TLS-tarkastus todella muuttaa

Tarkastuslaite päättää asiakaspuolen TLS-istunnon ja avaa erillisen istunnon varsinaiseen palveluun. Asiakas validoi sitten laitteen varmenteen, jonka on ketjujen ankkuriin, johon asiakas luottaa. Siksi hallitut laitteet saavat tarkastusjuuren laitehallinnan kautta, ja siksi henkilökohtainen laite ilman sitä näyttää varoituksen.

Järjestely on tahallinen ja paikallinen. Mikään alkuperäisen palvelimen ketjussa ei voi pakottaa hallitsematonta selainta hyväksymään korvaavaa henkilöllisyyttä, eikä mikään siinä estä hallittua laitetta tekemästä niin.

VPN:n päättäminen ei ole HTTPS:n salauksen purkamista

VPN-kerros kuljettaa paketteja asiakkaan ja yhdyskäytävän välillä. Sen poistaminen tai sen kokoonpanon lukeminen ei paljasta sisällä olevaa HTTPS-hyötykuormaa.

TLS-istunto kulkee edelleen selaimen ja verkkopalvelimen välillä samoilla validointisäännöillä, ellei jokin nimenomaisesti päätä sitä. Kahden kerroksen sekoittaminen synnyttää pyynnön VPN-ylläpitäjälle varmenteen toimittamisesta, vaikka kyseinen varmenne kuuluu tarkastusvälityspalvelimelle tai sivustolle itselleen. Kysy, mikä komponentti esittää varmenteen, ennen kuin muutat mitään luottamusvarastoa.

Aseta odotukset komponentissa, jota hallitset

Jos ylläpidät sovellusta ja sen asiakasta, määrittele yhdessä odotettu palveluidentiteetti, hyväksytyt myöntäjät ja mahdollinen kiinnitys- tai asiakastodennusvaatimus. Suunnittele uusiminen ja palautuminen niin, ettei laillinen varmennemuutos muutu katkokseksi. Jos ylläpidät vain julkista palvelinta, dokumentoi, mitä todennusta vaadit ja mitä asiakasympäristöjä tuet. Ensisijaisen ketjun lähettäminen ei todista vieraan laitetta.

Hallituilla laitteilla ratkaise yhteensopimattomuus sovelluksen ja verkon omistajien kautta. Vahvistuksen poistaminen käytöstä, selittämättömän juuren lisääminen tai yritys kestää tarkastuskäytäntöä ei perusta aiottua vertaissuhdetta.

Testaa tulos puhtaassa asiakasprofiilissa, älä koneella, johon poikkeus on jo lisätty. Se on ainoa tarkistus, joka näyttää, mitä uusi laite kokee.