Закачињање TLS-а и VPN приступ одговарају на различита питања

Ставите приватну мобилну апликацију иза VPN-а и разумна особа ће питати да ли јој је још потребно закачињање сертификата. Питање звучи као избор између две равноправне контроле, а заправо је питање о две различите капије. VPN одлучује сме ли овај уређај уопште да користи путању; апликација одлучује да ли је сервер који је достигла онај који је очекивала. Одговорите на оба одвојено и дизајн постаје једноставнији.

Две капије, два питања

Приступ мрежи тиче се клијента: да ли је овај уређај уписан, да ли је његов акредитив ваљан и да ли му политика дозвољава ову путању? Поверење апликације тиче се сервера: да ли је веза стигла до услуге са идентитетом који апликација прихвата? Ови одговори долазе из различитих система, падају из различитих разлога и поправљају их различити тимови. VPN руковање може успети док апликација разговара са истеклим сертификатом иза партнера. Беспрекорно закачена апликација ипак може остати недоступна свима, јер уређај никада није дошао на мрежу.

Оба се сабирају. Изостављање једног уклања контролу; додавање другог га не замењује.

Шта закачињање заиста ограничава

Закачињање сужава скуп идентитета сервера које ће апликација прихватити, обично именујући јавни кључ или хеш сертификата уместо да верује сваком ланцу за који би неко складиште јемчило. То је ограничење наложено на уобичајену проверу, а не њена замена. Уобичајена провера одговара да ли је ланац уопште поуздан; закачињање одговара да ли је то ланац који ова апликација очекује. Имплементација која прескочи први корак није добила безбедност, само новину.

Објекат који се закачиња разликује се међу платформама, па сама реч говори врло мало. Копирање хеша из складишта поверења једног производа и третирање као исте ствари у мобилној апликацији честа је и тиха грешка.

Закачињање на платформи је конфигурација, не политика

Android излаже закачињање кроз своју конфигурацију мрежне безбедности, где скуп закачињања држи сажетке јавног кључа и ланац мора да садржи барем један од њих. Та датотека је по апликацији и тражи намерну промену билда. iOS нема еквивалентан механизам манифеста, па закачињање тамо живи у сопственом коду за процену поверења апликације.

Пошто се механизам разликује, захтев се мора писати по платформи. Политика која каже закачи сертификат без именовања платформе није спроводива.

Ротација одлучује да ли закачињање преживљава

Тешки део није прво издање, него обнова сертификата након њега. Строга политика поверења одбија легитиман нови кључ једнако чврсто као и нападачев.

Два механизма чине ротацију преживљивом: резервно закачињање којем се верује пре него што затреба, и датум истека на скупу закачињања да се спровођење заврши уместо да блокира апликацију. Оба су политичке одлуке, а истек је посебно намерно смањење безбедности, не безазлен тајмер. Именујте ко контролише билд апликације, TLS крајњу тачку и обнову сертификата, и ставите их у један процес промене. Ако су то три различита тима, закачињање ће на крају изазвати испад који нико није планирао.

Изгубљени уређај је трећи проблем

Опозив VPN акредитива не завршава нужно сесију апликације, а закачињање сервера не чини баш ништа за телефон у туђој руци. Закључавање уређаја, чување акредитива, трајање сесије и даљински опозив одвојене су одлуке са одвојеним власницима. Ако их савијете у расправу о закачињању, гарантовано се ниједна од њих неће пројектовати.

Тестирајте четири односа уместо оног једног који видите: намеравани сервер и операцију, рачун који треба да буде одбијен, идентитет сервера који треба да буде одбачен и планирану ротацију. Исправан VPN вежба само први. Запишите шта је сваки тест доказао, јер ће следећа особа претпоставити да зелени тунел значи да су сва четири прошла.