Хорошо, что вы упомянули последний пункт в скобках, потому что он меня убедил. ;-П

Мы с @TX долго обсуждали размещение частей конфигурации на странице состояния в IRC, и мне все еще очень неудобно делать страницу состояния для чтения-записи и на основе сценариев (потому что, как вы знаете, это открывает возможность для дыр в безопасности). И я по-прежнему вижу самую большую проблему в «кодовом слове»: люди будут слепо вводить туда свой обычный пароль, независимо от того, насколько большим, жирным, жирным и мигающим цветом предупреждение не должно этого делать. И установка кодового слова действительно должна попасть в экспертный режим, я думаю.

Если это будет реализовано, возможно, можно будет реализовать аутентификацию с помощью HTTP-дайджеста? Таким образом, злоумышленнику придется использовать MITM вместо простого сниффинга.

Да, я согласен с проблемой рабочего процесса. И я считаю, что поцелуй - достаточное решение. Но все же пользователю необходимо выяснить IP-адрес узла для доступа к интерфейсу. Поэтому я предлагаю отобразить возможную ссылку http ipv6 на последней странице мастера маршрутизатора.

Но следует опасаться, что реализация этой функции вызовет другие жалобы на то, что функция X должна быть доступна аналогичным образом. И я считаю, что мы не должны бросать камни в пользователей, но также и пользователь, устанавливающий технологию, должен знать об этом и уметь управлять ею. Особенно если это уличная кровельная установка.

Сжатый: Реализуйте это, но подготовьте свои аргументы.

Дайджест HTTP

Я бы хотел использовать аутентификацию на основе дайджеста. К сожалению, uhttpd его не поддерживает.

Проблемы безопасности / ввод кода

Я уверен, что мы справимся с этим хорошо. Я не слышал о каких-либо проблемах с внедрением кода с luci, так что их, вероятно, всего несколько. Мы также могли бы запустить фаззеры, чтобы проверить это.

Кодовое слово / пароль пользователя

Мы могли бы сделать поле ввода в configmode обычным полем (т.е. без звездочек), и мы определенно должны добавить короткое, но краткое объяснение рисков безопасности и, опять же, отговорить пользователя от установки кодового слова вообще.

Если они по-прежнему вводят свой стандартный пароль, мы мало что можем сделать, и у них все равно проблемы.

Ссылка на узел

Это действительно нерешенная проблема. Я мог бы представить отображение IPv6-адреса узла прямо под полем ввода кодового слова, например: «Добавьте эту [ссылку] в закладки, чтобы изменить координаты узла после его запуска».

Другие похожие запросы функций

Я намеренно ограничился этим очень узким кругом, потому что мне известно об этих других вопросах. Более важная цель, которую я все еще хотел бы достичь, - это избавиться от configmode и делать все это во время нормальной работы удаленно через сетку. Однако, чтобы это было безопасно, нам нужно решить множество проблем.

Если кто-то запросит аналогичную функцию, мы должны либо направить его к этой проблеме, либо на вики-странице, где все это подытожено. В любом случае мы должны попросить его написать исчерпывающий вопрос о желаемой функции, касающийся всех проблем безопасности, упомянутых здесь и в обсуждениях, которые он имел с другими разработчиками. Если ему это удастся, он действительно может иметь вескую точку зрения.

Одноразовое кодовое слово

У меня была еще одна идея, но я не хотел бы ее здесь обсуждать, так как это может слишком сильно нарушить рабочий процесс. Мы обязательно обсудим это после того, как мое текущее решение будет принято или отклонено.

Кодовое слово может использоваться одноразово. Например, тот, кто первым изменит координаты (на странице состояния) и введет правильное кодовое слово, преуспеет. После этого он заблокирован, и в режиме конфигурации необходимо установить другое кодовое слово.

Это можно сделать необязательным, но я боюсь, что это может снова усложнить configmode (2 флажка, 3 поля ввода для установки координат).

