Я рад, что Вы оценили эту технологию. Хочу заметить, что это не просто идея, а уже работающая система. И мы заинтересованы в её распространении. Так что если Вы начнёте использовать — мы только рады будем. Если есть вопросы — пишите на адрес, приведённый в статье.
Касаемо ж БД — не стоит беспокоиться, все ENUM-записи хранятся в хешевой базе данных Bdb, и скорость доступа туда весьма высокая — запрос отрабатывается единицы милисекунд. А как известно, скорость поиска в хеш-таблицах O(1), то есть не зависит от размера базы.
Тут речь идёт об одном из возможных вариантов кошелька — WEB-кошельке. Это как раз решение для «поколения WWW», которым лень ставить полный клиент.
А децентрализацию обеспечивают как раз таки полные клиенты (кошельки), которых подавляющее большинство.
Естественно, использование любого сервера, в том числе и E1, подразумевает доверие к этому серверу. Верите серверу — пользуйтесь. Не верите — скачивайте себе полную ноду, и будет Вам счастье с истинной децентрализацией.
Статья же фокусируется на архитектурных решениях, заложенных в основу WEB-версии кошелька, призванных минимизировать ущерб пользователей от возможных успешных атак на сервер.
Иностранные фамилия не всегда однзначно транскрибируются по русски. Применённая мною транскрипция применяется тоже, например тут. Также в русских текстах имеются варианты: Керкгоффса, Керкхоффа, и другие.
Интересное направление, надо б обдумать. Тут главное — отличить мошенника от честного пользователя, чтобы случайно не забанить «не того». Но можно даже подумать о том, чтобы сделать спец-верификатора, который как раз подписывает записи о мошенниках. И если клиент хочет активировать и использовать стоп-лист — он включает доверие к этому верификатору. А если не хочет — он отключает доверие, и записи о мошенниках для него становятся неактивными.
> Т.е. если я ночной сторож в Центробанке (...),
> то могу перевести на себя весь его телефонный трафик?
Да. Если есть доступ к соответствующему телефону.
Но в таком случае, сторож-вредитель много чего и другого сделать может — провода там в свитче переставить, комп вынести, двери хранилища открыть, и тп…
> Наверное, идентификация по ответу на телефон не настолько секъюрна,
> как верификация сайта через размещение контента.
Что делать… Идеальной системы нет. Могу только заметить, что e164.org, пока был жив, использовал этот же механизм, и всё работало нормально. Ну или если у Вас есть предложение, как улучшить систему верификации — мы рады будем ознакомиться.
> А что делать Центробанку, когда это обнаружится?
1. Уволить сторожа, влупив вдогонку штраф и уголовное дело о вредительстве и неавторизованном вмешательстве в работу инфосистемы.
2. Обратиться к верификатору с заявлением на отзыв подписи в комрометированной записи в ENUMER.
3. Создать свою запись с правильной подписью, и тем обрезать малину будущим сторожам.
> А какая экономика у верификатора?
Ответ на этот вопрос выходит за рамки статьи о технологии. Но в общем случае — какую экономику себе верификатор сделает, такая и будет.
> Он работает бесплатно?
На его усмотрение.
Система подразумервает нескольких верификаторов, и клиенты ENUMERа сами решают, каким верификаторам верить. То есть возникает рынок услуг по верификации, и кто какие цены хочет ставить — тот и ставит. А клиенты сами решат, у кого выгоднее брать подписи.
Проблемы нет. Он такое сделать может. И он делает! Я имею в виду тех провайдеров, которые вносят целые интервалы номерного пространства в e164.arpa. Понятно, что далеко не все это делают, но многие. И владельцу обычного номера от этого никакого ущерба нет, так как входящие у него — бесплатные, и звонящему тоже всё выходит бесплатно, просто звонок приземляется не непосредственно в PBX владельца номера, а в PBX оператора.
Конфликт интересов возникает, если пользователь покупает у провайдера toll-free номер, а тот втихомолку на себя захватывает ENUM-запись, а за приземлённые бесплатные звонки сшибает деньгу у пользователя. В таком случае, у пользователя есть несколько вариантов действий:
— терпеть такого нехорошего провайдера
— сменить провайдера на более вменяемого
— попробовать договориться с провайдером, чтоб он передал ENUM-запись клиенту
— связаться с верификатором, и попросить отозвать подпись (внести подпись в чёрный список).
Да, в системе ENUMER предусмотрен механизм отзыва подписей, в котором чёрный список публикуется на блокчейне верификатором. В статье про это не было сказано, так как она и так сильно нагруженная вышла.
Ну и последнее — пользователь может опубликовать информацию о недобросовестном поведении провайдера, чем отвадить от него клиентов. Так что в интересах провайдера быть кооперативным.
Мы это придумали, но сделали ещё далеко не всё. Например, этому проекту нужен автоматический верификатор. Если Вы желаете поучаствовать в его создании и становлении — напишите письмо на адрес из статьи, и мы с Вами свяжемся по этому поводу.
Emer — это пиринговая сеть. Вычислительные мощности не покупает кто-то централизованно, а их предоставляют сети пользователи этой самой сети, и за это получают соответствующий сервис.
FreeSWITCH позволяет создавать и использовать видеоконференции. Но ни ENUMER (о котором статья), ни классический ENUM к организации видеоконференций отношения не имеет. Он позволяет одному PBXу найти путь к другому, и не более. А уж какой мультимедийный трафик далее пойдёт по прямому соединению — это уже вне компетенции ENUMERa.
Ну раз Вы так упорно апеллируете к математике и статистике — счас будет.
Итак, поехали:
Сервер выбирается из списка размером в 241 элемент. Вероятность выбора p=1/241.
Распределение равномерное, и обеспечивается криптографически стойким PRNG из библиотеки OpenSSL. Выбор какого-либо конкретного сервера в акте получения IP описывается процессом Бернулли с биноминальным распределением. Соответственно, среднеквадратичное отклонение от матожидания (среднего) для n экспериментов (актов запроса IP-адреса) есть:
сигма=sqrt(n * p * (1 — p))
Нас интересует такой n, после которого количество попаданий на тот же сервер в силу случайности распределения не превысит указанного мною параметра A=0.5%.
В качестве доверительного интервала примем три сигмы.
Пишем неравенство:
n * p + 3 * sqrt(n * p * (1 — p)) < n * A
Смысл неравенства:
количество заходов на сервер плюс тройная сигма меньше заявленного мною параметра A для того же количества заходов n.
Решаем неравенство относительно n, получаем:
n > p * (1 — p) / ((A — p) / 3)^2
Подставив числа, получаем:
n > 51398
Вот так работает статистика. Если желаете опровергнуть — формулы в студию.
Так как STUN у нас уже работает с 2014го, масштабы давно уже соблюдены, и далее будут соблюдаться ещё больше. И кстати, в новой версии программы будет использован тот список STUN-серверов, который приаттачен к данной статье, а там их поболее будет. И для этого списка n > 23764.
Математики в статье вообще не было. Было написано о некоем случайном сервере: «Он получает менее 0.5% запросов». То есть — подразумевалась именно средняя величина, при достаточно большом числе запросов n (математически говоря, стремящемся к бесконечности). А она для текущего списка равно 1/241, и меньше 0.5%, как и заявлено в тексте статьи.
Это конечно не исключает, что в какие-то моменты времени некий сервер случайно наберёт и более 0.5% запросов. Но в среднем этот процент будет сходиться к 0.041.
1. Про обновления списка.
Мы это делаем примерно раз в полгода-год, при выпуске очередной версии программы. На самом деле, поддержка актуальности списка не критична, так как даже если 50% серверов «умрёт», то клиент в среднем после 2х попыток обхода получит искомый IP. Как видите, запас прочности системы колоссальный. В реальности же список актуальных серверов изменяется на ~10% в год, так что беспокоиться просто не о чем.
Ну а чтоб размер списка держать простым — это несложно. Всегда можно его уменьшить до ближайшего простого, выбросив несколько записей.
2. Про двойное удаление.
Этот код мы как есть импортировали из Биткоина. Если посмотрите, там стоит assert(false), который вызывает exception, то есть до второго удаление дело не доходит. Но за помощь в проекте — спасибо.
> Почему бы вам просто не поставить этот сервис у себя на сервере?
Их в мире и так больше 200, зачем ещё один ставить? Не проще воспользоваться готовым?
Кроме того, 200+ независимых серверов — они понадёжнее будут, чем один. Вероятность выхода из строя всех их одновременно пренебрежимо мала.
> Почему надо хардкодить список серверов, если можно скачивать его со своего сервера при каких-то условиях?
И в случае усперной хакерской атаки на наш сервер, или когда к нам придут дяди с паяльником — клиенты скачают незнамо что, и начнут получать такие ответы, которые либо разрушат топологию сети, либо втянут пиринговую сеть под чужой контроль.
На самом деле, у нас сеть — подчёркнуто децентрализована, и создавать в ней зависимость от какого-либо сервера у нас нет желания.
1. Чтобы цикл гарантировано обошёл все элементы массива, размер массива N и шаг цикла (step) должны быть взаимно простыми. В противном случае, цикл разваливается на несколько независимых колец. Типичный пример такого разваливания — чётный размер массива и чётный шаг. При таком раскладе, в системе возникает два не-пересекающихся цикла — по чётным и по нечётным элементам. Простейший способ избежать этого — сделать размер массива N простым числом, тогда любой шаг step < N будет по определению взаимно простым. Альтернатива этому — перебирать различные случайные step до тех пор, пока gcd(N, step) != 1. Мы применили простейший вариант, который нас устраивает — с простым N.
2. Ну если нам заранее известны все длины name, мы можем выбрать такую длину, в которую поместятся все имена серверов. В данном случае это 30. Использование char* — это создание указателя на строку, а саму строку держать где-то ещё. Указатель — лишние 8 байт (либо 4 на 32-битовой машине). Средний неиспользуемый хвост строки — меньше. То есть при переходе к архитектуре с указателями, слегка возрастает размер используемой памяти, и без всякой иной пользы для проекта. Соответственно, возникает вопрос уместности такого решения.
Формально говоря — да. А на практике — всякое бывает. Например MacOS содержит в себе gzip, который распространяется под GPL.
А Apple и не думает открывать все коды своей MacOS.
bopoh13 привёл хороший пример того, как делать не надо.
Про недостатки такого подхода как раз и написано в первом абзаце статьи.
В приведённом примере используется единственный внешний WEB-сервер checkip.dyndns.org, с не-стандартизованным ответом. Если хозяевам сервиса вдруг вздумается поменять формат ответа, или просто прекратить его деятельность — все пользователи Mikrotik разом получат массу впечатлений.
Хороший вопрос. Мы тоже рассматривали такую возможность, но всё-таки предпочли держать список в виде статического массива. Доводы в пользу этого подхода такие:
1. Усложнение установки. Сейчас в поставке имеется только единственный обязательный элемент — бинарная программа, и конфиг — опционален. А при использовании внешнего списка STUNов — надо ещё в правильное место конфиг копировать, и как-то поддерживать его актуальность. Получается «развесистая» структура.
2. Эксплуатанты программы-кошелька — в основном не-админы, и никто не будет заморачиваться постоянным мониторингом актуальности списка. Работает — и ладно. Поэтому на практике, список будет обновляться вместе с обновлением программы. То есть для пользователей вынесение списка во вне пользы не принесёт.
3. Применённый алгоритм обхода списка требует, чтобы количество элементов списка было простым числом. В случае внешнего списка админ вряд ли будет соблюдать это требование, что приведёт к сильному редуцированию количества возможных путей обхода, что снизит балансировку нагрузки и снизит надёжность подсистемы при выходе из строя части серверов.
Но естественно, в других проектах и условия могут быть другими, и там будут резоны держать список в виде внешнего конфига. Но так как исходный текст программы доступен, авторы другого проекта могут творчески переработать наш код, и сделать список загружаемым.
Майнеры будут зарабатывать, как и раньше. Никакого ущерба не понесут.
Связано это с тем, что в отличие от биткоина, где обьём денежной массы фиксирован, но комиссия не исчезает из оборота, и переходит к майнерам, в Эмере прямой связи между комиссией и доходов майнеров нет. Здесь майнятся «свежеотчеканенные монеты», а комиссия — уничтожается «сжигается». Здесь Вы можете узнать подробности про отличия Эмера от других крипт, а также более подробно прочесть об экономической модели Эмеркоин.
Да, жаль. Хотя онлайн-кошельком мы (разработчики) и не владеем, но с его админом и хозяином дружим, и нам было неприятно узнать о том, что какие-то акаунты в том онлайн-кошельке взломали. Кстати, взломали, насколько мы поняли, отдельные учётные записи, а не всю систему.
Честно говоря, именно тот взлом и стал побудительным мотивом к созданию этой вот программы.
Касаемо ж БД — не стоит беспокоиться, все ENUM-записи хранятся в хешевой базе данных Bdb, и скорость доступа туда весьма высокая — запрос отрабатывается единицы милисекунд. А как известно, скорость поиска в хеш-таблицах O(1), то есть не зависит от размера базы.
А децентрализацию обеспечивают как раз таки полные клиенты (кошельки), которых подавляющее большинство.
Естественно, использование любого сервера, в том числе и E1, подразумевает доверие к этому серверу. Верите серверу — пользуйтесь. Не верите — скачивайте себе полную ноду, и будет Вам счастье с истинной децентрализацией.
Статья же фокусируется на архитектурных решениях, заложенных в основу WEB-версии кошелька, призванных минимизировать ущерб пользователей от возможных успешных атак на сервер.
> то могу перевести на себя весь его телефонный трафик?
Да. Если есть доступ к соответствующему телефону.
Но в таком случае, сторож-вредитель много чего и другого сделать может — провода там в свитче переставить, комп вынести, двери хранилища открыть, и тп…
> Наверное, идентификация по ответу на телефон не настолько секъюрна,
> как верификация сайта через размещение контента.
Что делать… Идеальной системы нет. Могу только заметить, что e164.org, пока был жив, использовал этот же механизм, и всё работало нормально. Ну или если у Вас есть предложение, как улучшить систему верификации — мы рады будем ознакомиться.
> А что делать Центробанку, когда это обнаружится?
1. Уволить сторожа, влупив вдогонку штраф и уголовное дело о вредительстве и неавторизованном вмешательстве в работу инфосистемы.
2. Обратиться к верификатору с заявлением на отзыв подписи в комрометированной записи в ENUMER.
3. Создать свою запись с правильной подписью, и тем обрезать малину будущим сторожам.
> А какая экономика у верификатора?
Ответ на этот вопрос выходит за рамки статьи о технологии. Но в общем случае — какую экономику себе верификатор сделает, такая и будет.
> Он работает бесплатно?
На его усмотрение.
Система подразумервает нескольких верификаторов, и клиенты ENUMERа сами решают, каким верификаторам верить. То есть возникает рынок услуг по верификации, и кто какие цены хочет ставить — тот и ставит. А клиенты сами решат, у кого выгоднее брать подписи.
Конфликт интересов возникает, если пользователь покупает у провайдера toll-free номер, а тот втихомолку на себя захватывает ENUM-запись, а за приземлённые бесплатные звонки сшибает деньгу у пользователя. В таком случае, у пользователя есть несколько вариантов действий:
— терпеть такого нехорошего провайдера
— сменить провайдера на более вменяемого
— попробовать договориться с провайдером, чтоб он передал ENUM-запись клиенту
— связаться с верификатором, и попросить отозвать подпись (внести подпись в чёрный список).
Да, в системе ENUMER предусмотрен механизм отзыва подписей, в котором чёрный список публикуется на блокчейне верификатором. В статье про это не было сказано, так как она и так сильно нагруженная вышла.
Ну и последнее — пользователь может опубликовать информацию о недобросовестном поведении провайдера, чем отвадить от него клиентов. Так что в интересах провайдера быть кооперативным.
Итак, поехали:
Сервер выбирается из списка размером в 241 элемент. Вероятность выбора p=1/241.
Распределение равномерное, и обеспечивается криптографически стойким PRNG из библиотеки OpenSSL. Выбор какого-либо конкретного сервера в акте получения IP описывается процессом Бернулли с биноминальным распределением. Соответственно, среднеквадратичное отклонение от матожидания (среднего) для n экспериментов (актов запроса IP-адреса) есть:
сигма=sqrt(n * p * (1 — p))
Нас интересует такой n, после которого количество попаданий на тот же сервер в силу случайности распределения не превысит указанного мною параметра A=0.5%.
В качестве доверительного интервала примем три сигмы.
Пишем неравенство:
n * p + 3 * sqrt(n * p * (1 — p)) < n * A
Смысл неравенства:
количество заходов на сервер плюс тройная сигма меньше заявленного мною параметра A для того же количества заходов n.
Решаем неравенство относительно n, получаем:
n > p * (1 — p) / ((A — p) / 3)^2
Подставив числа, получаем:
n > 51398
Вот так работает статистика. Если желаете опровергнуть — формулы в студию.
Так как STUN у нас уже работает с 2014го, масштабы давно уже соблюдены, и далее будут соблюдаться ещё больше. И кстати, в новой версии программы будет использован тот список STUN-серверов, который приаттачен к данной статье, а там их поболее будет. И для этого списка n > 23764.
Это конечно не исключает, что в какие-то моменты времени некий сервер случайно наберёт и более 0.5% запросов. Но в среднем этот процент будет сходиться к 0.041.
Мы это делаем примерно раз в полгода-год, при выпуске очередной версии программы. На самом деле, поддержка актуальности списка не критична, так как даже если 50% серверов «умрёт», то клиент в среднем после 2х попыток обхода получит искомый IP. Как видите, запас прочности системы колоссальный. В реальности же список актуальных серверов изменяется на ~10% в год, так что беспокоиться просто не о чем.
Ну а чтоб размер списка держать простым — это несложно. Всегда можно его уменьшить до ближайшего простого, выбросив несколько записей.
2. Про двойное удаление.
Этот код мы как есть импортировали из Биткоина. Если посмотрите, там стоит assert(false), который вызывает exception, то есть до второго удаление дело не доходит. Но за помощь в проекте — спасибо.
Их в мире и так больше 200, зачем ещё один ставить? Не проще воспользоваться готовым?
Кроме того, 200+ независимых серверов — они понадёжнее будут, чем один. Вероятность выхода из строя всех их одновременно пренебрежимо мала.
> Почему надо хардкодить список серверов, если можно скачивать его со своего сервера при каких-то условиях?
И в случае усперной хакерской атаки на наш сервер, или когда к нам придут дяди с паяльником — клиенты скачают незнамо что, и начнут получать такие ответы, которые либо разрушат топологию сети, либо втянут пиринговую сеть под чужой контроль.
На самом деле, у нас сеть — подчёркнуто децентрализована, и создавать в ней зависимость от какого-либо сервера у нас нет желания.
2. Ну если нам заранее известны все длины name, мы можем выбрать такую длину, в которую поместятся все имена серверов. В данном случае это 30. Использование char* — это создание указателя на строку, а саму строку держать где-то ещё. Указатель — лишние 8 байт (либо 4 на 32-битовой машине). Средний неиспользуемый хвост строки — меньше. То есть при переходе к архитектуре с указателями, слегка возрастает размер используемой памяти, и без всякой иной пользы для проекта. Соответственно, возникает вопрос уместности такого решения.
А Apple и не думает открывать все коды своей MacOS.
Про недостатки такого подхода как раз и написано в первом абзаце статьи.
В приведённом примере используется единственный внешний WEB-сервер checkip.dyndns.org, с не-стандартизованным ответом. Если хозяевам сервиса вдруг вздумается поменять формат ответа, или просто прекратить его деятельность — все пользователи Mikrotik разом получат массу впечатлений.
1. Усложнение установки. Сейчас в поставке имеется только единственный обязательный элемент — бинарная программа, и конфиг — опционален. А при использовании внешнего списка STUNов — надо ещё в правильное место конфиг копировать, и как-то поддерживать его актуальность. Получается «развесистая» структура.
2. Эксплуатанты программы-кошелька — в основном не-админы, и никто не будет заморачиваться постоянным мониторингом актуальности списка. Работает — и ладно. Поэтому на практике, список будет обновляться вместе с обновлением программы. То есть для пользователей вынесение списка во вне пользы не принесёт.
3. Применённый алгоритм обхода списка требует, чтобы количество элементов списка было простым числом. В случае внешнего списка админ вряд ли будет соблюдать это требование, что приведёт к сильному редуцированию количества возможных путей обхода, что снизит балансировку нагрузки и снизит надёжность подсистемы при выходе из строя части серверов.
Но естественно, в других проектах и условия могут быть другими, и там будут резоны держать список в виде внешнего конфига. Но так как исходный текст программы доступен, авторы другого проекта могут творчески переработать наш код, и сделать список загружаемым.
Связано это с тем, что в отличие от биткоина, где обьём денежной массы фиксирован, но комиссия не исчезает из оборота, и переходит к майнерам, в Эмере прямой связи между комиссией и доходов майнеров нет. Здесь майнятся «свежеотчеканенные монеты», а комиссия — уничтожается «сжигается».
Здесь Вы можете узнать подробности про отличия Эмера от других крипт, а также более подробно прочесть об экономической модели Эмеркоин.
Честно говоря, именно тот взлом и стал побудительным мотивом к созданию этой вот программы.