3 votos

¿Por qué se requiere un certificado de usuario y de CA para IKEv2 RSA VPN?

Debería funcionar de forma similar a ir a un sitio web HTTPS aleatorio, donde el certificado suministrado está respaldado por una CA, y en base al cual se realiza una conexión segura. A continuación, se realiza la autenticación a través de la conexión segura.

Entonces, ¿por qué estoy requerido para suministrar tanto los certificados del usuario como los de la CA. En otras palabras, ¿por qué no es simplemente una opción?

Edito: ahora que lo miro, parece que tampoco se puede suministrar el usuario ni la contraseña, por lo que la autenticación del cliente se produce en base al certificado del usuario. Sólo para PPTP se requiere una contraseña (que no es un protocolo seguro de todos modos). Así que la pregunta es: ¿por qué han elegido soportar sólo IKEv2 con certificados de usuario y no con contraseñas? No puede ser por razones de seguridad ya que PPTP está soportado.

4voto

duffymo Puntos 188155

Como su nombre indica, el tipo de VPN IKEv2/IPSec RSA [sic, en realidad debería ser "IPsec" no "IPSec"] es para la autenticación de clientes con un certificado/clave RSA. El nombre se eligió probablemente por coherencia con los tipos de VPN existentes basados en IKEv1 (por ejemplo, "L2TP/IPSec RSA" o "IPSec Xauth RSA"), también podría funcionar con certificados/claves ECDSA no sólo RSA, pero no lo he probado.

Se han añadido otros dos tipos de VPN IKEv2 en el cliente VPN integrado de Android 11/R:

  • IKEv2/IPSec PSK para la autenticación tanto del cliente como del servidor con una clave precompartida (PSK), que no es una opción ideal para las conexiones de acceso remoto, ya que cualquiera que conozca la PSK puede hacerse pasar por el servidor (un atacante activo puede recuperar el hash de la PSK y atacarla mediante un ataque de fuerza bruta/diccionario).
  • IKEv2/IPSec MSCHAPv2 para la autenticación del cliente con nombre de usuario/contraseña utilizando EAP-MSCHAPv2. En teoría, el servidor se autentifica primero con un certificado, de modo que el hash de la contraseña sólo se envía a un par de confianza. Sin embargo, esta verificación aparentemente no es obligatoria en este cliente y está desactivada por defecto ( don't verify server ), lo que hace que este tipo de VPN sea vulnerable a los atacantes activos, a menos que el usuario se asegure de instalar y seleccionar el certificado CA/servidor correcto.

Para un cliente VPN IKEv2/IPsec con más opciones (por ejemplo, túnel dividido, filtrado de aplicaciones), puede utilizar el código abierto Cliente VPN strongSwan que también funciona en versiones anteriores de Android. (Descargo de responsabilidad: soy desarrollador del proyecto strongSwan).

0 votos

Así que entiendo que no hay ninguna razón particular por la que IKEv2/IPSec MSCHAPv2 no está implementado en Android 10, ya que está previsto para Android 11. PS ¡Gran trabajo con strongSwan!

1 votos

En realidad, Android 10 no admite IKEv2 en su cliente VPN incorporado, y Android 11 será el primero (Google lleva varios años trabajando en su propia implementación de IKEv2). En versiones anteriores, IKEv2 sólo se soporta a través de una aplicación de terceros o si el fabricante del dispositivo modifica la imagen de Android, que es lo que, por ejemplo, Samsung ha estado haciendo durante años (pero como no tengo ningún dispositivo Samsung no conozco los detalles).

0 votos

No sabía que Samsung modificaba la imagen original de esa manera: Efectivamente, estoy utilizando un dispositivo Samsung con Android 10. ¡Gracias por otra respuesta informativa!

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X