VPN TLS fronte a IPsec: os cinco campos que paga a pena revisar
Compare unha VPN TLS e unha VPN IPsec por versión, versión do protocolo, suite, identidade do par e ámbito exposto, ademais do resultado de fallo que configurou realmente.
Clasificar as VPN TLS fronte ás VPN IPsec por familia de protocolos responde a unha pregunta que ninguén fixo, e adoita citar unha construción que ambas as familias deixaron de usar hai anos. O que un revisor pode avaliar de verdade é a protección negociada, a identidade do par, o modelo de cliente e o servizo exposto. Esas catro cousas son visibles nun despregamento, e ningunha se deduce da etiqueta do produto. Pida cinco campos e a conversa vólvese concreta.
Cinco campos, e a etiqueta non é un deles
O primeiro campo é a versión de software admitida, porque unha descrición de protocolo sen versión é un folleto. O segundo é a versión de protocolo negociada, que decide que construccións están incluso dispoñibles. O terceiro é a suite de protección, o cuarto o método de autenticación tanto do par como do usuario, e o quinto o ámbito de acceso que o produto concede tras a admisión.
Unha etiqueta VPN SSL cobre polo menos tres produtos distintos: un cliente de rede completo, un proxy de aplicacións e un portal herdado baseado en navegador. Expón servizos diferentes e fallan de forma distinta, así que a etiqueta non pode substituír o campo de ámbito.
| Field | What a usable answer looks like |
|---|---|
| Release | A version with a support window, not a family name |
| Protocol version | TLS 1.3 or IKEv2 with the ESP suite named |
| Protection suite | An authenticated-encryption algorithm, not a cipher list |
| Authentication | Peer identity plus user or device identity, separately |
| Access scope | The services reachable after admission |
Que cambia realmente o cifrado autenticado
TLS 1.3 esixe cifrado autenticado, o que elimina do protocolo a construción MAC-then-encrypt máis antiga en lugar de deixala opcional. IPsec ESP ten suites de cifrado autenticado desde hai o mesmo tempo, con AES-GCM definido na súa propia RFC. En ambas as familias a garantía vén da suite negociada e non do nome da familia, e por iso a lista de campos comeza por unha versión. Un revisor que non pode nomear a suite non ten nada que avaliar.
Por iso a comparación histórica é enganosa. Un despregamento fixado a unha versión antiga de TLS cunha suite CBC e outro que executa TLS 1.3 cunha suite AEAD non teñen a mesma postura de seguridade, aínda que ambos sexan VPN TLS. A mesma división existe no lado IPsec entre unha suite ESP moderna e unha combinación herdada.
Lea os valores negociados en lugar da configuración que pretendía. As ordes de abaixo mostran en que coincidiron realmente un extremo activo e un túnel activo.
openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sasSe o extremo non quere negociar TLS 1.3, é un achado e non unha preferencia. Se o túnel lista unha suite que non esperaba, a configuración que importa é a que elixiron os pares, non a do modelo.
A identidade do par é unha cuestión aparte
O cifrado sen un par verificado protexe o tráfico de observadores e entrégao a quen respondese á conexión. A autenticación do par pregunta que identidade se espera, que material de confianza a valida e como se comporta o cliente cando a resposta non coincide. Unha cadea de certificados, unha chave fixada e un segredo precompartido son tres respostas distintas con tres custos operativos distintos.
Despois faga as mesmas preguntas sobre o usuario ou o dispositivo. Unha pasarela que autentica a máquina e admite calquera usuario, ou o contrario, ten unha postura concreta que debería escribirse en lugar de supoñerse. Os permisos de recursos aplicados tras a admisión forman parte do mesmo campo, porque a autenticación non é a autorización.
Conservar as comprobacións de nome de host e de certificado importa máis que a familiaridade da xanela de inicio de sesión. Un cliente configurado para ignorar a verificación eliminou o único paso que distingue a súa pasarela dunha imitación convincente.
O límite que expón o produto
Un portal sen cliente fai de proxy de operacións de aplicación seleccionadas a través da pasarela, así que o usuario chega a unha interface en lugar de a unha rede. Un cliente de túnel completo transporta o que seleccionan as súas rutas e a súa política de filtrado, que é unha superficie moito maior. Comparar os dous pola forza do protocolo pasa por alto a diferenza no que un atacante pode acadar a través deles. Un expón unha interface de aplicación, o outro expón unha rede encamiñada, e os dous esixen revisións distintas.
Pregunte que servizo está exposto, que operacións están autorizadas e en que escoita a propia pasarela. Unha interface de administración accesible desde a mesma dirección que o portal de usuario é un achado de despregamento, e ningunha elección de protocolo o compensa.
O ámbito por aplicación reduce aínda máis a superficie, e tamén cambia o comportamento de fallo cando cae o túnel. Un deseño que supón cobertura de túnel completo rompe de maneiras que un deseño por aplicación non coñece, e a carga de soporte segue.
Decida o resultado de fallo e o ciclo de vida
O que acontece cando a autenticación ou a protección non está dispoñible é unha decisión de política que pertence á revisión. Un resultado bloqueado e unha volta directa non anunciada teñen consecuencias distintas, e a diferenza é invisible nunha lista de funcións. Indique o comportamento previsto xunto ao recurso que protexe.
Inclúa o ciclo de vida de parches e soporte da pasarela, as súas funcións externas habilitadas e o camiño de actualización dos clientes. Unha elección de protocolo correcta non fai seguro un servizo mal despregado, e a maioría dos incidentes viven nesa fenda e non na suite.
Escriba os cinco campos, a política de fallo e o responsable do ciclo de vida nunha páxina. Esa páxina é unha revisión; unha comparación de familias de protocolos é unha opinión.