Très rapidement, on peut effectivement envisager de faire fonctionner un VPN comme ça - mais je n'ai jamais vu ce type de config être faite.
De façon générale, le serveur de VPN est directement devant le réseau ciblé - on pourrait s'amuser à faire du routage/vlan via des réseaux tiers, mais ça serait un peu aller contre le principe même du VPN.
Le plus souvent un VPN va fonctionner soit avec échange direct des clefs (IE la société qui fournit le VPN paramètre aussi la machine et du coup en profite pour faire l'échange de certificat/clef publiques à ce moment là) - soit on pousse le client à créer sa propre paire clef publique/clef privée et on ajoute lui demande de transmettre la clef publique par mail/site web/ftp - Ou alors on se contente de filer bêtement un couple login/mot de passe, par exemple par téléphone.
Il est rarissime qu'un service VPN utilise un tiers de confiance (type verisign) et des certificats contre signés - Ça arrive parfois en bancaire, sur certaines plateformes de trading - généralement sur des réseaux dédiés (IE non routés sur internet).
Tout ça pour dire que mon serveur peut avoir comme reverse truc.chose.tld, comme nom de domaine accédé par le client waouh.super.net, comme domaine cible (IE une fois la connexion VPN établie) un.deux.test et avoir un certificat avec comme DN : CN=tutu, CN=titi, DC=pipo, DC=root - du moment que le certificat est reconnu par le client comme valide pour le domaine cible ça va passer.
En ce qui concerne la mitigation d'attaque - tu n'es pas obligé de me croire sur parole (encore heureux) - mais je t'invite à lire les docs que j'ai linké chez CloudFlare qui sont raisonnablement accessibles (Oui parce que les docs sur les systèmes de cryptographie ça devient vite pénible pour le non initié).
[^] # Re: Juste pour compléter la liste
Posté par Kaane . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 2.
Très rapidement, on peut effectivement envisager de faire fonctionner un VPN comme ça - mais je n'ai jamais vu ce type de config être faite.
De façon générale, le serveur de VPN est directement devant le réseau ciblé - on pourrait s'amuser à faire du routage/vlan via des réseaux tiers, mais ça serait un peu aller contre le principe même du VPN.
Le plus souvent un VPN va fonctionner soit avec échange direct des clefs (IE la société qui fournit le VPN paramètre aussi la machine et du coup en profite pour faire l'échange de certificat/clef publiques à ce moment là) - soit on pousse le client à créer sa propre paire clef publique/clef privée et on ajoute lui demande de transmettre la clef publique par mail/site web/ftp - Ou alors on se contente de filer bêtement un couple login/mot de passe, par exemple par téléphone.
Il est rarissime qu'un service VPN utilise un tiers de confiance (type verisign) et des certificats contre signés - Ça arrive parfois en bancaire, sur certaines plateformes de trading - généralement sur des réseaux dédiés (IE non routés sur internet).
Tout ça pour dire que mon serveur peut avoir comme reverse truc.chose.tld, comme nom de domaine accédé par le client waouh.super.net, comme domaine cible (IE une fois la connexion VPN établie) un.deux.test et avoir un certificat avec comme DN : CN=tutu, CN=titi, DC=pipo, DC=root - du moment que le certificat est reconnu par le client comme valide pour le domaine cible ça va passer.
En ce qui concerne la mitigation d'attaque - tu n'es pas obligé de me croire sur parole (encore heureux) - mais je t'invite à lire les docs que j'ai linké chez CloudFlare qui sont raisonnablement accessibles (Oui parce que les docs sur les systèmes de cryptographie ça devient vite pénible pour le non initié).