voxdemonix a écrit 914 commentaires

Une petite faute s'est glissé dans la précédente commande.

Donc la condition semble fonctionner avec le code suivant, mais les variables $certTor et $certSecure ne veulent plus s'afficher.

    # on enregistre les signatures dans les variables $certSecure et $certTor

${execp certSecure=$( openssl s_client -connect 88.191.250.176:443 -servername linuxfr.org < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin ); certTor=$( torsocks openssl s_client -connect linuxfr.org:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin ) }

    # on compare, si c'est bon on affiche une seule variable en vert, si non on affiche les deux en rouge

${if_match  "$certSecure"="$certTor"   }${execp echo '${color green}';echo $certTor;echo "good"; echo '${color}'; }${else}${execp echo '${color red}';echo "not good";echo $certSecure; echo $certTor;echo '${color}'; }${endif}

${execp if [[ "1" = "1" ]]; then echo "plop";else echo "not good"; fi  }

===> Affiche not good.

En suivant les moteurs de recherches j'ai aussi testé avec if_match comme expliqué ici : https://stackoverflow.com/questions/15692990/conky-with-if-match-and-and
Mais cela ne fonctionne pas (le conky ne s'affiche même plus).

${execp certSecure=$( openssl s_client -connect 88.191.250.176:443 -servername linuxfr.org < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin ) }
${execp certTor=$( torsocks openssl s_client -connect linuxfr.org:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin ) }

${if_match  "$certSecure"=="$certTor"   }${execp echo '${color green}';echo "$certTor";echo '${color}'; }${else}{$execp echo '${color red}';echo "$certSecure"; echo "$certTor";echo '${color}'; }${endif}

Le contraste en a pris un sacré coups, surtout en utilisation de nuit, on se croirait sur la documentation de nextcloud 😄

PS: c'est quoi ce trip à la mode sur plein de sites de libriste de taper du texte gris sur fond blanc ?

Ha, c'est moi qui ai fait une erreur de compréhension.

La commande affiche bien l'aide venant d'une réponse serveur

mysql -u user_toto -h 10.8.42.42 -P 3306 -e "help"

Mais la commande suivante exécute du bash sur le client (pas sur le serveur)

mysql --connect-timeout=2 -u user_toto -h 10.8.42.42 -P 3306 -e "system echo $USER"

Strange comportment !

Merci pour l'infos, ça va être utile pour la suite :)

Par défaut, pour des utilisateurs de type Health Check (genre HaProxy), il y a des restrictions à ajouter (autre que parefeu) ? :) Les tutos se limitent à créer un user sans lui accorder de BDD, hors un help affiche beaucoup de commandes pour l'user.

Merci pour l'infos 😉

Par contre, c'est quoi le rapport entre HTTPS et les gafams ?

Aucun de leur service ne serait impacté par un blocage d'HTTP.
Par contre les autres (les tor hidden service en http *1, les webui des routeurs dev par des informaticiens fainéants (genre TP Link), etc), n'iront plus. Et tout le monde n'a pas forcément envie de faire dépendre l'entièreté de ses WEBUI de deux tiers (le fournisseur de nom de domaine et l'autorité de certif à une époque où le mot "confiance" a perdu de sa substance).

*1 le truc "marrant" étant qu'en https sur Tor Hidden Service vous avez une alerte de sécurité (et donc 3 à 5 clics de plus pour accéder au site), sauf pour FaceBook qui, dans son infinie richesse, à réussi a certifier ses .onion

Du coup, excuse-moi, mais j'en ai déduit effectivement que tu utilisais SSH entre tes machines.

Non, tu en déduis des sophismes pour tenter de faire des attaques ad hominem et polarisé le débat.

Donc peut-être que tu maîtrises tellement ton VPN que tu utilises directement telnet entre tes machines.

Plus tôt que de faire des sophismes, je t'invite à faire un live twitch et essayer de craquer un

telnet 10.8.1.1 sur un réseau OpenVPN
telnet 10.8.42.42 sur un réseau Wireguard
telnet blablabla.onion (tor hidden service)
telnet 127.0.0.1 via SSH

Attention pour les boulets polarisé, ce commentaire n'est pas un "telnet vs ssh". A la base ca parle d'HTTP sécurisé par autre chose que TLS, mais certains commentateurs sont resté coincé à l'ère "htp vs https" d'il y a plus de dix ans.

Ça m'attriste et, maintenant, j'ai même un peu peur du contenu existant dans le wiki de LinuxFr.

Je suis étalé de rire en lisant ça. 😂😂😂
Vas-y lire mes commentaires ou je demande une correction de la communauté mais où personne ne répond parce qu'ici tout se qui compte c'est de jouer au plus sophiste.

