TLS-kiinnitys ja VPN-pääsy vastaavat eri kysymyksiin

Laita yksityinen mobiilisovellus VPN:n taakse, niin järkevä ihminen kysyy, tarvitseeko se yhä sertifikaatin kiinnitystä. Kysymys kuulostaa valinnalta kahden samanarvoisen valvonnan välillä, ja se on oikeastaan kysymys kahdesta eri portista. VPN päättää, saako tämä laite ylipäätään käyttää polkua; sovellus päättää, onko saavutettu palvelin se, jota odotettiin. Vastaa molempiin erikseen, niin suunnittelusta tulee yksinkertaisempaa.

Kaksi porttia, kaksi kysymystä

Verkkoon pääsy koskee asiakasta: onko tämä laite rekisteröity, onko sen tunniste voimassa ja salliiko käytäntö sen tälle polulle? Sovelluksen luottamus koskee palvelinta: saavuttiko yhteys palvelun, jonka identiteetin sovellus hyväksyy? Nämä vastaukset tulevat eri järjestelmistä, epäonnistuvat eri syistä ja eri tiimit korjaavat ne. VPN-kättely voi onnistua, kun sovellus puhuu vertaiskumppanin takana vanhentuneen sertifikaatin kanssa. Täydellisesti kiinnitetty sovellus voi silti olla kaikkien ulottumattomissa, koska laite ei koskaan päässyt verkkoon.

Molemmat lisääntyvät. Toisen pois jättäminen poistaa valvonnan; toisen lisääminen ei korvaa sitä.

Mitä kiinnitys todella rajaa

Kiinnitys kaventaa palvelinidentiteettien joukkoa, jonka sovellus hyväksyy, yleensä nimeämällä julkisen avaimen tai sertifikaatin tiivisteen sen sijaan, että luotettaisiin jokaiseen ketjuun, jonka jokin varasto takaisi. Se on tavallisen validoinnin päälle asetettu rajoitus, ei sen korvike. Tavallinen validointi vastaa, onko ketju ylipäätään luotettava; kiinnitys vastaa, onko se ketju, jota tämä sovellus odottaa. Toteutus, joka ohittaa ensimmäisen vaiheen, ei ole voittanut turvallisuutta, vain uutuutta.

Kiinnitettävä objekti vaihtelee alustoittain, joten sana yksin kertoo hyvin vähän. Tiivisteen kopioiminen yhden tuotteen luottamusvarastosta ja sen pitäminen samana asiana mobiilisovelluksessa on yleinen ja hiljainen virhe.

Kiinnitys alustalla on asetusta, ei käytäntöä

Android tarjoaa kiinnityksen verkon suoja-asetustensa kautta, joissa kiinnitysjoukko sisältää julkisen avaimen tiivisteitä ja ketjussa on oltava ainakin yksi niistä. Tämä tiedosto on sovelluskohtainen ja vaatii tarkoituksellisen build-muutoksen. iOS:llä ei ole vastaavaa manifestimekanismia, joten kiinnitys elää siellä sovelluksen omassa luottamuksen arviointikoodissa.

Koska mekanismi eroaa, vaatimus on kirjoitettava alustoittain. Käytäntö, joka sanoo kiinnitä sertifikaatti nimeämättä alustaa, ei ole toteutettavissa.

Kierto ratkaisee, jääkö kiinnitys eloon

Vaikea osa ei ole ensimmäinen julkaisu, vaan sitä seuraava sertifikaatin uusinta. Tiukka luottamuskäytäntö hylkää laillisen uuden avaimen yhtä lujasti kuin hyökkääjän avaimen.

Kaksi mekanismia tekee kierrosta kestettävää: varakiinnitys, johon luotetaan jo ennen kuin sitä tarvitaan, ja kiinnitysjoukon vanhenemispäivä, jotta valvonta lakkaa eikä sovellus mene jumiin. Molemmat ovat käytäntöpäätöksiä, ja juuri vanheneminen on tarkoituksellinen turvallisuuden vähennys, ei harmiton ajastin. Nimeä, kuka hallitsee sovelluksen buildia, TLS-päätepistettä ja sertifikaatin uusintaa, ja vie ne yhteen muutosprosessiin. Jos ne ovat kolme eri tiimiä, kiinnitys aiheuttaa lopulta katkoksen, jota kukaan ei suunnitellut.

Kadonnut laite on kolmas ongelma

VPN-tunnisteen peruuttaminen ei välttämättä lopeta sovelluksen istuntoa, eikä palvelinkiinnitys tee yhtään mitään toisen kädessä olevalle puhelimelle. Laitelukitus, tunnisteiden säilytys, istunnon kesto ja etäperuutus ovat erillisiä päätöksiä erillisine omistajineen. Niiden taittaminen kiinnityskeskusteluun takaa, ettei yhtäkään niistä suunnitella.

Testaa neljää suhdetta sen yhden sijaan, jonka näet: aiottu palvelin ja toiminto, tili joka pitäisi hylätä, palvelinidentiteetti joka pitäisi torjua, ja suunniteltu kierto. Toimiva VPN harjoittaa vain ensimmäistä. Kirjoita muistiin, mitä kukin testi todisti, sillä seuraava henkilö olettaa vihreän tunnelin tarkoittavan, että kaikki neljä menivät läpi.