Comments 38
1. ключи и настройки передаются поверх дикого интернета по незащищенному http?
2. все таки нужны публичные ноды?
3. было бы наверное интереснее, когда сеть работала бы в принципе без публичных нод, а вместо ip использовала адреса tox сети… И поиск нод велся бы используя публичные ноды tox и DHT, коими является любой клиент, бот, нода…
- Там зашифрованная передача. Я акцентировал внимание на этом в трёх местах в статье. Можно перед сервисом поставить ssl proxy (nginx..), если будет спокойнее.
2, 3. Спасибо, так наверное можно сделать. Но нужно детально проработать
Так можно было бы и в через tor пустить поверх например HiddenService
Во-первых, все-же трафик зашифрованный и аутентифицированный, пусть и передаваемый по открытым каналам связи. Подменить или прочитать сообщение (не зная токен) нельзя.
Во-вторых, предположим будет возможность задавать сертификаты (это не сложно добавить). Тогда Вам либо (а) придется добавлять сертификаты в доверенные каждого устройства (при самоподписанном сертификате), либо (б) использовать честные сертификаты (let's encrypt например), что в Вашем контексте о роутере звучит необычно. С другой стороны, для серверов это имеет смысл.
Реализовать несложно. Если Вас не затруднит, можете, пожалуйста, оформить это как feature request на github?
Главный недостаток всех существующих решений mesh сетей именно отсутствие возможности простой настройки/установки на роутерах.
Именно на домашних роутерах таким решениям самое место.
Если скинете ссылки на какой-нибудь простой туториал по запаковке в openwrt, то я могу попробовать сделать в свободное время.
или вот эта:
teamhelps.pp.ua/top/kompilyaciya-svoikh-prilozheniy-dlya-openwrt
А сколько у вас нод и как часто появляются новые?
PS: А какого размера сети реально работают на tinc? Быстрый поиск не дал результата, вдруг Вы в курсе…
Спасибо! Увы, выборки по другим пользователям у меня нет.
Грубо говоря, вы сосредоточились на версии 1.0 в которой применяется устаревший тип аутентификации и отсутствует поддержка
эллиптики.
А так же отказались от механизма инвайтов который делает ровно то же самое что и ваш сервис.
То есть, фактически, вы взяли с пыльной полки кактус и героически его съели.
Это я к тому что в версии 1.1 именно для данных целей был внедрён механизм инвайтов, а для деплоймента ключей остальных участников достаточно доверия к "boot" ноде.
То есть, это все решается просто использованием версии 1.1 с необходимыми параметрами в конфигурации.
Зачем в 2019 использовать устаревшую версию и героически пытаться пеиеизобрести то что уже сделано и работает?
1.1 безусловно шаг вперёд. Напомните, пожалуйста, когда они в релиз планируют вывести?
Я то этого уже жду несколько лет.
Смею заметить, Ваша фраза про кактус несколько категорична. У меня нет ни малейшего желания изобретать велосипед. Однако пользоваться продуктом в нерелизной версии в вопросах безопасности — неоправданный (для меня) риск.
Так что либо кто-то принимает риск и пробует все новое (я так понимаю Ваш случай), либо кто-то (как я) используют проверенные решения и адаптируют их под нужные условия.
Это очень однобокое оправдание.
Не напомните сколько раз за этот год выходили патчи стабильной openssl?
Как же так, ведь это проверенное решение?
Tinc 1.0 по части механизмов аутентификации именно фундаментально уступает 1.1.
Потому мое сравнение с пыльной полкой и кактусом как раз кстати, я не просто так это написал.
В использовании RC нет ничего плохого. OpenWrt (как пример) последние стабильные релизы выпускали на основе ветки wireless-testing или backports в статусе RC.
Ubuntu уже много лет тащит пакеты из debian testing и experimental. Так что про риски и прочие это не более чем притянутые за уши аргументы.
Завтра случится очередной heartbleed и что, это повод не использовать новые "непроверенные" версии opensssl и сидеть на 1.0 ?
LibreOffice регулярно релизятся, а потом дают отмашку о том с какой минорной версии по их мнению "можно в продакшен".
Так что я вам рекомендую перестать фиксироваться на цифрах и смотреть больше на стабильность API. В этом плане Tinc 1.1 давно созрел.
А вот чтобы говорить об ограничениях, нестабильности или недостаточной готовности той или иной версии, требуется как минимум изучить примеры использования других людей, а ещё лучше приложиться самому и тоже протестировать. В таком случае это будет предметный разговор.
А сидеть на стуле и рассуждать "ну, они что-то не релизят и я опасаюсь" — это, пардон, балобольство.
Изменение циферки в версии это не причина того на сколько ПО стабильно, а следствие.
В вашем случае это не "использование проверенного решения и адаптация", а
1) Дублирование уже имеющейся, работающей и протестированной функциональности.
2) Подталкивание пользователей к использованию менее надёжного механизма аутентификации.
И все это сознательно, исключительно на поводу у собственных предрассудков, раз вы в курсе про существование версии 1.1.
Или вы не разобрались и не изучили работу механизма инвайтов и распространения ключей без непосредственного их добавления, на основании доверия к промежуточным нодам?
Просто бегло по верхам прочитали мануал, нашли фатальные недостатки и пошли писать?
К слову, версия 1.1 на данный момент есть даже в debian experimental. Не говоря о ppa и с сторонних репозиториях.
Плюс tinc invite на условном «сервере».
По поводу доступности. Свежая FreeBSD:
# pkg search tinc
tinc-1.0.35_1 Virtual Private Network (VPN) daemon
tinc-devel-1.1pre17_3 Virtual Private Network (VPN) daemon
В целом я свою точку зрения высказал выше, но забыл добавить:
- 1.1pre17 — вышла 11 месяцев назад
- 1.0.36 — 3 недели назад. Часть комитов — бэкпорт из 1.1.
Бэкпорт о котором речь попал туда пол года надаз, а до этого, соответствено присутствовал в версии 1.1.
Последние коммиты — это исправления опечаток, выравнивание отступов и прочие вещи которые обычно делают коты когда у них других занятий нет.
Пройдите сюда и посмотрите что это за релиз
https://github.com/gsliepen/tinc/commits/master
Хватит мыслить как школьник и фапать на циферки.
Посмотрите к чему это привело. Я уже высказывался выше.
1) Дублирование функциональности
2) Навязывание пользователем устаревшего и менее безопасного протокола.
Могу я Вас попросить все же не использовать подобного рода формулировки? "Фапать", "школьник" — не тот уровень диалога, который обычно ожидается на профессиональном ресурсе.
Мне кажется есть определенного уровня недопонимание:
- Я не навязываю никому и ничего — есть проблема: сложность настройки Tinc 1.0 в ряде ситуаций. Одно из решений — tinc-boot.
- В статье однозначно описывается взаимодействие с Tinc 1.0. Смысл обсуждать 1.1 — если в статье в явном виде описано ограничение на 1.0? Это вне рамках текста. Если есть желание пообщаться — можно перейти в личные диалоги.
- Я обосновал свое решение относительно 1.0. Вы и некоторые другие с ним не согласились. С моей точки зрение имеется паритет мнений. Дальнейшее обсуждение не имеет смысла (как мне кажется).
Я ни в коей мере не ограничиваю (и не навязываю) ни Вам лично, ни читателем единственное верное решение. Это сугубо личное решение каждого. Доводы "за" и "против" приведены. Далее — вопросы приоритетов и личных предпочтений.
Для меня лично, использовать в критичных местах (а вопросы безопасности я считаю критичными) версии продуктов, которые не помечены как стабильные не приемлемо. Можете считать это профессиональной деформацией.
Поэтому, вы себе противоречите.
- Одно из. Тут напрашивается картинка про конкурирующие стандарты. Вы просто сделали "свое". И при этом не решили никакой проблемы. Потому ваш результат заслуживает порицания.
- В статье описывается метод, прибитый гвоздями к устаревшей версии. С тем же успехом вы могли бы написать библиотеку, прибитую гвоздями к python 2.7 и при этом имеющуюся в версии 3.
Вы бы тоже утверждали что писали осознанно под 2.7 и явно ограничили это в статье, а критика подобного это "вне контекста"?
Нет, милейший, вы решили выложить свои наработки в открытый доступ и даже написали статью. "Выйти и поговорить" это другой формат, будьте готовы пояснить за свое решение публично - Вы ничего не обосновали. Все ваши доводы из разряда "потому что могу". Сравнения версий не проводилось, объективных аргументов в пользу выбора версии не приводилось. Только ваши фантазии и страхи.
Вы пытаетесь опровергнуть то чего я не говорил.
Вы ПОДТАЛКИВАЕТЕ пользователей к использованию менее безопасного протокола. И это даже еще хуже чем если бы вы что-то утверждали. Потому что в таком случае можно было бы оспорить или опровергнуть утверждения. А тут вы просто даете инструмент, который заведомо deprecated и еще вдобавок РЕАЛЬНО снижает безопасность решения вцелом. Но при этом он позиционируется как "то что избавит вас от боли".
Осознанно или по незнанию, но вы сделали ужасную вещь.
Можно пожалуйста доказательство того, что есть неисправленные уязвимости Tinc 1.0.36 и исправленные/недопущенные в 1.1? Это серьезное заявление, которое действительно имеет смысл в нашем обсуждение. Вы уже второй комментатор, который ссылается на это.
- Я не уловил, но как это относится к предмету обсуждения? Я же не свой VPN создавал, а обертку. Возможно вы имели ввиду, что есть другая функционально схожая обертка (для 1.0.x)? Буду признателен, если скинете ссылку.
- Как можно называть версию устаревший, если (а) обновления выходят регулярно, (б) нет другой версии этого же продукта в релизной версии? В Вашем примере про питон: версии py3-RC, не позиционировались как готовые решения для замены 2.7. Только с момента релиза.
- Тут есть фундаментальная проблема: с моей точки зрения, довод в пользу 1.0 — его стабильность и актуальность, 1.1 — не релиз (что подчеркивается на сайте). С одной стороны, я признаю Ваши аргументы в пользу 1.1 (функциональность, удобство и в целом более продуманный дизайн). С другой, Вы мои аргументы не признаете. Логический тупик для диалога. Ну или диалог превращается в монолог.
This legacy authentication protocol has several weaknesses, pointed out by security export Peter Gutmann. First, data is encrypted with RSA without padding. Padding schemes are designed to prevent attacks when the size of the plaintext is not equal to the size of the RSA key. Tinc always encrypts random nonces that have the same size as the RSA key, so we do not believe this leads to a break of the security. There might be timing or other side-channel attacks against RSA encryption and decryption, tinc does not employ any protection against those. Furthermore, both sides send identical messages to each other, there is no distinction between server and client, which could make a MITM attack easier. However, no exploit is known in which a third party who is not already trusted by other nodes in the VPN could gain access. Finally, the RSA keys are used to directly encrypt the session keys, which means that if the RSA keys are compromised, it is possible to decrypt all previous VPN traffic. In other words, the legacy protocol does not provide perfect forward secrecy.
SPTPS, который используется в версии 1.1.
Спасибо за детали.
Не считая perfect forward security — это отсылка на CVE-
2018-16758, которая исправлена после 1.0.34
А почему вы считаете что можно забить на PFS и пользоваться legacy схемой когда перехват/кража ключа позволяет расшифровать ВЕСЬ собранный до этого трафик?
Это приемлемо во славу стабильного релиза?
Нет, отнюдь. PFS это серьезный довод, чтобы присмотреться к 1.1 (даже если он и не в релизе).
Я считаю что есть смысл добавить это в стаью. Собствено, ради этого и я вступил в дискуссию, пытаясь хоть как-то указать на неконструктивность подхода "because I can" и недостаточно глубокое изучение вопроса.
Три момента заслуживающих внимания читателей:
1) В серсии 1.1 данная вункциональность уже реализована из коробки.
2) Методы аутентификации в версии 1.1 более безопасны, но обратно не совместимы с 1.0 и бэкпортированы не будут никогда.
3) Исходя из официальной документации 1.0 версия считается legacy, хотя для нее и выходят корректирующие релизы (прямо как gnupg, правда?) и тем кто заботится о безопасности следовало бы присмотреться к механизму инвайтов и новой версии Tinc.
я как раз меш сеть делаю с пробивкой натов и тд
Проблема WireGuard в том что это исключительно TUN (L3). В то время как TINC умеет и TUN (L3) и TAP (L2).
Работает в пространстве ядра (модуль).
Проблема Tinc в том что он прибит гвоздями к OpenSSL.
Работает в пространстве пользователя (демон).
То есть, чисто менеджерским взглядом будет казаться что это отличная перспектива. Но на деле это два абсолютно разных проекта.
Я так понимаю, что если два устройства, у которых в конфиге tinc стоит connectto = China внезапно окажутся подключены к одной wi-fi точке, то пакеты между ними всё равно будут ходить через Китай, разве нет?
Говорят для mesh yggdrasil хорош.
tinc-boot — full-mesh сеть без боли