Si ce domaine héberge un VPN, il devrait obligatoirement présenté un certificat contenant abcdefghijkl123.mondomaine.com, sous peine de casser l’authentification côté client.
GNI ??? Déjà de quel type de VPN tu parles ? OpenVPN ? IPSec (et lequel ?) L2TP ? PPTP ? Parce que ces différents systèmes VPN ne nécessitent pas franchement de certificats avec correspondances des noms - en fait ils ne nécessitent même pas de nom résolus au niveau DNS - en IP pure ça passe. Du moment que tu valider le certificat...
En VPN 999 fois sur 1000 le nom de domaine ne sert qu'à simplifier l'installation ou la migration du service vis à vis des collaborateurs.
ne serait-ce que pour éviter une erreur flippante si un client se connecte directement dessus. C’est par exemple le cas chez CloudFlare.
CloudFlare c'est du frontal, c'est à dire un truc sur lequel le client est supposé se connecter directement - donc je ne comprend pas trop ta remarque. Bien entendu sur un serveur frontal il faut que le SSL contienne tous les alt name. On parle de serveurs back-end là
Non, ils indiquent juste qu’effectivement avec de la puissance de frappe on peut énumérer les domaines d’un serveur, et que ECDSA permettrait de minimiser la taille des réponses donc les facteurs d’amplification si ton résolveur DNS sert de vecteur d’attaque DDOS (et non s’il est la cible finale).
GNIIII ????
Ce qu'ils disent c'est que c'est casse pied d'avoir tout ses noms de domaines accessibles sur simple requête - que la parade est de passer par de la signature dynamique (au lieu de renvoyer un fichier générique statique - on signe une réponse qui correspond exactement à la demande) - sauf que bien sur la signature dynamique oblige à avoir les clefs privées sur tous les résolveurs (perso je suis pas fan) et qu'en plus l'algo par défaut pour la signature est RSA (c'est d'ailleurs le seul algo obligatoire) - sauf que RSA ça bouffe du CPU comme un goret, et que du coup si tu te prends une attaque - ton résolveur va exploser.
Donc ils demandent à ce que la signature par défaut passe par de l’elliptique qui va quand même 10 fois plus vite - ce qui permet de rester serein un peu plus longtemps quand on se prend une attaque par réflexion.
[^] # 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é à 3.
GNI ??? Déjà de quel type de VPN tu parles ? OpenVPN ? IPSec (et lequel ?) L2TP ? PPTP ? Parce que ces différents systèmes VPN ne nécessitent pas franchement de certificats avec correspondances des noms - en fait ils ne nécessitent même pas de nom résolus au niveau DNS - en IP pure ça passe. Du moment que tu valider le certificat...
En VPN 999 fois sur 1000 le nom de domaine ne sert qu'à simplifier l'installation ou la migration du service vis à vis des collaborateurs.
CloudFlare c'est du frontal, c'est à dire un truc sur lequel le client est supposé se connecter directement - donc je ne comprend pas trop ta remarque. Bien entendu sur un serveur frontal il faut que le SSL contienne tous les alt name. On parle de serveurs back-end là
GNIIII ????
Ce qu'ils disent c'est que c'est casse pied d'avoir tout ses noms de domaines accessibles sur simple requête - que la parade est de passer par de la signature dynamique (au lieu de renvoyer un fichier générique statique - on signe une réponse qui correspond exactement à la demande) - sauf que bien sur la signature dynamique oblige à avoir les clefs privées sur tous les résolveurs (perso je suis pas fan) et qu'en plus l'algo par défaut pour la signature est RSA (c'est d'ailleurs le seul algo obligatoire) - sauf que RSA ça bouffe du CPU comme un goret, et que du coup si tu te prends une attaque - ton résolveur va exploser.
Donc ils demandent à ce que la signature par défaut passe par de l’elliptique qui va quand même 10 fois plus vite - ce qui permet de rester serein un peu plus longtemps quand on se prend une attaque par réflexion.