Menos mal que mencionaste ese último punto entre paréntesis, porque me convenció. ;-PAG

@TX y yo tuvimos una gran discusión sobre poner partes de configuración en la página de estado en IRC y todavía me siento muy incómodo al hacer que la página de estado sea de lectura-escritura y basada en scripts (porque, ya sabes, abre la posibilidad de agujeros de seguridad). Y todavía veo el mayor problema en la "palabra clave": la gente ingresará a ciegas su contraseña habitual allí, sin importar cuán grande, gruesa, audaz y parpadeante sea la advertencia de no hacerlo. Y creo que la configuración de la palabra en clave debería llegar al modo experto.

Si esto se implementa, ¿quizás sea posible implementar la autenticación mediante HTTP Digest? De esa manera, un atacante tendría que usar MITM en lugar de solo olfatear.

Sí, estoy de acuerdo con el problema del flujo de trabajo. Y mi opinión es que esto es una solución suficiente para un beso. Pero aún así, el usuario debe averiguar la dirección IP del nodo para acceder a la interfaz. Así que propongo que deberíamos mostrar el posible enlace http ipv6 en la última página del asistente del enrutador.

Pero, para preocuparse, la implementación de esta función generará otras quejas acerca de que la función X debería ser accesible de manera similar. Y mi opinión es que no debemos tirar piedras en el camino de los usuarios, sino que también un usuario que instala tecnología debe ser consciente de ello y ser capaz de gestionarlo. Especialmente si se trata de una instalación de techo al aire libre.

Comprimido: impleméntalo, pero prepara tus argumentos.

Resumen HTTP

Me encantaría usar la autenticación basada en digest. Desafortunadamente, uhttpd no lo admite.

Problemas de seguridad / inyección de código

Estoy seguro de que podemos manejarlo bien. No he oído hablar de ningún problema de inyección de código con luci, así que probablemente solo haya unos pocos. También podríamos ejecutar fuzzers para probarlo.

Palabra clave / contraseña del usuario

Podríamos hacer que el campo de entrada en configmode sea un campo normal (es decir, sin estrellas) y definitivamente deberíamos agregar una explicación breve pero concisa de los riesgos de seguridad y, nuevamente, disuadir al usuario de establecer una palabra clave.

Si aún ingresan su contraseña estándar, no hay mucho que podamos hacer y de todos modos están en problemas.

Enlace al nodo

De hecho, este es un problema sin resolver. Me imagino mostrando la dirección IPv6 del nodo justo debajo del campo de entrada de la palabra de código, como: "Marque este [enlace] para cambiar las coordenadas de su nodo una vez que se esté ejecutando".

Otras solicitudes de funciones similares

Encontré esto muy, muy estrecho a propósito porque estoy al tanto de esas otras preguntas. El objetivo principal que aún me gustaría lograr es deshacerme de configmode y hacerlo todo durante el funcionamiento normal, de forma remota a través de la malla. Sin embargo, para que esto sea seguro, tenemos muchos problemas que resolver.

Si alguien solicita una función similar, deberíamos dirigirlo a este problema o una página wiki que lo resuma todo. En cualquier caso, deberíamos pedirle que escriba un número completo sobre la función deseada que aborde todas las preocupaciones de seguridad mencionadas aquí y en las discusiones que tuvo con otros desarrolladores. Si tiene éxito, es posible que tenga un punto válido.

Palabra de código de un solo uso

Acabo de tener otra idea, pero me gustaría no discutirla aquí, ya que podría interrumpir demasiado el flujo de trabajo. Sin duda lo discutiremos después de que mi solución actual sea aceptada o rechazada.

La palabra en clave podría usarse una sola vez. Por ejemplo, el primero que cambia las coordenadas (en la página de estado) e ingresa la palabra de código correcta tiene éxito. Después de eso, está bloqueado y se debe configurar otra palabra de código en configmode.

Esto podría hacerse opcional, pero me temo que podría hacer que configmode vuelva a ser complejo (2 casillas de verificación, 3 campos de entrada para establecer coordenadas).

