3 votes

Pourquoi l'utilisateur et le certificat de l'autorité de certification sont-ils requis pour le VPN RSA IKEv2 ?

Le fonctionnement devrait être similaire à celui d'un site Web HTTPS aléatoire, où le certificat fourni est soutenu par une autorité de certification, et sur la base duquel une connexion sécurisée est établie. L'authentification s'effectue ensuite via la connexion sécurisée.

Alors pourquoi suis-je requis pour fournir les certificats de l'utilisateur et de l'autorité de certification. En d'autres termes, pourquoi n'est-ce pas une simple option ?

Edit : maintenant que je regarde, il semble qu'aucun utilisateur ou mot de passe ne peut être fourni, donc l'authentification du client se fait sur la base du certificat de l'utilisateur. Seul le PPTP nécessite un mot de passe (qui n'est pas un protocole sécurisé de toute façon). La question qui se pose est donc la suivante : pourquoi ont-ils choisi de ne prendre en charge que IKEv2 avec des certificats d'utilisateur et non des mots de passe ? Cela ne peut pas être pour des raisons de sécurité puisque le PPTP est pris en charge.

4voto

duffymo Points 188155

Comme son nom l'indique, le type de VPN IKEv2/IPSec RSA [sic, il faudrait en fait dire "IPsec" et non "IPSec"] est destiné à l'authentification du client avec un certificat/une clé RSA. Le nom a probablement été choisi par souci de cohérence avec les types de VPN existants basés sur IKEv1 (par exemple "L2TP/IPSec RSA" ou "IPSec Xauth RSA"), il pourrait également fonctionner avec des certificats/clés ECDSA et pas seulement RSA, mais je ne l'ai pas testé.

Deux autres types de VPN IKEv2 ont été ajoutés dans le client VPN intégré d'Android 11/R :

  • IKEv2/IPSec PSK pour l'authentification du client et du serveur à l'aide d'une clé pré-partagée (PSK), ce qui n'est pas un choix idéal pour les connexions d'accès à distance car quiconque connaît la PSK peut se faire passer pour le serveur (un attaquant actif peut récupérer le hachage de la PSK et l'attaquer par force brute/dictionnaire).
  • IKEv2/IPSec MSCHAPv2 pour l'authentification du client avec nom d'utilisateur/mot de passe en utilisant EAP-MSCHAPv2. En théorie, le serveur est d'abord authentifié par un certificat, de sorte que le hachage du mot de passe n'est envoyé qu'à un pair de confiance. Cependant, cette vérification n'est apparemment pas obligatoire dans ce client et est désactivée par défaut ( don't verify server ), ce qui rend ce type de VPN vulnérable aux attaquants actifs, sauf si l'utilisateur s'assure d'installer et de sélectionner le certificat CA/serveur correct.

Pour un client VPN IKEv2/IPsec avec plus d'options (par exemple, le split-tunneling, le filtrage d'applications), vous pouvez utiliser le logiciel open-source Client VPN strongSwan qui fonctionne également sur les anciennes versions d'Android. (Avertissement : je suis un développeur du projet strongSwan).

0 votes

Je comprends donc qu'il n'y a pas de raison particulière pour laquelle IKEv2/IPSec MSCHAPv2 n'est pas implémentée dans Android 10, car elle est prévue pour Android 11. PS Bon travail avec strongSwan !

1 votes

Plain Android 10 ne supporte pas IKEv2 dans son client VPN intégré, Android 11 sera le premier à le faire (Google travaille sur sa propre implémentation d'IKEv2 depuis plusieurs années). Dans les versions antérieures, IKEv2 n'est supporté que via une application tierce ou si le fabricant de l'appareil a modifié l'image Android, ce que fait par exemple Samsung depuis des années (mais comme je n'ai pas d'appareil Samsung, je ne connais pas les détails).

0 votes

Je ne savais pas que Samsung modifiait l'image originale de cette manière : J'utilise en effet un appareil Samsung Android 10. Merci pour cette réponse instructive !

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X