ModHeader et ajouter comme Header Host 1.2.3.4 pour son domaine perso.
Ne fonctionne que s'il n'y a pas de check de l'IP ni de ré-écriture des URL.

Cette config basique mono serveur devrait faire le boulot.

listen mon_equipement
        bind *:80
                # si tu veux disposer du HTTPS, c'est la ligne suivante
#       bind *:443 ssl crt /etc/haproxy/certs/www.helloworld.com.pem
        mode http
        balance roundrobin
                # Transmission des infos du vrai clients (ptete pas obligatoire)
                http-request add-header X-Forwarded-Proto https if { ssl_fc }
                option forwardfor
                # On force https (le navigateur du client va passer de HTTP a HTTPS tout seul) - nécésite d'écouter sur le port 443 (voir ligne plus haut)
#       acl http      ssl_fc,not
#       http-request redirect scheme https if http
                # On check la présence en ligne ou non du serveur (suffit de retirer le "check" dans la ligne du serveur pour qu'il n'effectue plus de check). Les check en mono serveur n'ont d’intérêt que si tu veux suivre les statistiques.
        option httpchk GET http://1.2.3.4/html/index.html HTTP/1.0
                # Gestion des cookies
                cookie SERVERID insert indirect nocache
                # Modification du host (le backend croira que le client contacte 1.2.3.4)
        http-request set-header Host "1.2.3.4"
                # Ton équipement
    server mon_equipement1 1.2.3.4:80 weight 1 check cookie mon_equipement1

La ligne importante c'est http-request set-header Host "1.2.3.4"

Le problème semble plus la redirection vers une IP interne au LAN.
Peut-être utiliser HaProxy comme mentionné par NeoX, mais en tant que Frontend. Ça signifie que ton NAT redirigera vers ton HaProxy qui lui jouera l'intermédiaire entre ton équipement (qui sera le Backend) et toi.
HaProxy permet de "fake" le nom de domaine envoyé au Backend il me semble (infos), ceci afin que ton équipement n'envoie pas la redirection HTTP en pensant que tu le contactes bien depuis 1.2.3.4.
Un autre avantage, si ton équipement n'est accessible qu'en HTTP, tu pourras tout de même utiliser HTTPS depuis ton HaProxy : ainsi la liaison entre toi et HaProxy sera chiffrées (mais pas sur ton LAN entre ton HaProxy et ton équipement).

Je ne sais pas ce qu'est une seedbox Deluge, mais si tu es capable d'y associer un nom de domaine oui, tu peux la sécuriser par une des 2 techniques proposées par le protocole ACME.
Mon outil, acme-dns-tiny, par exemple nécessite une machine avec un service DNS qui est capable de faire de la mise à jour dynamique des ressources DNS grâce à TSIG. Sur une autre machine (ta seedbox par exemple), tu as juste besoin d'avoir python3 (avec les modules dnspython et requests) et openssl d'installé. Tu peux voir la documentation pour configurer ta seedbox et le serveur avec bind9 dans le wiki.
Cet outil, n'est pas le seul à savoir faire des certificats avec le challenge DNS, je te laisse chercher sur le web celui qui te convient le mieux.

Merci pour ces infos, je ne connaissais pas ce challenge.

Ça marche aussi avec les domaines dynamique du style dyndns ?

Si la machine qui demande le certificat est sur un réseau A et le serveur DNS sur un réseau B qui gère le domaine (les deux étant relié par une liaison quelconque), ça peut fonctionner ?

Note d'ailleurs que SSH a exactement le même défaut si tu n'installes pas les clés de l'hôte dans des ressources DNS sécurisées par DNSSEC: tu dois manuellement vérifier les fingerprint des certificats utilisé par SSH.

Ai-je énoncé "owai SSH c tro mieu" ? Non, je ne fais que troller Firefox et consort qui ont décidé que seul TLS devait être utilisé et que les alternatives sont juste bonne à jeter.
C'est comme si je te disais "j'aime SFTP" et que les commentateurs de LinuxFR passaient leur temps a répondre "si tu n'utilises pas FTPS c'est que tu utilises FTP et donc ta sécurité c'est de la merde". Pour un site censé être peuplé de gens callés, c'est fort kikoolol.

C'est un peu dans le désordre sorry. 😄

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. 😀

Voila l'exemple typique des gens qui ne savent pas que l'on peut connecter des serveurs à un VPN et y utiliser les WEBUI, et qui pense donc qu'un VPN ne sert qu'à rediriger du trafic réseau pour un navigateur. 😂
On parle d'un curl http://10.8.42.42 pas d'un curl www.google.com 😉

