TLS VPN срещу IPsec: петте полета, които си струва да се прегледат

Подреждането на TLS VPN срещу IPsec VPN по семейство протоколи отговаря на въпрос, който никой не е задал, и обикновено цитира конструкция, която и двете семейства изоставиха преди години. Това, което рецензентът действително може да оцени, е договорената защита, идентичността на партньора, моделът на клиента и изложената услуга. Тези четири неща са видими при внедряване и нито едно не следва от етикета на продукта. Поискайте пет полета и разговорът става конкретен.

Пет полета и етикетът не е едно от тях

Първото поле е поддържаната версия на софтуера, защото описание на протокол без версия е брошура. Второто е договорената версия на протокола, която решава кои конструкции изобщо са налични. Третото е защитният набор, четвъртото е методът за удостоверяване както на партньора, така и на потребителя, а петото е обхватът на достъп, който продуктът дава след допускането.

Етикетът SSL VPN покрива поне три различни продукта: пълен мрежов клиент, прокси за приложения и стар портал, базиран на браузър. Те излагат различни услуги и се провалят по различен начин, така че етикетът не може да замести полето за обхват.

Какво всъщност променя удостовереното криптиране

TLS 1.3 изисква удостоверено криптиране, което премахва по-старата конструкция MAC-then-encrypt от протокола, вместо да я остави незадължителна. IPsec ESP има набори за удостоверено криптиране от също толкова дълго време, с AES-GCM, дефиниран в собствен RFC. И в двете семейства гаранцията идва от договорения набор, а не от името на семейството, затова списъкът с полета започва с версия. Рецензент, който не може да назове набора, няма какво да оценява.

Затова историческото сравнение е подвеждащо. Внедряване, закрепено към стара версия на TLS с набор CBC, и такова, което изпълнява TLS 1.3 с набор AEAD, не са еднаква позиция за сигурност, макар и двете да са TLS VPN. Същото разделение съществува от страната на IPsec между модерен набор ESP и по-стара комбинация.

Четете договорените стойности, а не конфигурацията, която сте предвиждали. Командите по-долу показват за какво всъщност са се споразумели работеща крайна точка и работещ тунел.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

Ако крайната точка не иска да договаря TLS 1.3, това е констатация, а не предпочитание. Ако тунелът изброява набор, който не сте очаквали, конфигурацията, която има значение, е тази, която партньорите са избрали, а не тази от шаблона.

Идентичността на партньора е отделен въпрос

Криптиране без проверен партньор защитава трафика от наблюдатели и го предава на този, който е отговорил на връзката. Удостоверяването на партньора пита каква идентичност се очаква, какъв доверителен материал я валидира и как клиентът се държи, когато отговорът не съвпада. Верига от сертификати, закрепен ключ и предварително споделена тайна са три различни отговора с три различни оперативни разходи.

След това задайте същите въпроси за потребителя или устройството. Шлюз, който удостоверява машината и допуска всеки потребител, или обратното, има конкретна позиция, която трябва да се запише, а не да се предполага. Разрешенията за ресурси, приложени след допускането, са част от същото поле, защото удостоверяването не е оторизация.

Запазването на проверките на име на хост и сертификат е по-важно от познатостта на прозореца за вход. Клиент, конфигуриран да игнорира проверката, е премахнал единствената стъпка, която отличава вашия шлюз от убедително копие.

Границата, която продуктът излага

Портал без клиент посредничи за избрани операции на приложения през шлюза, така че потребителят достига интерфейс, а не мрежа. Клиент с пълен тунел носи това, което изберат неговите маршрути и политиката за филтриране, което е много по-голяма повърхност. Сравняването на двете по сила на протокола пропуска разликата в това до какво нападателят може да стигне през тях. Едното излага интерфейс на приложение, другото маршрутизирана мрежа, и двете изискват различни прегледи.

Питайте коя услуга е изложена, кои операции са оторизирани и на какво слуша самият шлюз. Административен интерфейс, достъпен от същия адрес като потребителския портал, е констатация при внедряването и никакъв избор на протокол не го компенсира.

Обхватът по приложение допълнително стеснява повърхността и променя и поведението при отказ, когато тунелът падне. Дизайн, който предполага обхват на пълен тунел, се чупи по начини, които дизайнът по приложение не познава, и натоварването на поддръжката следва.

Решете резултата от отказа и жизнения цикъл

Какво се случва, когато удостоверяването или защитата не са налични, е решение за политика, което принадлежи на прегледа. Блокиран резултат и необявено директно връщане имат различни последствия, а разликата е невидима в списък с функции. Посочете предвиденото поведение до ресурса, който защитава.

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

Запишете петте полета, политиката при отказ и собственика на жизнения цикъл на една страница. Тази страница е преглед; сравнение на семейства протоколи е мнение.