Perso, même si c'est pour du réseau "local", je ne ferais quand même rien passer en claire, car tu ne peux jamais être sûr de la santé des machines connectées au réseau.
Du même avis que toi, la défense en châteaux c'est dépassé, maintenant il faut partir du principe que le réseau est compromis.
Ok, je vois, mais stp, arrête de dire que Let's Encrypt ne sait utiliser que du port 80 ou 443: c'est tout bonnement faux.
De souvenir quand tu utilises un port non standard, alors ce port est inséré dans le nom de domaine (par exemple HelloWorld.com:8666 et le certif n'est alors pas utilisable sans alerte pour HelloWorld.com).
Maintenant tu nous parles de curl
C'était un bête exemple réseau (parce que certains ne comprennent pas qu'un VPN peut servir à connecter des machines et sécuriser leurs communications, qu'un VPN ça ne se résume pas à cacher ses communications de la LOPSI).
Pourquoi dis tu que les communications avec certificats auto-signé sont facilement cassées ?
Enfaîte ca dépends.
HaProxy permet par exemple de vérifier les certificats autosigné. Ainsi en cas de MITM (et donc de certificats différents) HaProxy va le détecter et indiquer le serveur touché comme down.
Firefox fait un peu pareil en enregistrant le certificat HTTPS. Mais si tu n'as pas déjà enregistré le certificat et qu'un pirate à MITM ton service, alors le certificat que tu vas recevoir c'est le sien et se sera peu visible. Note que Tor Browser supprime les certifs lors de l'arrêt, afin d'éviter qu'un scan du dossier ne suffisent pour récupérer la liste des sites visités.
Est-ce aussi simple que l'ARP spoofing ?
Non, l'ARP poisoning aujourd'hui c'est LE piratage le plus facile.
J'ai vu sur StackOverflow également que tu peux faire des certificats autos signés pour des adresses IP.
Tant que ton set de clés est unique et que ton logiciel check que le certif n'a pas changé entre deux requêtes : en autosigné peu importe se qui est indiqué dans la section nom de domaine du certif. En effet un pirate peut reforger un certif autosigné en indiquant se qu'il veut dans ce champs, mais son certif aura une signature différente du tiens.
As tu vraiment besoin de Firefox ou Chrome dans ta situation qui n'est pas "grand publique" ?
Si demain Chrome et Firefox bloquent complètement HTTP, ça signifie que les "pas 2k" peuvent jeter une partie de leur matos électronique alors que celui-ci fonctionne.
Pour moi ce n'est juste pas acceptable. (ça signifie que pour accéder à la WEBUI d'un vieux routeur ou une caméra de surveillance grand publique, il va falloir mettre en place un proxy (sur une autre machine) chargé de faire de l'HTTPS, bref aucune sécurité en plus mais plein de config en plus).
J'ai l'impression que tout ces cas de figures sont mélangés dans tes commentaires et que c'est pour ça que l'on a de la peine à s'entendre...
Si tu veux comprendre ma façon de penser, ne te dis pas "il n'aime pas HTTPS" mais "il utilise TLS, SSH, VPN, Tor tout les jours en fonction des avantages et inconvénients de chacun".
D'ailleurs avec le challenge DNS, Let's Encrypt n'a même pas besoin d'accéder à tes machines autres que celles qui gèrent tpn service DNS.
Serait-ce utilisable pour jean-kévin qui voudrait sécuriser l'accès à la WEBUI de sa seedbox Deluge ?
Un tuto sur LinuxFR sur cette procédure serait intéressant. 😀
[^] # Re: ca commence
Posté par voxdemonix . En réponse à la dépêche Firefox 68 et 68 ESR par le menu. Évalué à 0. Dernière modification le 11 août 2019 à 16:09.
C'est un peu dans le désordre sorry. 😄
Du même avis que toi, la défense en châteaux c'est dépassé, maintenant il faut partir du principe que le réseau est compromis.
De souvenir quand tu utilises un port non standard, alors ce port est inséré dans le nom de domaine (par exemple HelloWorld.com:8666 et le certif n'est alors pas utilisable sans alerte pour HelloWorld.com).
C'était un bête exemple réseau (parce que certains ne comprennent pas qu'un VPN peut servir à connecter des machines et sécuriser leurs communications, qu'un VPN ça ne se résume pas à cacher ses communications de la LOPSI).
Enfaîte ca dépends.
HaProxy permet par exemple de vérifier les certificats autosigné. Ainsi en cas de MITM (et donc de certificats différents) HaProxy va le détecter et indiquer le serveur touché comme down.
Firefox fait un peu pareil en enregistrant le certificat HTTPS. Mais si tu n'as pas déjà enregistré le certificat et qu'un pirate à MITM ton service, alors le certificat que tu vas recevoir c'est le sien et se sera peu visible. Note que Tor Browser supprime les certifs lors de l'arrêt, afin d'éviter qu'un scan du dossier ne suffisent pour récupérer la liste des sites visités.
Non, l'ARP poisoning aujourd'hui c'est LE piratage le plus facile.
Tant que ton set de clés est unique et que ton logiciel check que le certif n'a pas changé entre deux requêtes : en autosigné peu importe se qui est indiqué dans la section nom de domaine du certif. En effet un pirate peut reforger un certif autosigné en indiquant se qu'il veut dans ce champs, mais son certif aura une signature différente du tiens.
Si demain Chrome et Firefox bloquent complètement HTTP, ça signifie que les "pas 2k" peuvent jeter une partie de leur matos électronique alors que celui-ci fonctionne.
Pour moi ce n'est juste pas acceptable. (ça signifie que pour accéder à la WEBUI d'un vieux routeur ou une caméra de surveillance grand publique, il va falloir mettre en place un proxy (sur une autre machine) chargé de faire de l'HTTPS, bref aucune sécurité en plus mais plein de config en plus).
Si tu veux comprendre ma façon de penser, ne te dis pas "il n'aime pas HTTPS" mais "il utilise TLS, SSH, VPN, Tor tout les jours en fonction des avantages et inconvénients de chacun".
Serait-ce utilisable pour jean-kévin qui voudrait sécuriser l'accès à la WEBUI de sa seedbox Deluge ?
Un tuto sur LinuxFR sur cette procédure serait intéressant. 😀