Je ne saisi pas l'intérêt de ne chiffrer les données que sur la première partie du chemin. Peux-tu expliquer ?

Si tu parles du VPN, je rappel qu'un VPN à la base ça sert à créer "un réseau privé virtuel", pas à matter Arte.

Bête démonstration :
Pour ce tutoriel un client passe par une connexion HTTP (sans S) pour wget les infos sur un serveur web. Les données sont chiffrées (avec pour openvpn une séance de déchiffrement puis rechiffrement quand les données passent par le VPN, par contre il me semble que Wireguard n'a pas ce soucis pas franchement écolo).
HTTPS en autosigné serait inutile (facile à craquer), et mettre en place un HTTPS signé pour chaque serveurs (voir services) Backends serait un pourrissage de config pas possible (sans compter que ce n'est pas forcément possible, Let's Encrypt veut du port 80 ou 443, pas pratique lors des renouvellement si tu as plusieurs machines sur une même IP).

Tu insistes sur le fait que HTTPS dans une surcouche chiffrée est idiot.

Plus tôt inutile (voir dangereux) et un gaspillage d'électricité, juste pour faire plaisir à papa Google.

Et j'avoue ne pas avoir envie de perdre mon temps à passer du HTTPS partout pour la moindre petite webui qui ne listen déjà que sur des IP non routable. (genre comme c'est parti là, Firefox va bientôt bloquer l'accès à l'IOT "parce qu'on sait mieux que vous ce qui est bon pour vous dans de" (tiens ça rappel la télévision et les politicards)).

en parlant de permissions, l’accès à la caméra et au microphone sera refusé en l’absence d’une connexion sécurisée via HTTPS 

Objectif : un internet uniquement conçu pour les gafams.

Donc en gros, ça ne fonctionnera pas sur votre site :

1. en HTTP dans un VPN,
2. en HTTP derrière Tor Hidden Service,
3. en HTTP derrière I2P,
4. en HTTP derrière tunnel SSH.

Les dernières versions permettent de monter des stockages distants.

Ces montages n'ont pas besoin de l'utilisateur www-data (au cas où cette phrase serait liée à la suivante).
Par contre l'accès au fichier via ce type de montage n'est pas aussi fluide que si tu montes directement tes dossiers dans le filesystem de ton OS. (c'est surtout chiant quand tu uploads de gros fichiers, ou que tu veux charger la galerie et que tu as des images sur des dossiers distants)

je dois mettre le user www-data propriétaire des données….. et je veux pas….

Tu peux forcer apache2 à utiliser un autre utilisateur, voir même un utilisateur spécifique pour un VHOST (et donc utiliser plusieurs utilisateurs pour apache2).

Voila se qui se passe quand le débat est polarisé à coups de "pour" et de "contre".
On te sort des exemples tiré par les cheveux.
Tu compares deux défragmenteurs de disque, on te rétorque "qu'est-ce que t'as contre la défragmentation"…

tu sous entends que généraliser le passage à HTTPS (côté navigateur / client) c'est mal

Non, je me méfie de la tentative de restreindre à une technologie en oubliant qu'il existe des alternatives (routage en onion, SSH, I2P, VPN, etc).
Il ne serait pas logique que demain mon Firefox me bloque l'accès aux stats de mon HaProxy sous prétexte que j'y accède en HTTP, alors que la communication est protégée par un VPN qui est plus sécurisé qu'un TLS trusté. *1

C'est comme si tu appréciais utiliser Thelia et Prestashop (des e-shop), et que demain je te menaçais de bloquer tout se qui n'est pas Prestashop.

1 Si un pays MITM un nom de domaine d'un VPN, les clients du VPN ne vont plus accepter de se connecter. Si un état MITM un domaine d'un TLS trusté, les navigateurs ne verront rien c'est le serveur qui va devoir checker les adresses IP pour chercher l'anomalie.

On ne doit pas avoir peur de rendre des applications non fonctionnelles s'il avère qu'ils usent et abusent d'un protocole qui n'est plus en phase avec les recommandations de sécurité minimales de notre temps.

Boaf le sujet est plus complexe.
- Quid de la question monétaire (exemple le monde de la vidéos surveillance grand publique est bourré à craquer de ce genre de prob) ? Par exemple le blocage d'ActiveX a cassé les interfaces d'un nombre incroyable de Foscam (et donc, je suppose, le renouvellement du matos pour les non-hacker)
- Quid du retro ?
- Quid de l'IOT ?

et que tu devrais donc ne pas du tout avoir confiance, donc partir

Et tu crois que je pense différemment ?
Mais mon client m'avait répondu que c'est moi qui était qu'un noob qui devait apprendre à se débrouiller avec se qu'on lui donne et qu'il ne comptait pas changer d'hébergeur. ("si non j'ai trouvé un site où je peux engager des indiens pour peanuts")

Arrêtez avec vos FUD anti vie privée et anti-sécurité, ça gonfle.

😂 😂 😂
C'est une belle contradiction aux arguments que tu me sors quand on se dispute autour de Tor et des Cryptomonnaies. 😄

rien à voir avec des "applis" car on parle du navigateur

"Site internet", ça sous entends qui ne fait qu'afficher du contenu, c'est un peu "has been" AHMA.
Example : ZoneMinder est une application dont la WEBUI est accessible via navigateur.

donc avec des données sensibles qui transitent en clair.

HTTPS autosigné on le fait sauter en 30 secondes grâce a Youtube + Kali Linux.
Donc admettons que doit faire Foscam pour sécuriser ses caméras ?
HTTPS signé sur de l'IOT peut être ? 🤭 (qui par design n'est pas censé être accessible sur le net à tout le monde mode OpenBar)

