Heureusement que vous avez mentionné ce dernier point entre parenthèses, car il m'a convaincu. ;-P

@TX et moi avons eu une énorme discussion sur la mise en place des éléments de configuration dans la page d'état sur IRC et je suis toujours très mal à l'aise de rendre la page d'état en lecture-écriture et basée sur des scripts (car, vous savez, cela ouvre la possibilité de trous de sécurité). Et je vois toujours le plus gros problème dans le « mot de passe » : les gens entreront aveuglément leur mot de passe habituel, peu importe à quel point l'avertissement est gros, gras et clignotant. Et le réglage du mot de passe devrait vraiment passer en mode expert, je pense.

Si cela est mis en œuvre, il est peut-être possible de mettre en œuvre l'authentification à l'aide de HTTP Digest ? De cette façon, un attaquant devrait utiliser MITM au lieu de simplement renifler.

Oui, je suis d'accord avec le problème de workflow. Et mon opinion est qu'il s'agit d'une solution suffisante pour un baiser. Mais l'utilisateur doit toujours trouver l'adresse IP du nœud pour accéder à l'interface. Je propose donc d'afficher l'éventuel lien http ipv6 dans la dernière page de l'assistant routeur.

Mais pour être concerné, la mise en œuvre de cette fonctionnalité soulèvera d'autres plaintes concernant la fonctionnalité X qui devrait être accessible de la même manière. Et mon opinion est qu'il ne faut pas jeter des cailloux dans la voie des utilisateurs, mais aussi qu'un utilisateur installant une technologie doit en être conscient et capable de la gérer. Surtout s'il s'agit d'une installation sur un toit extérieur.

Compressé : mettez-le en œuvre, mais préparez vos arguments.

Résumé HTTP

J'aimerais utiliser l'authentification basée sur le résumé. Malheureusement, uhttpd ne le supporte pas.

Problèmes de sécurité / injection de code

Je suis certain que nous pouvons bien le gérer. Je n'ai pas entendu parler de problèmes d'injection de code avec luci, donc il n'y en a probablement que quelques-uns. Nous pourrions également exécuter des fuzzers pour le tester.

Mot de passe / Mot de passe de l'utilisateur

