Salut,
J'ai un serveur web qui tourne en HTTP sur un appareil dans un réseau local et je voudrais le sécurisé au mieux moins pire en le passant en HTTPS pour chiffrer ce qui est échangé.
Si je ne dis pas trop de bêtises, il me faut au moins un certificat côté serveur pour faire du HTTPS.
Sachant que je ne peux agir que sur l'appareil en question. Les PC qui s'y connectent et le réseau ne sont pas sous mon contrôle, donc je ne peux pas ajouter de CA au PC ni modifier les DNS du réseau.
C'est là que j'ai un problème …
En local, je me connecte avec une IP ou au mieux avec un nom d'hôte.
- Je ne pense pas que ça ait de sens ni que ça soit possible d'obtenir un certificat pour une IP privée ou un nom d'hôte
- Je ne vois pas l’intérêt d'utiliser un certificat auto-signé (qui pourrait être fait par n'importe qui) qui va sûrement faire crier le navigateur et qui ne protégerait pas d'attaque "Man in the middle"
Question:
- est-ce que c'est possible de faire du HTTPS dans ces conditions ?
- est-ce qu'utiliser un certificat auto-signé sur une IP peut fonctionner (une fois le warning du navigateur accepté) et au moins apporter le chiffrement même si le serveur n'est pas authentifié?
- est-ce que j'ai rien compris?
Merci pour vos conseils et avis éclairés!
# Oui !
Posté par gUI (Mastodon) . Évalué à 5. Dernière modification le 15 février 2021 à 14:27.
Oui, HTTPS marche très bien, même si tu fais ta propre infra. Ça marche exactement pareil, à un détail près
Oui, tu auras les mêmes services rendus :
- communication chiffrée
- authentification du serveur. le détail est sur ce point, il va falloir tout d'abord accepter le certificat, donc être dans une situation où tu as confiance "oui, je sais que c'est le bon serveur" (pas dur dans le cas d'un réseau local). ensuite il sera mémorisé, et si ça change ton browser te le dira
Après une façon assez sympa c'est de te créer un certificat d'autorité, et mettre ce certificat dans ton browser (a la suite des 10aines qui sont livrés avec) et ensuite tu n'auras pas à accepter quoi que ce soit, ton site HTTPS auto-signé sera accepté.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Oui !
Posté par matteli . Évalué à 2.
Certificat sur une IP, ça a du sens ?
[^] # Re: Oui !
Posté par gouttegd (site web personnel) . Évalué à 5.
Oui, c’est tout-à-fait possible.
Par contre, aucune CA ne délivrera de certificat pour une IP privée (ou un nom d’hôte local), c’est interdit par le CA/Browser Forum.
[^] # Re: Oui !
Posté par gouttegd (site web personnel) . Évalué à 2.
Ce serait clairement la meilleure solution ici, sauf qu’apparemment ykrons n’a pas la main sur les postes clients pour y ajouter sa propre CA.
Reste la possibilité d’inviter gentiment les utilisateurs à installer eux-mêmes le certificat racine de la CA. Est-ce une solution envisageable dans le contexte de la demande, seul ykrons peut le dire.
[^] # Re: Oui !
Posté par ykrons . Évalué à 2.
Merci pour les retours!
Ça confirme un peu ce que je craignais : tant que le CA n'aura pas été ajouté sur les PC, il y aura au moins une alerte de sécurité la première fois.
C'est destiné a être utilisé par Mme/M Michu+ et je suis pas sur que ça plaise trop aux services info qui passent leur temps à dire de pas tout accepter :)
L'option d'ajouter un CA auto-signé devrait pas les enchanter non plus :) mais bon on peut pas tout avoir non plus!
Le bon point c'est qu'on ne l'aura plus après sauf si:
- il y a changement de certificat (MITM par exemple)
- on se connecte sur un autre appareil qui utilise le même principe avec la même IP mais un certificat différent
Au final, je pense pas partir sur cette option dans ce contexte. Trop de warning du navigateur si le CA n'est pas ajouté au navigateur ou si on change de méthode de connexion (potentiellement plusieurs IP pour se connecter), donc ça serait sans HTTPS
Par contre dans le cas où je veux juste chiffrer les données envoyées par le client (typiquement mot de passe etc) est ce qu'il n'est pas possible de bricoler un truc en JS?
- la page web embarque du code avec une clé publique
- quand l'utilisateur rempli un formulaire et envoie les données au serveur, elles sont chiffrées avec la clé publique
- le serveur à la clé privée et est capable de déchiffrer les données reçues.
Ça n'apporte pas d'authentification, ça ne chiffre pas les urls, ni les données de la page, mais au moins les données envoyées au serveur peuvent être chiffrées. Ça peut peut-être suffire dans mon cas.
[^] # Re: Oui !
Posté par gUI (Mastodon) . Évalué à 2.
C'est une idée.
Si. Tout ce qui est déchiffré par le client prouve que c'est bien le bon serveur et lui seul qui l'a chiffré.
Non en effet. D'où l'idée de ne pas passer d'information dedans style 'http://server/accueil?id=monlogin"
Et pourquoi pas ? Tu as des sites web tous modernes (warning, c'est pas mon domaine), où la page HTML est quasi vide, tout se fait en dynamique via socket/JS qui par exemple télécharge des JSON et remplis le HTML (ReactJS je crois fait ça). Tu peux imaginer de chiffrer (d'ailleurs si ça se trouve ça existe).
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Oui !
Posté par NeoX . Évalué à 4.
un bon service informatique aura sa propre CA, deja installée sur les machines de l'entreprise
à eux de te fournir un certificat, signé par leur autorité.
ca reste un certificat interne, mais utilisable par tous les utilisateurs de l'entreprise.
[^] # Re: Oui !
Posté par gouttegd (site web personnel) . Évalué à 2.
D’autant qu’il y a un risque : si tu demandes aux utilisateurs d’installer le certificat racine de ta CA sur leurs machines, ta CA se retrouve en position d’émettre des certificats valides pour n’importe quel site.1 Tu as intérêt à faire très attention à la clef privée de ta CA…
Il va falloir sérieusement penser à ton threat model. En particulier : est-ce que tu crains les attaques actives ou pas ? On dirait que oui, vu que tu ne veux pas utiliser un certificat auto-signé « qui ne protégerait pas d’attaque “Man in the middle” ».
Si l’hypothèse d’un attaquant actif est crédible, alors ton « bricolage » en JS ne t’apporte absolument rien, et certainement pas la garantie que les données envoyées au serveur sont chiffrés.
Sauf les sites épinglés « en dur » dans le navigateur, typiquement les sites de Google & Co. ↩
[^] # Re: Oui !
Posté par ykrons . Évalué à 1.
Tout à fait. Ça me semblerait aussi être la meilleure solution si il n'y avait qu'une IP et qu'une "entité" qui accède au serveur web.
Mon vrai problème c'est qu'on peut accéder à l'appareil en question de plein de façons différentes (ce que j'avais pas précisé dans ma question):
- par une interface avec une IP fixe : là OK pour le certificat sur IP et ajouté au PC
- par une ou plusieurs autres interfaces LAN/Wi-Fi avec une IP dynamique : là ça ne marche plus pour les certificats
- enfin plusieurs boîtes (au moins fournisseur et client) vont s'y connecter : là encore compliqué de partager un CA auto-signé entre deux boîtes je pense …
[^] # Re: Oui !
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 16 février 2021 à 10:40.
Ça complique mais ne change pas le fondamental. Si tu installes le CA sur le client, tu génèreras ensuite autant de certificats que de moyen d'accéder au serveur, le certificat étant reconnu par le CA, ils seront tous acceptés.
Pour une seule manip, tu valides tous les certificats générés par la suite (c'est pour ça que c'est une bonne idée que l'IT gère ce CA).
Pour le cross-entreprise, en soit c'est pas gênant. Tu as une 20aine de CA dans ton Firefox qui viennent tu ne sais pas trop d'où, là en ajouter un d'une entreprise partenaire, c'est pas déconnant du tout. C'est juste que c'est pas trop dans les moeurs c'est vrai.
Mais un membre de l'IT de l'entreprise A, qui se déplace physiquement vers l'entreprise B avec une clé USB contenant le certificat de l'entreprise A, c'est la classe je trouve :)
Niveau chaîne de confiance, on est au top !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Oui !
Posté par ykrons . Évalué à 1.
Coté client oui, mais coté serveur si j'ai une IP dynamique ça colle pas. Je ne vais préparé tous les certificats correspondant aux IPs possible ?
Dans l'idée, j'aime bien aussi mais en pratique je vois pas quelqu'un faire le tour de la planète avec sa clé USB … en fait si :) mais surtout je vois qui va le payer pour ça … ;)
Au final, mon cas est assez proche d'une Box internet. Connexion via IP pas forcement statique.
Perso, ça me ferait bizarre d'installer un certificat de Orange/Free/etc pour pouvoir administrer une box …
[^] # Re: Oui !
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 16 février 2021 à 13:04.
Déjà un serveur avec une IP dynamique ça colle pas vraiment. Tu t'y connectes comment si son IP change ?
Mais quelle autre entreprise va l'utiliser ? C'est pas sur ton réseau local ? Pour moi c'était un cas particulier d'une entreprise précise qui devait aussi utiliser ton serveur.
On parle pas de la même chose je pense
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# certbot + challenge DNS?
Posté par freem . Évalué à 4.
À part utiliser une CA déjà connue, pas d'autre choix que l'auto-signé.
Du coup, utiliser let's encrypt comme CA me semble faisable.
Dans tous les cas, il te faudra un nom de domaine internet, donc que le DHPC de ton LAN fournisse un DNSd qui connaisse ton serveur (dommage de passer par internet pour un accès du serveur LAN, pas vrai?).
Pour le challenge HTTP, il faut que la machine installe et fasse tourner le certbot en tant que root, ce qui peut poser problème. Il faut également, de mémoire, un httpd qui supporte les CGI, ainsi que python installé. Et, bien entendu, être joignable par le www… Si je ne m'abuse.
Perso, je regarderais plus les challenge DNS, pas d'install spécifique sur le serveur.
Notes aussi que je peux me tromper: j'ignore si le certificat vérifie la concordance de l'IP (ce qui ne me surprendrais pas). Si c'est le cas, peut-être via l'IPv6?
C'est, de toute façon, juste une piste.
Perso, je me ferais pas chier: un certificat auto-signé, une manip a faire par les utilisateurs et hop. Beaucoup plus simple ainsi. Au final, c'est même plus sûr que d'utiliser une CA, puisque ton certificat étant auto-signé, si un cert parent se fait voler/copier/whatever, tu ne sera pas affecté (ben oui: pas de cert parent. D'ailleurs, il me semble bien que ce genre de situations s'est déjà produites…) contrairement à un "vrai" certificat.
L'inconvénient, c'est que bien sûr l'auto-signé, ça scale pas, et ça demande aux utilisateurs de faire confiance au 1er usage.
Tout dépend du besoin réel en fait. D'ailleurs, pour "sniffer", il faudrait que le sniffeur, soit ait accès physique au switch ou aux câble qui relie celui-ci au serveur, soit accès au câble entre un client et le switch (pour espionner ce client-ci) soit passer par du wifi (et encore… dans le cas du wifi je ne sais pas s'il est trivial de déchiffrer les connexions des autres… et ça m'étonnerais qu'on le puisse avec tous les protocoles de chiffremment…).
Dans un hypothétique cas 100% filaire (câbles encastrés dans le mur, pas d'accès physique, etc), avec 0 logiciel malveillant installé sur la machine cliente, je pense même que le chiffrement n'apporte rien.
[^] # Re: certbot + challenge DNS?
Posté par ykrons . Évalué à 1.
L'appareil sera une sorte de box sur un réseau local et pas accessible d'internet donc le nom de domaine pour le CA ou let's encrypt ne me parait pas jouable.
Sinon je pense aussi que les risques sont assez bas sur un réseau local filaire ou Wi-Fi en rapport des données échangées donc ça ne me semble pas justifier d'habituer l'utilisateur ou l'utilisatrice à accepter des warnings de sécurité à tout va!
[^] # Re: certbot + challenge DNS?
Posté par Xebrok . Évalué à 1.
Dans ce cas le DNS-challenge avec un registrar qui va bien, ça le fait ex: https://go-acme.github.io/lego/dns/infomaniak/
Mais sans accès au DNS local pour paramétrer le nouveau nom de domaine, il faut modifier le fichier hosts de chaque machine..
# Petite question
Posté par aiolos . Évalué à 3.
Tu ne peux pas en parler avec le service informatique ?
De ce que je comprends des échanges précédents, c'est dans une structure pro, avec des gens qui n'aprecieraient pas voire des utilisateurs accepter à tous va des alertes de sécu…
Si tu dois intégrer un service dans le réseau, ils aimeraient peut-être être informés, et ils pourront peut-être t'aider. Est-ce que vous avez d'autres outils internes ? Sont-ils en https ? Dans ce cas comment le problème a-t-il été résolu ailleurs ? Sinon, comment verraient-ils les choses ? Peuvent-ils ajouter l'autorité de certification interne ? Définir une politique sur la clef maître ?
[^] # Re: Petite question
Posté par ykrons . Évalué à 1.
Oui on a effectivement sûrement déjà des CA internes mais après ces discussions, je me rends compte que mon problème est ailleurs … (https://linuxfr.org/forums/linux-general/posts/https-sur-reseau-local#comment-1841837).
En ayant plusieurs moyens de me connecter via différentes IPs potentiellement dynamiques, je ne vois pas trop comment générer un certificat.
En plus, on peut se connecter à partir de différentes machines (sans lien), je ne vois pas trop comment partager des CA sauf si ils sont publics ce qui ne sera pas compatible avec des IPS.
[^] # Re: Petite question
Posté par aiolos . Évalué à 3. Dernière modification le 16 février 2021 à 11:52.
En fait, plus je te lis, plus je me dis que tu as un problème d'architecture réseau/applicative, et qu'il faudrait avoir une démarche plus globale avec, au moins :
- étude de l'intégration dans l'archi réseau (mise en place d'un DNS dynamique, persistance DHCP, etc.)
- description du modèle de vulnérabilité (quelles données/enjeux, quel type d'attaques, etc.)
[^] # Re: Petite question
Posté par gUI (Mastodon) . Évalué à 2.
Idem c'est bcp trop compliqué je pense :)
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Petite question
Posté par NeoX . Évalué à 2. Dernière modification le 18 février 2021 à 17:48.
si ton serveur à des IPs dynamiques, il ne faut surtout pas se connecter avec l'IP
en effet, celle-ci peut changer au prochain démarrage, et donc rendre caduque tes regles de firewall entre l'utilisateur et le serveur, les exceptions dans le navigateur, etc
il faut utiliser un système de DNS, couplé au DHCP
qui fournit alors la mise à jour IP -> DNS
et tu te connectes toujours sur nom-dns.domain.tld
évidemment si c'est une machine que tu emmènes en clientele, il faut faire le parametrage chez chaque client.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.