Разве дайджест HTTP не должен быть реализован в сценарии за uhttpd? В конце концов, это просто заголовки и прочее ...

Я определенно голосую против реализации этого для первого выпуска глюонов. Мы отказались делать страницу статуса лучше, что является относительно неважным изменением, поэтому, я думаю, нам не следует бросать эту кучу вопросов в первом раунде.

Он не отмечен вехой, поэтому он определенно не является показателем для 2014.1, однако, если мы согласимся построить его, он может дойти до 2014.1.

Да, ты прав. Дайджест HTTP можно реализовать, используя только заголовки.

Возвращение к аутентификации на основе пароля для чего-либо кажется мне огромным скачком назад.

Я думал, у нас уже есть решение проблемы с картой? Почти все пользователи в любом случае находятся в WLAN при настройке своего узла, поэтому мы можем просто загрузить карту из Интернета. Нам просто нужно предоставить хороший запасной вариант (поля ввода) на тот случай, когда их нет.

И я не вижу проблемы с тем, что пользователям придется один раз возвращаться в режим конфигурации, когда они где-то устанавливают узел.

Другой вариант - сделать специальную страницу конфигурации доступной с помощью обратного туннелирования SSH. Это потребует от пользователя предоставить свой открытый ключ SSH во время режима конфигурации.

Почему бы не иметь специальную страницу конфигурации, доступную через http: //node.ffhh, когда узел сначала подключен к сети freifunk (через mesh или vpn). если владелец не зайдет в режим конфига, фрейфанк работать не будет. возможно, с кнопкой сброса в качестве аутентификации («нажмите эту кнопку HTML и кнопку сброса в течение 30 секунд, чтобы разрешить настройку узла»).

Я думаю об этом как о какой-то настройке plug and play с автоматической регистрацией узла при первой загрузке. автоматическое подключение к сети freifunk (mesh или vpn) позволит отображать карту и так далее.

Я не думаю, что какое-то аппаратное взаимодействие возможно, если узел уже находится в каком-то удаленном месте. Также для устройств, например устройств ubnt, доступ к аппаратной кнопке довольно затруднен.
Вместо некоторого прямого интерфейса http мы должны рассмотреть интерфейс конфигурации на основе ssh.
К которому затем можно было получить доступ через защищенный интерфейс https третьей стороны.
Для реализации интерфейса конфигурации ssh требуется, чтобы у пользователя была специальная конфигурационная оболочка,
который не должен допускать никаких других взаимодействий.

Какие-нибудь решения к настоящему моменту? Кто-то уже реализовал что-то подобное локально?

Компания hexa пришла к идее использования OTP на основе времени (например, RFC 6238) для аутентификации. Мне вроде нравится такой подход. Для этого пользователю будет показан QR-код (+ строка) для настройки OTP «Клиент» (т.е. смартфон). Пользователь должен иметь возможность сбросить токен (или полностью отключить функцию).

это далеко от удобной идеи простой настройки гео со страницей состояния (с каким бы то ни было режимом авторизации) .. но если у вас есть ssh-соединение и вас не пугают терминалы - вот несколько полезных мини-скриптов, таких как lat lon alt location geoguess https: / /github.com/viisauksena/gluon-banner/tree/master/files/usr/bin/ вы можете добавить по умолчанию к своим узлам или вашей прошивке

Как насчет большой подсказки

Убедитесь, что вы записали географические координаты, прежде чем продолжить

что будет показано только один раз при первом вызове режима конфигурации после новой установки?

@blocktrron @mweinelt @rotanid Можем ли мы закрыть это?

NeoRaider сказал

И я не вижу проблемы с тем, что пользователям придется один раз возвращаться в режим конфигурации, когда они где-то устанавливают узел.

Думаю, это правда ... Возврат в режим конфигурации возможен. Здесь не нужно слишком сложного решения, и это не было реализовано за 5 лет. Так что, возможно, это никогда не будет закончено ...