Nous pourrions faire du champ de saisie sur configmode un champ normal (c'est-à-dire sans étoiles) et nous devrions certainement ajouter une explication courte mais concise des risques de sécurité et, encore une fois, décourager l'utilisateur de définir un mot de code.

S'ils continuent à saisir leur mot de passe standard, nous ne pouvons pas faire grand-chose et ils ont de toute façon des problèmes.

Lien vers le nœud

C'est effectivement un problème non résolu. Je pourrais imaginer afficher l'adresse IPv6 du nœud juste en dessous du champ de saisie du mot de passe, comme : « Marquez ce [lien] pour modifier les coordonnées de votre nœud une fois qu'il est en cours d'exécution. »

Autres demandes de fonctionnalités similaires

J'ai volontairement défini cela de manière très très étroite parce que je suis au courant de ces autres questions. Le plus grand objectif que j'aimerais toujours atteindre est de me débarrasser du mode de configuration et de tout faire pendant le fonctionnement normal, à distance sur le maillage. Cependant, pour que cela soit sécurisé, nous avons beaucoup de problèmes à résoudre.

Si quelqu'un demande une fonctionnalité similaire, nous devrions soit le diriger vers ce problème, soit vers une page wiki résumant le tout. Dans les deux cas, nous devrions lui demander d'écrire un numéro complet sur la fonctionnalité souhaitée en répondant à tous les problèmes de sécurité mentionnés ici et dans les discussions qu'il a eues avec d'autres développeurs. S'il réussit, il pourrait en effet avoir un point valable.

Mot de passe unique

Je viens d'avoir une autre idée, mais je voudrais ne pas en discuter ici, car cela pourrait trop perturber le flux de travail. Nous en discuterons certainement une fois que ma solution actuelle sera acceptée ou rejetée.

Le mot de passe peut être utilisé une seule fois. Par exemple, le premier qui change les coordonnées (sur la page d'état) et saisit le mot de code correct réussit. Après cela, il est verrouillé et un autre mot de passe doit être défini en mode de configuration.

Cela pourrait être rendu facultatif, mais je crains que le mode de configuration ne soit à nouveau complexe (2 cases à cocher, 3 champs de saisie pour définir les coordonnées).

Le résumé HTTP ne devrait-il pas également être implémentable dans le script derrière uhttpd ? Ce ne sont que des en-têtes et des trucs, après tout...

Je vote définitivement contre la mise en œuvre de cela pour la première version de gluon. Nous avons refusé de rendre la page de statut plus agréable, ce qui est un changement relativement sans importance, nous ne devrions donc pas jeter cette pile de questions pour le premier tour, je pense.

Il n'est pas étiqueté avec une étape importante, donc ce n'est certainement pas un événement marquant pour 2014.1, mais si nous acceptons de le construire, il pourrait arriver jusqu'en 2014.1.

Oui tu as raison. Le condensé HTTP pourrait être implémenté en utilisant uniquement des en-têtes.

Revenir à l'authentification par mot de passe pour quoi que ce soit me semble être un énorme pas en arrière.

Je pensais que nous avions déjà une solution pour le problème de la carte ? Presque tous les utilisateurs sont de toute façon dans un WLAN lors de la configuration de leur nœud, nous pouvons donc simplement charger une carte à partir d'Internet. Nous avons juste besoin de fournir une bonne solution de repli (champs de saisie) pour le cas où ils ne le sont pas.

Et je ne vois pas de problème avec les utilisateurs qui doivent revenir au mode de configuration une fois lorsqu'ils installent un nœud quelque part.

Une autre option pourrait être de rendre une page de configuration spéciale accessible à l'aide du tunneling inverse SSH. Cela nécessiterait que l'utilisateur fournisse sa clé publique SSH pendant le mode de configuration.

Pourquoi ne pas avoir une page de configuration spéciale accessible via http://node.ffhh lorsque le nœud est d'abord connecté au réseau freifunk (via mesh ou vpn). si le propriétaire ne visite pas le mode config, freifunk ne fonctionnera pas. peut-être avec le bouton de réinitialisation comme une sorte d'authentification ("appuyez sur ce bouton html et sur le bouton de réinitialisation dans les 30 secondes pour permettre la configuration du nœud").

Je pense à cela comme une sorte de configuration plug and play avec enregistrement automatique du nœud au premier démarrage. la connexion automatique au réseau freifunk (mesh ou vpn) permettrait d'afficher une carte et ainsi de suite.

Je ne pense pas qu'une interaction matérielle soit possible si le nœud se trouve déjà sur un emplacement distant. Aussi pour les appareils, par exemple les appareils ubnt, accéder à un bouton matériel est assez difficile.
Au lieu d'une interface http directe, nous devrions envisager une interface de configuration basée sur ssh.
Qui pourrait ensuite être accessible via une interface sécurisée https tierce.
L'implémentation de l'interface de configuration ssh nécessite un utilisateur avec un shell de configuration spécial,
qui ne devrait permettre aucune autre interaction.

Des solutions maintenant? Quelqu'un a-t-il déjà implémenté quelque chose comme ça localement?

hexa a eu l'idée d'utiliser un OTP temporel (c'est-à-dire RFC 6238) pour l'authentification. J'aime bien cette approche. Pour que cela fonctionne, l'utilisateur recevrait un code QR (+ chaîne) pour configurer le "client" OTP (c'est-à-dire un smartphone). L'utilisateur doit pouvoir réinitialiser le jeton (ou désactiver complètement la fonctionnalité).

ce qui est loin de l'idée de convinient de géo réglage facile avec la page d'état (avec que ce soit en mode auth) .. mais si vous avez une connexion ssh et vous n'êtes pas frightend par des terminaux - voici quelques minisripts serviable comme lat LON emplacement alt geoguess https: / /github.com/viisauksena/gluon-banner/tree/master/files/usr/bin/ vous pouvez ajouter par défaut à vos nœuds ou à votre firmware

Qu'en est-il un gros indice

Assurez-vous d'avoir noté les coordonnées géographiques avant de continuer

qui ne s'affichera qu'une seule fois au premier appel du mode config après une nouvelle installation ?

@blocktrron @mweinelt @rotanid On peut fermer ça ?

NeoRaider a dit

Et je ne vois pas de problème avec les utilisateurs qui doivent revenir au mode de configuration une fois lorsqu'ils installent un nœud quelque part.

Je pense que c'est vrai... Revenir en mode config est faisable. Aucune solution trop compliquée n'est nécessaire ici et cela n'a pas été mis en œuvre en 5 ans. Donc ça ne sera peut-être jamais fini...