Закріплення TLS і доступ через VPN відповідають на різні питання

Поставте приватний мобільний застосунок за VPN, і розважлива людина запитає, чи потрібне йому ще закріплення сертифіката. Питання звучить як вибір між двома рівноцінними засобами контролю, а насправді це питання про двоє різних воріт. VPN вирішує, чи може цей пристрій узагалі користуватися шляхом; застосунок вирішує, чи той сервер він досяг, якого очікував. Дайте відповідь на обидва окремо, і проєкт стане простішим.

Двоє воріт, два питання

Доступ до мережі стосується клієнта: чи зареєстрований цей пристрій, чи чинні його облікові дані й чи дозволяє політика цей шлях? Довіра застосунку стосується сервера: чи з’єднання дійшло до служби з ідентичністю, яку застосунок приймає? Ці відповіді надходять із різних систем, зазнають невдачі з різних причин і виправляються різними командами. Рукостискання VPN може вдатися, поки застосунок говорить із простроченим сертифікатом за партнером. Ідеально закріплений застосунок усе одно може бути недосяжним ні для кого, бо пристрій так і не потрапив у мережу.

Обидва додаються. Прибрати одне означає прибрати засіб контролю; додати інше не замінює його.

Що насправді обмежує закріплення

Закріплення звужує набір ідентичностей сервера, які застосунок прийме, зазвичай називаючи відкритий ключ або хеш сертифіката замість довіри кожному ланцюжку, за який поручився б якийсь сховище. Це обмеження, накладене поверх звичайної перевірки, а не її заміна. Звичайна перевірка відповідає, чи ланцюжок узагалі надійний; закріплення відповідає, чи це той ланцюжок, якого очікує застосунок. Реалізація, що пропускає перший крок, отримує не безпеку, а лише новизну.

Об’єкт закріплення різниться між платформами, тож саме слово говорить дуже мало. Скопіювати хеш зі сховища довіри одного продукту й вважати його тим самим у мобільному застосунку — поширена й тиха помилка.

Закріплення на платформі — це конфігурація, а не політика

Android надає закріплення через конфігурацію мережевої безпеки, де набір закріплень містить дайджести відкритого ключа, і ланцюжок має містити принаймні один із них. Цей файл задається для кожного застосунку й вимагає свідомої зміни збирання. У iOS немає еквівалентного механізму маніфесту, тому закріплення там живе у власному коді оцінювання довіри застосунку.

Оскільки механізм різний, вимогу треба писати для кожної платформи. Політика, яка каже закріпіть сертифікат, не називаючи платформу, є нездійсненною.

Ротація вирішує, чи виживе закріплення

Складна частина — не перший випуск, а оновлення сертифіката після нього. Сувора політика довіри відкидає законний новий ключ так само твердо, як і ключ зловмисника.

Два механізми роблять ротацію стерпною: резервне закріплення, якому довіряють ще до того, як воно знадобиться, і дата завершення на наборі закріплень, щоб примусове застосування припинялося, а не блокувало застосунок. Обидва — політичні рішення, і саме завершення є свідомим зниженням безпеки, а не нешкідливим таймером. Назвіть, хто керує збиранням застосунку, кінцевою точкою TLS та оновленням сертифіката, і зведіть їх в один процес змін. Якщо це три різні команди, закріплення зрештою спричинить збій, якого ніхто не планував.

Загублений пристрій — третя проблема

Відкликання облікових даних VPN не обов’язково завершує сеанс застосунку, а закріплення сервера взагалі нічого не робить із телефоном у чужій руці. Блокування пристрою, зберігання облікових даних, тривалість сеансу й віддалене відкликання — окремі рішення з окремими власниками. Якщо згорнути їх в обговорення закріплення, жодне з них не буде спроєктоване.

Перевірте чотири відношення замість одного видимого: передбачуваний сервер і операцію, обліковий запис, який слід відхилити, ідентичність сервера, яку слід відкинути, і заплановану ротацію. Робочий VPN вправляє лише перше. Запишіть, що довів кожен тест, бо наступна людина вважатиме, що зелений тунель означає, що всі чотири пройшли.