On Wed, Apr 04, 2018 at 04:27:30PM +0200, Frederic Dumas wrote: > J???aimerai mieux sécuriser le serveur contre les balayages d???IP, et lui > interdire de communiquer ce certificat X.509 à un visiteur se connectant > directement sur son adresse IP ou se connectant en résolvant cette adresse IP > à travers un domaine fictif.
C'est une bonne question. J'ai l'impression que ce n'est pas possible de cacher les serveurs hébergés sur une adresse IP, rien qu'à cause du DNS (voir [4] par exemple). La meilleure réponse serait une adresse IP par type de service, de préférence dans une autre plage à chaque fois. Une idée serait de prendre une VM Amazon, Hetzner ou autre et de faire un redirecteur TCP sur une adresse IP non autrement accessible, et un numéro de port différent s'il y a plusieurs certificats pour éviter de montrer le même certificat. D'un autre côté, quelqu'un fera peut-être un jour une base de données des certificats, par scan. Une idée "parfaite" serait un hidden service tor. Mais cela pose d'autres problèmes (performance, etc). En ce qui concerne le problème mentionné: Par défaut, le certificat SSL sera présenté sur le port 443 lors de toute connexion. En effet, le modèle classique est un certificat par adresse IP, envoyé par le serveur avant que le client n'envoie sa requête! L'établissement d'une session SSL/TLS est indépendante du virtual host considéré. On servait plusieurs certificats en utilisant plusieurs adresses IP (ou numéros de port, mais pas très transparent pour l'utilisateur), ou en indiquant plusieurs domaines dans le certificat X.509 (dépendant des règles de l'autorité de certification). C'est justement ce que SNI (RFC-4366, [3] avec du joli ASN.1) a amélioré, en ajoutant une indication avant TLS du domaine considéré, qui permet d'envoyer le bon certificat, et donc d'avoir une adresse IP et un port pour plusieurs certificats différents. La norme [3] dit: "If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal)." Donc, il est autorisé d'aborter la négociation TLS/SSL si le nom indiqué dans SNI n'est pas reconnu. Cela n'empêchera pas l'énumération, en particulier si un scan du DNS a été fait et une liste de tous les domaines hébergés par une adresse IP construite[4], mais au moins l'énumération du certificat ne sera pas possible sans l'énumération du DNS au départ. Toutefois, Wikipedia dit: "Lorsque le navigateur ne gère pas le SNI, le serveur fournit le certificat par défaut," [1]. Cependant, Apache2 semble avoir une configuration: SSLStrictSNIVHostCheck qui permet de restreindre les clients non SNI, et peut-être ainsi d'éviter une énumération [2], à contrôler si cela présente effectivement aucun certificat / interdit la connexion TLS/SSL. [1] https://fr.wikipedia.org/wiki/Server_Name_Indication [2] http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslstrictsnivhostcheck [3] https://tools.ietf.org/html/rfc4366#section-3.1 [4] http://viewdns.info/reverseip/?host=46.140.72.222&t=1 _______________________________________________ gull mailing list [email protected] http://forum.linux-gull.ch/mailman/listinfo/gull
