Ainda bem que você mencionou esse último ponto entre parênteses, porque me convenceu. ;-P

@TX e eu tivemos uma grande discussão sobre colocar partes de configuração na página de status no IRC e ainda estou muito desconfortável em fazer a página de status de leitura-escrita e baseada em script (porque, você sabe, abre a possibilidade de brechas de segurança). E ainda vejo o maior problema na "palavra-código": as pessoas vão digitar cegamente suas senhas usuais, não importa quão grande, gordo, ousado e piscante o aviso é para não fazê-lo. E a configuração da palavra-código realmente deveria chegar ao modo especialista, eu acho.

Se isso for implementado, talvez seja possível implementar a autenticação usando HTTP Digest? Dessa forma, um invasor teria que usar MITM em vez de farejar.

Sim, concordo com o problema de fluxo de trabalho. E minha opinião é que esta é uma solução suficiente. Mas ainda assim o usuário precisa descobrir o endereço IP do nó para acessar a interface. Portanto, proponho que exibamos o possível link http ipv6 na última página do assistente do roteador.

Mas, para se preocupar, a implementação desse recurso levantará outras reclamações sobre o recurso X que deve ser acessível de maneira semelhante. E minha opinião é que não devemos jogar pedras no caminho do usuário, mas também um usuário que instala tecnologia deve estar ciente disso e ser capaz de administrá-la. Especialmente se for uma instalação de telhado ao ar livre.

Comprimido: implemente, mas prepare seus argumentos.

Resumo HTTP

Eu adoraria usar autenticação baseada em resumo. Infelizmente, o uhttpd não o suporta.

Problemas de segurança / injeção de código

Tenho certeza de que podemos lidar com isso bem. Não ouvi falar de nenhum problema de injeção de código com o luci, então provavelmente há apenas alguns. Também poderíamos executar fuzzers para testá-lo.

Palavra-código / senha do usuário

Poderíamos tornar o campo de entrada no configmode um campo normal (ou seja, sem estrelas) e definitivamente devemos adicionar uma explicação curta, mas concisa, dos riscos de segurança e, novamente, desencorajar o usuário de definir uma palavra-código.

Se eles ainda inserirem a senha padrão, não há muito que possamos fazer e eles estão com problemas de qualquer maneira.

Link para o nó

Este é realmente um problema não resolvido. Eu poderia me imaginar exibindo o endereço IPv6 do nó logo abaixo do campo de entrada da palavra-código, como: "Marque este [link] para alterar as coordenadas do seu nó quando ele estiver em execução."

Outras solicitações de recursos semelhantes

Escolhi isso muito, muito estreito de propósito, porque estou ciente dessas outras questões. O objetivo maior que ainda gostaria de alcançar é me livrar do configmode e fazer tudo durante a operação normal, remotamente na malha. No entanto, para que isso seja seguro, temos muitos problemas para resolver.

Se alguém solicitar um recurso semelhante, devemos encaminhá-lo para este problema ou para uma página wiki resumindo tudo. Em qualquer caso, devemos solicitar que ele escreva uma edição abrangente sobre o recurso desejado, abordando todas as questões de segurança mencionadas aqui e nas discussões que teve com outros desenvolvedores. Se ele tiver sucesso, ele pode realmente ter um ponto válido.

Palavra-código única

Acabei de ter outra ideia, mas não gostaria de discuti-la aqui, pois pode atrapalhar muito o fluxo de trabalho. Certamente discutiremos isso depois que minha solução atual for aceita ou rejeitada.

A palavra-código pode ser usada apenas uma vez. Por exemplo, o primeiro que altera as coordenadas (na página de status) e insere a palavra-código correta é bem-sucedido. Depois disso, é bloqueado e outra palavra-código deve ser definida no configmode.

Isso pode ser opcional, mas temo que torne o configmode complexo novamente (2 caixas de seleção, 3 campos de entrada para definir as coordenadas).

O HTTP digest não deveria ser implementável no script por trás de uhttpd também? Afinal, são apenas cabeçalhos e outras coisas ...

Eu definitivamente voto contra a implementação disso no primeiro lançamento do Gluon. Rejeitamos tornar a página de status mais agradável, o que é uma mudança relativamente sem importância, então não devemos jogar essa pilha de perguntas na primeira rodada, eu acho.

Não está marcado com um marco, então definitivamente não é um obstáculo para 2014.1, no entanto, se concordarmos em construí-lo, ele pode chegar a 2014.1.

Sim, você está certo. O resumo HTTP pode ser implementado usando apenas cabeçalhos.

Voltar para a autenticação baseada em senha para qualquer coisa parece um grande retrocesso para mim.

Achei que já tínhamos uma solução para o problema do mapa? Quase todos os usuários estão em uma WLAN de qualquer maneira ao configurar seu nó, então podemos apenas carregar um mapa da Internet. Precisamos apenas fornecer um bom substituto (campos de entrada) para o caso em que não o são.

E não vejo problema em os usuários precisarem voltar ao modo de configuração uma vez ao instalar um nó em algum lugar.

Outra opção pode ser tornar uma página de configuração especial acessível usando o túnel reverso SSH. Isso exigiria que o usuário fornecesse sua chave pública SSH durante o configmode.

Por que não ter uma página de configuração especial acessível via http: //node.ffhh quando o nó é conectado pela primeira vez à rede freifunk (via mesh ou vpn). se o proprietário não visitar o modo de configuração, o freifunk não funcionará. talvez com o botão reset como algum tipo de autenticação ("pressione este botão html e o botão reset dentro de 30s para permitir a configuração do nó").

Estou pensando nisso como uma espécie de configuração plug and play com registro automático do nó na primeira inicialização. a conexão automática à rede freifunk (mesh ou vpn) permitiria exibir um mapa e assim por diante.

Não acho que alguma interação de hardware seja possível se o nó já estiver em algum local remoto. Também para dispositivos, por exemplo, dispositivos ubnt, acessar um botão de hardware é meio difícil.
Em vez de alguma interface http direta, devemos considerar uma interface de configuração baseada em ssh.
Que pode então ser acessado por meio de uma interface segura de https de terceiros.
A implementação da interface de configuração ssh requer um usuário com um shell de configuração especial,
que não deve permitir nenhuma outra interação.

Alguma solução até agora? Alguém já implementou algo assim localmente?

hexa teve a ideia de usar um OTP baseado em tempo (ou seja, RFC 6238) para autenticação. Eu meio que gosto dessa abordagem. Para que isso funcione, o usuário verá um código QR (+ string) para configurar o "Cliente" OTP (ou seja, um smartphone). O usuário deve ser capaz de redefinir o token (ou desativar o recurso completamente).

isso está longe de ser a ideia conveniente de fácil configuração geo com página de status (com qualquer modo de autenticação) .. mas se você tiver conexão ssh e não se assustar com terminais - aqui estão alguns minisripts úteis como lat lon alt localização geoguess https: / /github.com/viisauksena/gluon-banner/tree/master/files/usr/bin/ você pode adicionar por padrão aos seus nós ou firmware

Que tal uma grande dica

Certifique-se de anotar as coordenadas geográficas antes de continuar

que será mostrado apenas uma vez na primeira chamada do modo de configuração após uma nova instalação?

@blocktrron @mweinelt @rotanid Podemos fechar isso?

NeoRaider disse

E não vejo problema em os usuários precisarem voltar ao modo de configuração uma vez ao instalar um nó em algum lugar.

Acho que isso é verdade ... Voltar para o modo de configuração é viável. Nenhuma solução excessivamente complicada é necessária aqui e isso não foi implementado em 5 anos. Então isso possivelmente nunca será concluído ...