Власний сертифікат VPN — не додатковий шар шифрування

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

Три окремі завдання в рукостисканні TLS 1.3

RFC 8446 розділяє ці речі, і саме цей поділ — уся відповідь. Повідомлення Certificate несе ланцюжок сертифікатів кінцевої точки. CertificateVerify доводить володіння відповідним приватним ключем і прив'язує розшифровку рукостискання. Рівень записів захищає трафік узгодженими ключами трафіку.

Замініть сертифікат — перші два пункти зміняться. Захист записів не виконується двічі й не стає сильнішим через те, що видавець тепер приватний.

Що насправді дає приватний CA

Він дає керовану систему ідентичності: ви вирішуєте, кому видавати, ви вирішуєте, яким видавцям довіряють партнери, і можете відкликати за власним графіком. Це справді корисно, коли ви керуєте обома кінцями.

Але він приносить і зобов'язання. Довіру треба розподіляти свідомо, перевірка партнера має залишатися увімкненою, а життєвим циклом облікових даних має хтось володіти. Приватний CA — не короткий шлях в обхід жодного з цих трьох пунктів.

Коли другий канал — правильна відповідь

Припустімо, застосунок відкриває перевірений HTTPS до власного сервісу, а його пакети йдуть ще й через VPN. У такої схеми дві межі з потенційно різними кінцевими точками, і саме так виглядає другий захищений канал.

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

Запитайте, що змінює встановлення

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

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

Запишіть межі

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

Два рядки на одній сторінці зазвичай закривають суперечку, яку ротація сертифіката закрити не може.

Вирішіть трьома питаннями

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

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