[gull] HTTPS en home hosting - restreindre la diffusion du certificat X.509

[Marc SCHAEFER]

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