что такое проприетарные протоколы
Новое слово: проприетарный
Что означает слово «проприетарный»? Нет ли у него в русском языке адекватного синонима?
Чаще всего это прилагательное вкупе с существительным «проприетарность» используется в околокомпьютерной тематике, по отношению к программным или аппаратным продуктам. Буквально английское proprietary значит «собственнический; частный», от латинского proprius — «владение, собственность». Проприетарность часто противопоставляется открытости, и с одной стороны эти понятия действительно антагонистичны, однако тут нужно сделать важное замечание. Например, широко распространено мнение, будто все программы с открытым кодом, распространяемые бесплатно — не проприетарны. Это большое заблуждение. Существует множество продуктов, права на которые принадлежат вполне определённым лицам, но при этом они вовсе не обязательно платные и с закрытым исходным кодом (хотя большинство из них, не будем лукавить, именно такие).
Проприетарность чего-либо говорит прежде всего о том, что его разработка и производство целиком принадлежат и контролируются неким собственником. И как он распоряжается готовой продукцией — продаёт её или дарит — полностью зависит от его воли. Именно эта зависимость от непредсказуемых решений владельца смущает многих потребителей при равном выборе между проприетарными продуктами и открытыми, заставляя делать выбор в пользу последних.
Вопросы построения сети. Проприетарное рабство, отказоустойчивость и модульность (часть 1)
Введение
Сегодня расскажем как построить максимально отказоустойчивую сетевую инфраструктуру предприятия, с минимальной привязкой к конкретному вендору, преимущественно на открытых протоколах и стандартах.
Условно говоря, сетевую инфраструктуру можно разделить на ряд компонентов:
ЛВС (локальная вычислительная сеть) — IT-инфраструктура на основе группы стандартов IEEE 802.3.
БЛВС (беспроводная локальная вычислительная сеть) — IT-инфраструктура на основе группы стандартов IEEE 802.11, так или иначе интегрированная с ЛВС.
Вспомогательные системы (система управления IP пространством, инвентарная система, система описания сетевых сервисов, системы мониторинга).
Сегодня начнем с ЛВС.
Долой проприетарное рабство!
Каждый производитель активного сетевого оборудования предлагает свои проприетарные решения для упрощения настройки администрирования сети, для построения высоко надежных и отказоустойчивых систем. И эти решения могут быть вполне себе эффективными и полезными. Но у проприетарных решений есть недостатки:
Появляется зависимость от конкретного производителя, в случае необходимости замены оборудования или масштабирования сети не так просто перейти на другого производителя;
Повышаются и сужаются требования к персоналу (инженер должен знать конкретные решения конкретного производителя);
Усложняется процесс поиска и устранения неисправностей и усиливается необходимость контракта на техническую поддержку производителя.
Поэтому мы строим вендор-независимую отказоустойчивую сеть, для этого необходимо минимизировать использование проприетарных протоколов — отдаем предпочтение открытым стандартам. Плюсы отказа от объединения физических коммутаторов в кластер или стек:
Минимизация масштабов простоя сервиса в случае сбоя в ПО на одном из физических коммутаторов — это не приведет к сбою всего виртуального коммутатора или стека, и, как следствие, простою сервиса;
Унификация настроек коммутаторов (первый порт это всегда Gi1/0/1, а не Gi3/0/1);
Минимизация использования проприетарных технологий и минимизации зависимости от вендора;
Минимизация масштабов простоя сервиса в случае обновления ПО и перезагрузки. Несомненно, производители предлагают механизмы обновления ПО без простоя, но это на данный момент не все производители умеют, и не все инженеры будут изучать мануал, а если и будут, то все равно попросят maintenance window у бизнеса для перестраховки;
Минимизация простоя сервиса в случае ошибки по причине человеческого фактора. Например, если администратор случайно перезагрузит коммутатор доступа, то перезагрузится только 1 устройство, а не стек из Х коммутаторов. А если инженер случайно перезагрузит коммутатор распределения или ядра, то простой сервисов ограничится только временем сходимости сети;
Простота замены оборудования: достаточно скопировать бэкапный конфиг и подключить устройство в сеть, без сложных и рискованных процедур по объединению оборудования в стек или кластер; никогда не знаешь наверняка, все ли пройдет без сбоев и перезагрузок.
Минусы отказа от объединения физических коммутаторов в кластер или стек:
Потребуется увеличение количества физических линков (удорожание СКС). Отказоустойчивость или дешевизна, нужно выбрать одно;
Усложнится (сделается не loop free) L2 домен (этим пугают производители, предлагая проприетарные решения). Решается грамотной настройкой выбранного протокола группы STP;
Усложнится процесс администрирования, так как будет больше логических устройств. Решается применением автоматизации, которая не предусматривает подключение к оборудованию инженерами “руками” для решения рутинных задач;
Замедлится сходимость сети — это явный минус. Если стоит задача максимально ускорить сходимость сети и если сходимость сети в 1 минуту уже очень долго для бизнеса, лучше присмотреться к проприетарным решениям, так как любой протокол группы STP в этом случае будет проигрывать.
Отказоустойчивость (больше линков, больше железа, меньше технологий)
Active-passive vs active-active
Выбор схемы active-active не является оптимальным из-за того, что данные мониторинга загрузки оборудования в режиме active-active не будут достаточно информативными, чтобы гарантировать работу сети в случае выхода из строя одного из компонентов.
Пример построения сети на L2:
Три кита отказоустойчивости:
Резервирование линков. Каждый логический канал между активным сетевым оборудованием должен состоять как минимум из двух физических каналов;
Резервирование оборудования. Каждый логический модуль уровня ядра и распределения должен состоять из двух физических устройств;
Грамотная настройка оборудования.
Резервирование линков и оборудования
Потребуются две серверные для построения территориально-распределенных компонентов ЛВС, чтобы минимизировать влияние аварии в одной из серверных на работу всей сети. Под авариями подразумеваются такие события, как продолжительное отключение электропитания, физическое повреждение каналов связи, пожар, поломки оборудования и пр;
Потребуется два провайдера Интернета (или других сервисов) до каждой серверной (оптика). Оптические трассы могут быть перекопаны техникой, поэтому важно еще иметь дополнительный линк провайдера по радио.
Три источника проблем
Неправильная настройка оборудования. Все может отлично работать, и даже продолжительное время, но какой-то внешний фактор может нарушить работу сети;
Человеческий фактор. Настройка и администрирование оборудования человеком рано или поздно приведет к ошибкам. Человек не может выдавать одинаковый результат втечение продолжительного времени. Например, если администратор вот уже Х лет не делал ни одной ошибки, не факт что завтра он не спутает консоль коммутатора доступа с консолью коммутатора ядра;
Модульность (занудно, но важно)
Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связанных между собой модулей (Wi-Ki).
В зависимости от требований бизнеса, сетевую инфраструктуру удобно разделить на несколько логических компонентов (модулей), например:
Модуль ядра сети (коммутаторы ядра сети) предназначен для быстрой коммутации и маршрутизации, объединения других модулей в единую систему. Чаще всего это будут два коммутатора, которые производители позиционируют как “Core Switch”. Лучше территориально разнести по разным серверным;
Модуль кампусной сети (коммутаторы уровней распределения и доступа). Каждый логический коммутатор уровня распределения должен состоять из двух физических коммутаторов, лучше территориально разнести по разным серверным. Коммутаторы уровня доступа должны состоять из одного физического коммутатора. В случае надобности подключения оконечных сетевых устройств, требующих питание по active PoE, необходимо предусмотреть коммутаторы доступа с поддержкой active PoE. При этом должен быть отражен расчет бюджета PoE;
Модуль подключения серверного оборудования. Как правило, модуль представляет собой набор из межсетевых экранов, высокопроизводительных коммутаторов и модулей расширения фабрики с поддержкой IEEE 802.1BR, предназначенных для центров обработки данных. Тут все сильно зависит от масштабов бизнеса;
Модуль подключения к сети Интернет. Представляет собой набор коммутаторов, межсетевых экранов, с поддержкой подключения к удаленным объектам (IPSec VPN) и подключения удаленных рабочих мест (SSL/IPsec VPN) в случае надобности;
Модуль вспомогательных систем управления может включать в себя следующие компоненты: система управления IP-пространством IPAM (IP Address Management), инвентарная система, система описания сетевых сервисов или управления конфигурацией, системы мониторинга, система контроля доступа NAC (Network Admission Control), NTP, FTP, TFTP и пр.
Любой выбор — это всегда баланс между плюсами и минусами того или иного решения. Предлагаемый вариант подхода к построению сети призван удовлетворить трем главным для нас критериям: отказоустойчивость, простота, независимость от модели и производителя.
Передача данных в портативных мультимедиа-плеерах: проприетарные протоколы
Основным отличием портативных аудиоплееров «поколения Интернет» от своих предшественников является их тесная интеграция с персональным компьютером.
В прошлом портативные плееры воспроизводили музыку с распространенных сменных носителей и не нуждались в подключении к чему бы то ни было, кроме наушников
До недавнего времени ПК был для них единственным источником контента. При этом возникала необходимость в механизме сопряжения портативного плеера и компьютера. Задача заключалась в передаче данных в цифровой форме с одного носителя (в ПК) на другой (в плеере) в формате, принятом в компьютерной отрасли.
Контент необходимо перенести с компьютера, в котором он обычно хранится на жестком диске форм-фактора 3.5”, на носители портативных плееров: флэш-память, жесткие диски форм-фактора 1” и 1.8”
Следовательно, нужно задействовать какой-либо компьютерный интерфейс передачи данных.
В любом подобном интерфейсе можно выделить два уровня. Первый – физический, т.е. непосредственно провода, разъемы, микросхемы и т.п. Второй – программный, это, условно говоря, набор инструкций и алгоритмов, согласно которым осуществляется обмен данными на физическом уровне. Этот программный уровень часто называют протоколом. Сегодня мы будем в основном говорить именно о нем. Для пользователя он является «лицом» интерфейса, его возможности и недостатки определяют удобство или сложности в эксплуатации устройства в целом.
Для полноценной эксплуатации протокола необходимо наличие двух программных компонентов. Во-первых, это драйвер, занимающийся непосредственно сопряжением портативного устройства и ПК на программном уровне. Во-вторых, это программное обеспечение, позволяющее пользователю управлять протоколом и использовать его для своих нужд. ПО, строго говоря, не является непосредственной частью протокола. Но без его наличия само существование протокола теряет смысл. Поэтому в рамках данной статьи мы будем рассматривать ПО как неотъемлемую часть рассматриваемых протоколов.
Любой программный протокол использует драйверы и ПО, хотя реализация этих компонентов в каждом конкретном случае может сильно отличаться. Удачность протокола можно условно вычислить по формуле: возможности минус неудобства. Под возможностями понимается спектр доступных функций. Неудобства обычно включают в себя непрозрачность при использовании, неудобство в установке, сложность в освоении, ограниченную совместимость.
По меркам цифровой портативной техники MP3-плееры – уже достаточно немолодой класс устройств. Они появились в то время, когда инфраструктура ПК была совершенно не готова к роли компьютера как мультимедиа-хоста. И на физическом, и на программном уровне в этой области еще не существовало распространенных и стандартизированных решений, они лишь находились в разработке, готовились к выходу на рынок или существовали в штучных количествах. В схожем положении оказались другие родственные классы портативных устройств: мобильные накопители, цифровые камеры, сотовые телефоны, КПК. Все эти разновидности мобильной техники появились примерно в одно и то же время, во второй половине 90-х годов. Своим появлением они вызвали необходимость разработки единых стандартных протоколов сопряжения ПК с портативной техникой.
На физическом уровне все было относительно ясно. Первые портативные устройства были вынуждены использовать COM и LPT – других широкодоступных интерфейсов в то время просто не было.
LPT-разъем до сих пор можно найти на большинстве ПК
Так, именно физический интерфейс LPT использовался родоначальниками MP3-плееров, Saehan MpMan и Diamond Rio. Этот период можно назвать «кустарным», разработчикам приходилось использовать интерфейсы и протоколы, изначально созданные для совершенно иных задач.
Однако мучаться в оковах медленных и неудобных интерфейсов новому поколению портативного аудио пришлось недолго: уже в следующем 1999 году производители представили широкий спектр устройств, использующих новый стандарт: USB, Universal Serial Bus.
Какое-то время наблюдалась видимость борьбы между USB и распространенным главным образом на компьютерах Apple Macintosh протоколом Firewire.
Война Firewire-USB в портативных плеерах: от iPod 1G – только Firewire – до iPod 5G – только USB
Однако основная масса портативного аудио быстро и безболезненно пересела на Universal Serial Bus, закрыв, по крайней мере в рамках проводных решений, вопрос с передачей данных на физическом уровне.
Далеко не так просто сложилось все для программных протоколов. В тот короткий период, когда производители вынужденно использовали COM и LPT, программные протоколы были исключительно их собственной разработки. Никакими другими они быть, собственно, и не могли, т.к. и COM-, и LPT-интерфейсы создавались в свое время, естественно, совсем не для передачи мультимедийных файлов на портативные цифровые проигрыватели. Разрабатывать драйверы и программные оболочки для последних кроме самих разработчиков было некому, а о стандартизации речи и вовсе не шло.
Но и появление USB не решило проблему. Индустрия в первую очередь озаботилась созданием стандартных протоколов для мобильных накопителей, цифровых камер. Ситуация с MP3-плеерами была вообще не ясна: запретят их или нет, а если все же не запретят, то какими особенностями должны обладать протоколы, чтобы форум SDMI дал добро. В подобных условиях разработка программных протоколов по-прежнему лежала на плечах разработчика устройства. Так продолжалось не менее четырех лет, пока, наконец, в плеерах не начали появляться стандартные протоколы передачи данных. Эти годы были временем господства первой разновидности программных протоколов – проприетарных или закрытых.
Характерной их чертой являлись индивидуальные драйверы и программное обеспечение для каждого производителя, а зачастую и для каждого нового поколения плееров в рамках продукции одного и того же производителя.
Проприетарный протокол на примере RCA-Thomson Lyra. Используется собственный драйвер (PDP2222.SYS), который необходимо устанавливать отдельно на каждый ПК, к которому планируется подключать плеер
Это создает множество неудобств для пользователя. Ни о какой прозрачности речи нет – пользователь сам вынужден вручную устанавливать драйверы и ПО для своего плеера. При этом могут возникать различные сложности, к примеру, если покупатель по ошибке подключит плеер к ПК раньше установки драйверов.
Перепутав порядок действий при подключении плеера, пользователь рисковал любоваться подобным сообщением, даже установив впоследствии все необходимые драйверы
О совместимости тоже лучше забыть: драйверы и ПО работали лишь с данной моделью плеера (в лучшем случае – с несколькими моделями от данного производителя), а плеер мог работать только с ПК, на котором установлены данные драйверы и ПО. Возможности программных оболочек поначалу были совсем скудны и ограничивались исключительно копированием аудиофайлов в память плеера. Позже появилось разнообразие в способах копирования контента на плеер: индивидуально по трекам или синхронизацией содержимого памяти плеера с содержимым скомпонованной из аудиофайлов, находящейся на ПК библиотеки. Отдельные программные оболочки поддерживали лишь один из этих способов. Со временем ПО обретало дополнительные возможности, к примеру, копирование любых файлов, а не только поддерживаемых плеером, что давало возможность использования его как накопителя (функция получила прозвище Data Taxi). Однако тот факт, что для данной операции была обязательна установка на ПК драйверов и ПО, серьезно снижал полезность этой функции. О высоких эстетических качествах, безукоризненной работе и хорошей эргономике оболочек речь, как правило, и вовсе не шла. Пользователи тогда были в массе своей людьми суровыми и неизбалованными: копируются файлы на плеер – и ладно.
Через проприетарные системы прошло большинство производителей: iriver, Rio Audio, Creative, Cowon, Mpio и т.д. У каждого из этих производителей в свое время были и свои драйверы, и свое программное обеспечение, у кого-то более, у кого-то менее удачное. В любом случае, сменив плеер на устройство другого производителя, пользователь был вынужден приспосабливаться к новой оболочке с ее логикой и особенностями. Многие производители продолжают и сегодня комплектовать свои устройства этими программами как альтернативой стандартам MSC/UMS или MTP-решениям.
Проприетарные оболочки-менеджеры: Iriver Music Manager, Cowon JetAudio, Mpio Manager, Creative Play Center
Зоопарк всевозможных оболочек не мог устраивать потребителей (с существованием кучи разношерстных драйверов они еще могли смириться). Не устраивал он и производителей, особенно небольших, не имевших ресурсов на разработку качественного программного обеспечения. Поэтому в 1999 – начале 2000-х годов определенную популярность обрело использование оболочек сторонних производителей.
Среди них можно выделить программу MusicMatch Jukebox.
Интерфейс MusicMatch Jukebox
До появления iTunes для Windows PC именно она использовалась здесь для работы с Apple iPod. Работала она и с плеерами других производителей, таких, как RCA-Thomson.
Программы типа MusicMatch Jukebox были первыми ростками стандартизации. Они позволяли использовать плееры разных производителей без установки дополнительного ПО для каждого из них. Решение не было безупречным, это был лишь шаг от разномастных протоколов и оболочек к стандартизированным решениям. В данном случае же был стандартизирован только интерфейс управления протоколом, установка отдельных драйверов для каждого устройства по-прежнему оказывалась необходимой. Сами оболочки не входили в состав операционной системы, их было необходимо устанавливать отдельно, из Интернета или с сопутствующего CD. Их функциональность, стабильность работы и удобство зачастую также вызывали вопросы. Поддерживались далеко не все плееры, что вынуждало производителей комплектовать свои устройства плагинами для популярных программ-менеджеров.
Доступно для скачивания на сайте RCA-Lyra: в первую очередь плагин для MusicMatch Jukebox и только потом собственная оболочка Lyra DJ
Обычно со временем программа «толстела», обрастала ненужными пользователю функциями, рекламой, требовала все больше ресурсов.
Еще одна популярная в прошлом оболочка – RealJukebox
Одновременно росло давление конкурентов: в 2001 году Windows Media Player вошел в стандартную поставку Windows XP, в 2003 году появился iTunes для Windows. Небольшие азиатские компании в 2002-2003 году также нашли хорошую замену этому ПО – открытый протокол MSC/UMS. В результате оболочки типа MusicMatch Jukebox сошли со сцены, чтобы уступить место протоколам нового поколения. Но их наследие не пропало даром: модель «одна оболочка для разных плееров» во многом унаследована системой Microsoft PlaysForSure.
Одна черта проприетарных систем, однако, позволила им прожить на отдельных рынках дольше разумного. Их закрытость создавала препятствия при использовании плеера для свободного переноса данных с ПК на ПК, то есть, по версии RIAA, при использовании его как орудия цифрового пиратства. На проблемных рынках, наподобие американского, компании, не желающие привлекать к себе лишнего внимания, продолжали придерживаться проприетарного подхода даже после распространения универсальных решений.
На сайте iriver непроприетарные прошивки до сих пор отмечаются особо, как UMS или MTP
Тут можно вспомнить, к примеру, iriver или Creative. Плееры iriver вообще выпускались в двух вариантах: для рынка США – работающие через проприетарный протокол, для других – через открытый MSC/UMS. Такая «жизнь после смерти» для закрытых протоколов продолжилась вплоть до выхода в 2004 протокола MTP, который, будучи относительно универсален, устроил и звукозаписывающие компании.
Период 2002-2004 гг. был переходным от «темных веков» закрытых систем к относительной открытости современных протоколов. Сегодня чистые проприетарные протоколы полностью вышли из употребления.
Свой криптографический протокол — опасная идея
Разработка своей криптографии в чём-то сравнима с созданием собственного авиадвигателя, говорит эксперт по безопасности Руна Сандвик. Фото: Виталий Кузьмин
Предположим, заказчик требует разработать собственный сетевой протокол. Например, для передачи данных между сервером и мобильным приложением, для связи между микросервисами, модулями программной системы, поверх UDP или поверх TCP. С шифрованием.
Казалось бы, почему не использовать открытые стандарты типа WebSocket и JSON, зачем собственный закрытый протокол? На это обычно приводят ряд причин. Во-первых, для безопасности, чтобы его было сложнее отреверсить и никто не понял, какие данные вы передаёте. Во-вторых, для эффективности. У нас ведь уникальный случай использования, поэтому стандартные решения — не самые оптимальные. Наш собственный протокол будет работать с меньшими задержками, потреблять меньше трафика и меньше расходовать батарею (на мобильных устройствах). И третья причина — функции. В своём протоколе специально для нашего приложения мы реализуем уникальные возможности, каких нет ни в открытом стандарте, ни у конкурентов.
Это распространённые причины, из-за которых разрабатывают проприетарные протоколы.
Безопасность
Поговорим о безопасности.
Любой безопасник скажет, что протокол должен быть закрытым. Это важно для защиты от конкурентов. И от клиентов тоже. Чем меньше клиент знает о протоколе — тем меньше он контролирует систему, приложение. Вся власть остаётся в руках разработчика. Система полностью под контролем производителя, то есть вас. Соответственно, клиент навечно привязан к вам по обслуживанию, он не сможет ничего поломать в аппаратуре или софте. Он вообще побоится туда сунуться, потому что там ничего не понятно. Всё обфусцировано, зашифровано и написано на непонятном языке. Классика.
На Хабре частенько упоминают реверс-инжиниринг протоколов в различных устройствах: автомобили, тракторы, даже машины для производства мороженого. Производители этой техники стараются скрыть технические данные ради безопасности. Чтобы глупые пользователи не совали шаловливые ручки внутрь.
Например, важной частью бизнеса многих компаний является сервис и техническое обслуживание. Поэтому некая компания, скажем, системный интегратор предпочтёт вместо стандартных Open Source решений внедрить клиенту проприетарный софт с собственным закрытым протоколом. И всё. После этого она будет «доить» клиента десятилетиями.
Доходит до того, что некоторые интеграторы вообще пишут уникальный софт для конкретного клиента — и отправляют собственного сотрудника в штат компании-клиента. Потому что он единственный, кто умеет работать с этой программой.
В общем, проприетарный протокол кажется очень выгодным для фирмы.
Но жизнь иногда показывает обратное. А именно:
Принцип «безопасность через неясность» не работает в криптографии
Принцип «безопасность через неясность» (security through obscurity) заключается в том, чтобы скрыть внутреннее устройство системы или реализацию для обеспечения безопасности.
Но в любой системе есть недостатки. В данном случае разработчик системы хочет спрятать эти недостатки, чтобы злоумышленник ими не воспользовался.
Сравните с опенсорсными системами, где разработчик специально открывает код, чтобы независимые сторонние эксперты помогли выявить и исправить эти недостатки.
В итоге получается, что собственный проприетарный протокол, максимально закрытый от посторонних глаз и обфусцированный, вовсе не увеличивает безопасность системы, а уменьшает её!
В криптографии одно из базовых правил — использовать только открытые, публичные алгоритмы и протоколы. В такой системе есть лишь один секрет — приватный ключ. Больше ничего. Это принцип Керкгоффса, который широко применяется в криптографии и считается практически неоспоримым.
Голландский криптограф Огюст Керкгоффс изложил правила проектирования военных шифров в книге «Военная криптография» (1883). Основная идея была в том, что попадание системы в руки врага не должно причинять неудобств. Поэтому ничего, кроме ключа, не должно быть секретным.
Собственная криптография
Вопрос «Почему не разработать собственную криптографию?» чем-то похож на вопрос «Почему не спроектировать авиадвигатель?», говорит Руна Сандвик, исследователь по безопасности. Конечно, теоретически мы можем это сделать. Но это чрезвычайно сложно. Гораздо более простой и надёжный вариант — выбрать готовое решение, проверенные и надёжные протоколы и алгоритмы.
Поэтому в сообществе информационной безопасности вызывает большое подозрение, если какая-то компания реализует собственный проприетарный протокол. Например, проприетарный протокол MTProto в Telegram поначалу вызвал массу критических отзывов. Взлом MTProto 1.0 стал одной из самых популярных статей на Хабре в 2013 году: «Безопасен ли Telegram? Или как я искал закладку в MTProto» (спойлер: глупые ошибки в проприетарной криптографии).
Хотя баг быстро исправили, это наглядный пример, почему не нужно разрабатывать собственные авиадвигатели криптографические алгоритмы. Вы можете допустить ошибку — а риски огромные. Люди полагаются на безопасное шифрование, от этого зависит их свобода, а иногда жизнь.
К тому же, в мессенджере запрещена анонимная регистрация без номера телефона — вероятно, так удобнее коммерческой компании, чтобы блокировать спам и продвигать приложение по адресным книгам. Кто будет думать об анонимности, когда на кону миллиарды долларов прибыли? При этом Telegram изначально позиционировали именно как «безопасный» мессенджер (многие пользователи купились на такую рекламу).
В реальности для обеспечения анонимности нужно регистрироваться по анонимной сим-карте, но не все это понимают. См. также советы «Как защитить свой аккаунт в Telegram» и «Практическое руководство по анонимности в онлайне».
Привязка к телефонному номеру делает пользователя уязвимым, потому что операторы сотовой связи внутри страны — удобный объект для работы спецслужб.
Конечно, в опенсорсе есть свои специфические риски. Например, проблемы с сотнями зависимостей, которые вы не контролируете. Например, 20% багов в проектах на GitHub явно внесены в проекты специально, со злым умыслом. То есть вредоносными контрибуторами, которые действовали умышленно. Ещё не забыта история c мейнтейнером ESLint, который 12 июля 2018 года опубликовал вредоносные версии пакетов eslint-scope и eslint-config-eslint в репозитории npm.
Такое может случиться с каждым опенсорсным проектом, потому что мейнтейнеры работают бесплатно, на износ:
Но все проблемы безопасности решаемы. Независимый аудит открытого кода профессиональными экспертами — лучшая гарантия его надёжности.
Кстати, в 2013 году проприетарный софт впервые обогнал опенсорсные проекты по среднему количеству багов на 1000 строк кода.
Источник: Coverity Scan Open Source Report
В прошлом веке считалось, что проприетарный софт пишут профессионалы, а Open Source — любители. Сегодня же профессиональный уровень опенсорсных программ вовсе не уступает проприетарным. Может, даже превосходит их.
Возвращаясь к примеру Telegram. 5 декабря 2020 года двое итальянских математиков Марино Микулан и Никола Витоколонна опубликовали на сайте препринтов arXiv.org исследование «Автоматическая символическая проверка протокола MTProto 2.0 в Telegram» (вторая версия опубликована 30 апреля 2021 года, arXiv:2012.03141v1). Оно подтверждает безопасность обновлённой версии фирменного протокола MTProto 2.0.
Набор протоколов MTProto 2.0 (в голубой рамке) и область покрытия данной научной работы (светло-зелёным цветом). Схема из научной статьи Марино Микулана и Никола Витоколонны, arXiv:2012.03141v1
Статья содержит «полностью автоматизированное доказательство надёжности аутентификации MTProto 2.0, обычного чата, зашифрованного end-to-end чата и механизмов повторного ввода ключей в отношении нескольких свойств безопасности, включая аутентификацию, целостность, конфиденциальность и совершенную прямую секретность», а также «доказывает формальную корректность MTProto 2.0».
Протокол аутентификации MTProto 2.0. Здесь 
означает асимметричное шифрование 
открытым ключом 
. В свою очередь, 
означает симметричное шифрование общим ключом 
с вектором инициализации 
. Схема из научной статьи
Слегка упрощённая версия протокола MTProto 2.0 для секретных чатов. Все сообщения перенаправляются через сервер 
: каждое сообщение между 
и шифруется с использованием ключа авторизации 
(здесь не показан). Обратите внимание, что 
, и не известны серверу . Схема из научной статьи
Эта математическая работа чуть ослабила озабоченность экспертов по поводу проприетарного протокола MTProto 2.0. Редкий случай, когда собственная нестандартная криптографическая система (пока) работает надёжно. В ней ещё не нашли таких фатальных уязвимостей, как в MTProto 1.0.
Неужели разработчики Telegram всё-таки научились — и смогли сделать уникальный «авиадвигатель» без ошибок? Можно только порадоваться за них, ведь все пользователи Telegram участвовали в этом «обучении» как бета-тестеры. В каком-то смысле это наш общий успех.
На правах рекламы
Наша компания предлагает серверы с Linux или Windows. Не экономим на железе — только современное оборудование и одни из лучших дата-центров в России и ЕС. Поспешите проверить!