Le chiffrement par le VPN protège d'un regard indiscret du fournisseur du VPN, tu en es sûr? Hum…

Osef si tu gère tes webservices tu gère aussi le VPN (qui est très utile pour ne plus dépendre d'un TLS qui dépends lui-même d'un nom de domaine qui peut être MITM par un gouvernement).
Tu peux aussi faire pareil avec des tunnels SSH.

Mais c'est vraiment triste que ce genre d'outils attende qu'on lui botte le cul pour que ce soit natif.

C'est natif si tu passes par un frontend. Mais c'est du boulot inutile en plus (rajouter un nom de domaine, le certifier, le maintenir). Alors que bêtement connecter au VPN et ne bind que sur une IP interne au VPN est suffisant

Sous entendu que le HTTPS est mal

L o o o o L
Non j'ai mentionné que bloquer les connexions HTTP sans S allaient provoquer un break.
Mais comme d'hab, certains sont incapable de faire autre chose que de polariser toute discutions histoire de pondre des threads où ils s'imaginent avoir une plus grosse que les autres.
Regarde, je haï tellement HTTPS que je n'explique surtout pas aux gens comment le mettre en place lorsqu'un projet ne l'a pas intégré… 🙄

PS : au final TLS est très proche de SSH. Quand quelqu'un parle de SSH vous ne vous bloquez pas sur "il est pour ou contre". La même logique devrait être appliquée avec TLS.

Tu parles de quel type d'applications ?

Par exemple les WEBUI de certaines caméras de surveillances (toutes celle à moins de 50 balles qui sont déjà à moitié petée), les WEBUI de certains logiciels serveurs (Shinobi, les stats de HaProxy), etc.

Les longues clés RSA posent de toute façon des problèmes de performance et on s'oriente donc sur des problèmes de courbes elliptiques, qui utilisent des clés bien plus courtes pour la même sécurité.

C'était juste un exemple de cas de figure ou TLS n'est pas du tout requis.
HTTPS dans un VPN n'apporte que "l'identité" de l'hôte (si certifs signé et non falsifié). Le chiffrement de la ligne étant déjà géré par le VPN.

Pour les services onions, c'est un peu plus discuté effectivement. Notamment parce que l'échange est déjà chiffré pour les services onions, pas besoin de HTTPS pour ça. Mais je ne vois pas d'inconvénient particulier à le faire si tu parviens à avoir un certificat pour ça.

Ma réflexion concernait bien entendu les .onion. Visiter des sites "normaux" sans https depuis le réseau TOR c'est du suicide.
D'après une discutions avec le dev de RetroShare, certains algos de chiffrements ne doivent pas être superposés au risque d'apporter des fragilités (de souvenir, il devient plus facile d'identifier les algos et de distinguer les fakes datas des vrais).

Sur le long terme, la plupart des sites vont être plus ou moins forcés de passer en HTTPS only de toute façon puisque Google et Mozilla notamment prévoient de bloquer le HTTP sans chiffrement.

Ce jour là ils auront pété un nombre incroyable d'applications libre (sauf pour ceux qui manient le proxy) et augmenté la pollution (https sur un VPN/SSH avec une clés de 4000bit, c'est du pétrole gaspillé), voir même diminué la sécurité (le sur-chiffrage peu avoir des effets inverses).
Et n'oublions pas le réseau Tor où https est décrié.

Pourquoi ce moissage ?
J'ai déjà rencontré ce cas de figure d'un hébergeur pro où https coûtait un truc comme 20€/mois alors qu'on peut avoir du Let's Encrypt sur nos propres serveurs via un simple script bash et sans débourser 1€.