¿No debería implementarse HTTP digest en el script detrás de uhttpd también? Son solo encabezados y esas cosas, después de todo ...

Definitivamente voto en contra de implementar esto para la primera liberación de gluones. Rechazamos hacer que la página de estado fuera más agradable, lo cual es un cambio relativamente sin importancia, por lo que no deberíamos lanzar este montón de preguntas en la primera ronda, creo.

No está etiquetado con un hito, por lo que definitivamente no es un éxito para 2014.1, sin embargo, si aceptamos construirlo, podría llegar a 2014.1.

Sí tienes razón. HTTP digest podría ser posible de implementar usando solo encabezados.

Volver a la autenticación basada en contraseña para cualquier cosa me parece un gran salto hacia atrás.

Pensé que ya teníamos una solución para el problema del mapa. Casi todos los usuarios están en una WLAN de todos modos cuando configuran su nodo, por lo que podemos simplemente cargar un mapa desde Internet. Solo necesitamos proporcionar un buen respaldo (campos de entrada) para el caso cuando no lo sean.

Y no veo ningún problema con que los usuarios tengan que volver al modo de configuración una vez cuando instalan un nodo en algún lugar.

Otra opción podría ser hacer accesible una página de configuración especial mediante el túnel inverso SSH. Esto requeriría que el usuario proporcione su clave pública SSH durante el modo de configuración.

¿Por qué no tener una página de configuración especial accesible a través de http: //node.ffhh cuando el nodo se conecta por primera vez a la red freifunk (a través de mesh o vpn)? si el propietario no visita el modo de configuración, freifunk no funcionará. tal vez con el botón de reinicio como algún tipo de autenticación ("presione este botón html y el botón de reinicio en 30 segundos para permitir la configuración del nodo").

Estoy pensando en eso como una especie de configuración plug and play con registro automático del nodo en el primer arranque. la conexión automática a la red freifunk (mesh o vpn) permitiría mostrar un mapa y así sucesivamente.

No creo que sea posible alguna interacción de hardware si el nodo ya está en una ubicación remota. También para dispositivos, por ejemplo, dispositivos ubnt, acceder a un botón de hardware es algo difícil.
En lugar de una interfaz http directa, deberíamos considerar una interfaz de configuración basada en ssh.
A la que luego se puede acceder a través de una interfaz segura https de terceros.
La implementación de la interfaz de configuración ssh requiere un usuario con un shell de configuración especial,
que no debe permitir ninguna otra interacción.

¿Alguna solución por ahora? ¿Alguien ya implementó algo como esto a nivel local?

hexa tuvo la idea de utilizar una OTP basada en el tiempo (es decir, RFC 6238) para la autenticación. Me gusta ese enfoque. Para que esto funcione, se le mostrará al usuario un código QR (+ cadena) para configurar el "Cliente" de OTP (es decir, un teléfono inteligente). El usuario debe poder restablecer el token (o deshabilitar la función por completo).

esto está lejos de la idea conveniente de configurar geo fácilmente con la página de estado (con cualquier modo de autenticación) ... pero si tiene conexión ssh y no está asustado por los terminales, aquí hay algunos minisripts útiles como lat lon alt location geoguess https: / /github.com/viisauksena/gluon-banner/tree/master/files/usr/bin/ puede agregar por defecto a sus nodos o su firmware

¿Qué tal una gran pista?

Asegúrese de anotar las coordenadas geográficas antes de continuar

que se mostrará solo una vez en la primera llamada del modo de configuración después de una nueva instalación?

@blocktrron @mweinelt @rotanid ¿Podemos cerrar esto?

NeoRaider dijo

Y no veo ningún problema con que los usuarios tengan que volver al modo de configuración una vez cuando instalan un nodo en algún lugar.

Creo que esto es cierto ... Volver al modo de configuración es factible. Aquí no se necesita una solución demasiado complicada y esto no se implementó en 5 años. Así que esto posiblemente nunca se terminará ...