TLS piespraušana un VPN piekļuve atbild uz dažādiem jautājumiem

Novietojiet privātu mobilo lietotni aiz VPN, un saprātīgs cilvēks jautās, vai tai joprojām vajag sertifikāta piespraušanu. Jautājums izklausās kā izvēle starp divām līdzvērtīgām kontroles metodēm, un patiesībā tas ir jautājums par diviem dažādiem vārtiem. VPN izlemj, vai šī ierīce vispār drīkst izmantot ceļu; lietotne izlemj, vai sasniegtais serveris ir tas, kuru tā gaidīja. Atbildiet uz abiem atsevišķi, un dizains kļūs vienkāršāks.

Divi vārti, divi jautājumi

Piekļuve tīklam attiecas uz klientu: vai šī ierīce ir reģistrēta, vai tās akreditācijas dati ir derīgi un vai politika to laiž šajā ceļā? Lietotnes uzticēšanās attiecas uz serveri: vai savienojums sasniedza pakalpojumu ar identitāti, kuru lietotne pieņem? Šīs atbildes nāk no dažādām sistēmām, neizdodas dažādu iemeslu dēļ, un tās labo dažādas komandas. VPN rokasspiediens var izdoties, kamēr lietotne runā ar novecojušu sertifikātu aiz partnera. Perfekti piesprausta lietotne tomēr var palikt nesasniedzama visiem, jo ierīce nekad nav nonākusi tīklā.

Abi summējas. Viena izlaišana noņem kontroli; otra pievienošana to neaizstāj.

Ko piespraušana patiešām ierobežo

Piespraušana sašaurina servera identitāšu kopu, ko lietotne pieņems, parasti nosaucot publisko atslēgu vai sertifikāta jaucējvērtību, nevis uzticoties katrai ķēdei, par kuru galvotu kāda krātuve. Tas ir ierobežojums, kas uzlikts parastajai validācijai, nevis tās aizstājējs. Parastā validācija atbild, vai ķēde vispār ir uzticama; piespraušana atbild, vai tā ir ķēde, kuru šī lietotne gaida. Ieviešana, kas izlaiž pirmo soli, nav ieguvusi drošību, tikai jaunumu.

Piespraužamais objekts atšķiras starp platformām, tāpēc vārds vien pats par sevi pasaka ļoti maz. Nokopēt jaucējvērtību no viena produkta uzticības krātuves un mobilajā lietotnē to uzskatīt par to pašu ir izplatīta un klusa kļūda.

Piespraušana platformā ir konfigurācija, nevis politika

Android atklāj piespraušanu ar savu tīkla drošības konfigurāciju, kur piespraušanas kopa glabā publiskās atslēgas kopsavilkumus un ķēdē jābūt vismaz vienam no tiem. Šis fails ir katram lietojumam atsevišķi un prasa apzinātu būvējuma izmaiņu. iOS nav līdzvērtīga manifesta mehānisma, tāpēc tur piespraušana dzīvo pašas lietotnes uzticības novērtēšanas kodā.

Tā kā mehānisms atšķiras, prasība jāraksta katrai platformai. Politika, kas saka piespraudiet sertifikātu, nenosaucot platformu, nav īstenojama.

Rotācija izlemj, vai piespraušana izdzīvos

Grūtā daļa nav pirmā laidiens, bet gan sertifikāta atjaunošana pēc tā. Stingra uzticības politika noraida likumīgu jaunu atslēgu tikpat stingri kā uzbrucēja atslēgu.

Divi mehānismi padara rotāciju pārdzīvojamu: rezerves piespraušana, kurai uzticas jau pirms tās vajadzības, un derīguma termiņš piespraušanas kopai, lai izpilde beigtos, nevis lietotni nobloķētu. Abi ir politikas lēmumi, un termiņš jo īpaši ir apzināta drošības samazināšana, nevis nekaitīgs taimeris. Nosauciet, kas pārvalda lietotnes būvējumu, TLS galapunktu un sertifikāta atjaunošanu, un savediet tos vienā izmaiņu procesā. Ja tie ir trīs dažādas komandas, piespraušana galu galā izraisīs pārtraukumu, ko neviens nebija plānojis.

Pazaudēta ierīce ir trešā problēma

VPN akreditācijas datu atsaukšana ne vienmēr beidz lietotnes sesiju, un servera piespraušana absolūti neko nedara ar tālruni cita cilvēka rokā. Ierīces bloķēšana, akreditācijas datu glabāšana, sesijas ilgums un attālināta atsaukšana ir atsevišķi lēmumi ar atsevišķiem īpašniekiem. To ielocīšana piespraušanas diskusijā garantē, ka neviens no tiem netiks projektēts.

Pārbaudiet četras attiecības tās vienas vietā, ko redzat: paredzēto serveri un darbību, kontu, kuram vajadzētu atteikt, servera identitāti, kuru vajadzētu noraidīt, un plānoto rotāciju. Strādājošs VPN trenē tikai pirmo. Pierakstiet, ko pierādīja katrs tests, jo nākamais cilvēks pieņems, ka zaļš tunelis nozīmē, ka visi četri izturēja.