dxdt.blog: занимательный интернет-журнал

Если все голосующие жители оснащены компьютерами, то можно устроить полностью распределённую систему, в которой нет центрального “контролирующего сервера”, а все участники могут проверить легитимность того или иного решения. При этом можно сохранить анонимность, если потребуется. Естественно, как и в случае всякой добротной криптосистемы, всё можно реализовать в открытых исходных кодах, на базе открытых алгоритмов. Примерно так работает Bitcoin (со своими особенностями, конечно).

Понятно, что как только такая сеть создана, на её базе уже нетрудно поднять систему всеобщего прямого голосования. Впрочем, результаты такого нововведения довольно подробно описаны в фантастических рассказах.

Кстати, наверное, при повсеместном распространении и “исторической привычке” не возникнет особенных вопросов о том, как схема работает. Тем более, что всё открыто.

Обычно, перевод древних аналоговых технологий связи на цифровые рельсы выливается в сплошные преимущества: цифровая система может быть и гибче, и надёжнее, и безопаснее. Всё это верно и для радиосвязи. Но только в том случае, если реализация добротная. Очередное подтверждение, очень занятное: исследователи изучили цифровые системы радиосвязи стандарта P25, – используемые, например, спецслужбами США, – и обнаружили эффективные направления для активных атак.

Помимо многих прочих интересностей, описанных в работе, авторы выяснили, что цифровой защищённый канал передачи речи оказалось гораздо проще полностью подавить, чем соответствующий аналоговый (при этом помеха в эфире практически незаметна).

Как пишут, реализация протоколов связи выполнена так плохо, что для блокирования приёма достаточно подавить всего несколько бит в передаваемом пакете (кадре). Это вполне конкретные биты, и, казалось бы, для точного срабатывания помехопостановщика нужна хорошая синхронизация. Но в реальности, из-за предсказуемого формата заголовка пакета, помехопостановщик может активироваться после обнаружения ключевой последовательности в эфире – и тут же передавать экстремально короткую помеху, забивая ключевые биты заголовка пакета данных.

Без этих битов приёмники не могут правильно раскодировать кадр (так устроен протокол передачи) и отбрасывают его целиком, вместе со всеми данными. В результате, средняя мощность эффективного помехопостановщика выходит примерно на порядок меньше мощности передатчика, и при этом канал связи подавлен полностью. Для того, чтобы полностью подавить выполняющую ту же функцию голосовой связи аналоговую радиостанцию, потребовался бы передатчик гораздо более мощный и “непрерывного” действия. (Почему? Потому что, грубо говоря, нужно было бы передавать помеху всё время, пока работает подавляемая станция, и при этом излучать более “сильный” сигнал.)

В качестве аппаратуры для практической постановки помех исследователи применяют детскую радиоигрушку (да, именно так, не шутка), по цене $30 за комплект из двух устройств.

Атакуемая система поддерживает шифрование и вообще проектировалась для специальных применений. Ситуация хоть и касается портативных радиостанций, но отлично иллюстрирует возможные проблемы в других областях. Кстати, во внутренней связи комплексов ПВО. Протоколы там сходные. А эффект – более мощный, понятно. По крайней мере, неверно будет считать, что комплексы заведомо защищены “используемыми алгоритмами” от изощрённого вторжения внешней силы в системы управления и контроля.

(Ссылка на научную работу найдена тут: schneier.com.)

О рисках, связанных с внедрением гипотетическим интернет-гигантом, браузера-шпиона: при верном планировании и качественной реализации плана, особых репутационных рисков нет, их преувеличивают. Такова реальность Интернета.

Посудите сами. Возьмём схему из предыдущей записки. Грамотное воплощение её в программном коде будет содержать всего два-три критичных момента: подмешивание текста страниц (с перекодированием) в значения передаваемых на сторонний сервер “технических параметров”; псевдослучайную выборку фрагментов страниц (по плану); приём ответов и стартовых команд от центрального сервера, опять же, с элементом случайности (необязательный пункт). Всё это реально представить в виде ошибок разработчиков, а весь механизм, в случае чего, признать уязвимостью. Официальная реакция могла бы быть такой: “…обнаружена уязвимость, связанная с использованием буферов данных, которая в некоторых случаях могла приводить к утечке информации о содержании страниц, просматриваемых пользователем”. Ну и т.д., и т.п. Уязвимость исправлена. Особого вреда репутации производителя браузера – нет. Находили уязвимости и похуже.

Но, опять же, из этого не следует вывод, что Chrome собирает контент “секретных” страниц. Потому что не обязательно же реализовывать каждую придумку, которая не несёт с собой особых рисков, и тратить таким образом ресурсы. (И это наблюдение не про то, что нужно “обязательно делать собственный браузер”.)

В продолжение темы про Chrome, который, якобы, переправляет в Google контент закрытых страниц из корпоративных интранетов: интересно подумать, как можно было бы устроить подобный шпионский браузер. Понятно, что едва ли Google что-то подобное делает, потому что не ясны стратегические выгоды: ну чего там интересного для массового пользователя можно найти в интранетах? Тем более, что и ссылку-то не покажешь: сервер же закрыт. В исходном вбросе, направленном на тематические СМИ, по той или иной причине не разработан технический аспект: то есть нет легенды, как именно Chrome “сливает инфу”. А ведь это был бы самый занимательный кусочек истории.

Что можно придумать? Понятно, что простое зеркалирование забранных с “секретного” сайта страниц на сервер Google – это неинтересный вариант. Хотя бы потому, что он обнаруживается совсем уж элементарно, с помощью систем мониторинга трафика. Использование зашифрованных каналов тут не поможет, потому что само наличие канала с трафиком демаскирует “шпиона”. Однако, можно “размазать” собранную информацию по многим транзакциям, передавая внутри каждой лишь небольшой фрагмент. Получается такой медленный и малозаметный канал.

Посудите сами: обычный корпоративный пользователь ходит не только по интранету и закрытым внутренним серверам, основную часть его трафика составляют результаты просмотра внешних ресурсов. Это означает, что доля трафика, формирующего утечку, невелика, и эту долю можно разложить по растянутой во времени серии внешних запросов, скрыв, таким образом, в исходящем трафике. Основным предметом утечки должны являться тексты на естественном языке (иногда требуется и графика, но сосредоточиться нужно на текстах). Это позволяет ещё уменьшить трафик – тексты хорошо сжимаются при передаче.

Возникает вопрос: где хранить тексты страниц, если мы растянули передачу и для того, чтобы утекло десять килобайт текста, требуется несколько сеансов работы браузера и большой “легитимный” трафик для прикрытия? Действительно, пользователь почитал страницу и закрыл её, а браузеру ещё передавать и передавать. Ответ: есть кэш, читать текст страницы нужно из него. Обычно браузерный кэш включен. Да, страницы, полученные по https, не должны бы сохраняться в кэше, но ведь наш шпионский браузер может сделать исключение. Тем более, не обязательно кэшировать текст страницы в открытом виде, можно преобразовать его в некоторый “служебный файл”, – попутно сжав, да, – и сохранить так.

Другой вопрос: что взять за основу для построения канала утечки? А тут годятся любые сервисы, принимающие некие персонализированные настройки (например, проверка посещаемых URL на “фишинговость и вредоносность”). Сжатый текст будем передавать так: небольшие блоки подмешиваются в токены, которые браузер генерирует при формировании запроса на сервер. Пусть токен содержит 64 байта. Предположим, что 16 из них – это данные утечки. Тридцать запросов с токенами (не много) – 480 байт. Хорошим кодированием можно ужать сюда примерно 2500 знаков текста (можно и заметно больше). Необязательно поддерживать канал открытым, пока не передан весь собранный текст (см. ниже). Вообще, нет никакой необходимости, создавая такой браузер, встраивать в него излишнюю надёжность. Механизмы обеспечения такой надёжности только выдадут затею. Центр посеял много браузеров в окружающее киберпространство. Какие-то из них что-то приносят, какие-то – нет, они сломались. Нестрашно, многочисленность источников компенсирует (для центра) ненадёжность каждого из них.

Вот ещё занимательная идея: мы договорились, что наш шпионский браузер – популярен, то есть в корпоративной сети таких браузеров много. Поэтому можно увеличить ширину только что описанного “стеганографического” канала: заставим каждый отдельный браузер передавать в рамках утечки блоки текста не последовательно, а выбирая их случайным образом (добавим метки, – это всего несколько бит, – так что на другом конце смогут восстановить последовательность). Таким образом, когда несколько браузеров “сливают” один и тот же текст из интранета, увеличивается “мгновенная” ширина канала, это раз, и улучшается надёжность (резервирование), это два. Последняя особенность связана с допущением “досрочного” закрытия канала. При этом, одновременная передача одной и той же страницы всё равно неизбежна, так как мы не можем оперативно управлять браузерами-шпионами, и центр не знает, что там они найдут в закрытых сегментах локальных сетей.

В комментариях к предыдущей заметке высказали ещё несколько идей. Jno предлагает использовать DNS для передачи части собранной информации (как известно, DNS-трафик хорошо преодолевает всякие корпоративные брандмауэры и редко мониторится на предмет утечек). А Vlad пишет, что не обязательно передавать все “внутренние” страницы подряд. Сперва можно посчитать статистику текста по ключевым словам и спросить центр, нужна ли такая страница. Правда, это подразумевает развитую обратную связь, что может демаскировать канал утечки. Кстати, браузеру хорошо бы спрашивать, есть ли уже найденная только что страница в базе, например, передавая хеш её текста.

Вообще, задача определения “секретных” страниц – тоже интересная (особенно, если нет связи с центром). И её что-то упустили из вида при обсуждении вброса на тему Chrome.

Впрочем, всё это хорошо, но остаётся одна большая трудность: как спрятать дополнительную функциональность браузера внутри его кода. Можно предположить, что большинство пользователей не сами собирают браузер из исходников, а довольствуются “бинарником”. Такой расклад несколько проще. Но ведь и “бинарники” подлежат исследованию. А популярный браузер специалисты разберут дизассемблером вдоль и поперёк.

(Продолжение про риски и политику.)

Кстати, успешный вброс истории о том, как браузер Chrome отсылает содержимое (да, именно, они так и написали) веб-страниц из закрытых интарнетов в Google для индексации, – см. например, бурное обсуждение на roem.ru, где активность поддержала редакция, – это неплохой задел в подготовке почвы для обоснования разработки “своего безопасного браузера”. То есть, потом, в рамках информационной кампании, можно ссылаться: были публикации в специализированной прессе, “продемонстрировавшие нам”, ну и так далее.

В общем, нужно последить за новостями. Это интересно.

Да, можно придумать программное обеспечение, которое эффективно противодействует средствам идентификации пользователей Веба из предыдущей записки. Такое ПО должно быть интегрировано с браузером и некоторыми компонентами ОС, отвечающими за установление соединений и работу с DNS. Принцип маскировки: прыжки между наборами профилей, сгенерированных с помощью анализа “неанонимизированных” компьютеров, и случайное изменение параметров, служащих для построения “отпечатков” (хороший пример: время исполнения тех или иных скриптов, а также время загрузки файлов со сторонних серверов – сюда можно подмешивать нераздражающие пользователя задержки). А ключевой момент в том, чтобы поведение самого защитного ПО не являлось идентифицирующим признаком. Скажем, очевидно, что если вы пользуетесь редким браузером с уникальной (модифицированной) строкой User-Agent, то, собственно, других признаков для идентификации уже и не нужно.

Интересно, что не выйдет использовать один стандартный и распространённый профиль-отпечаток, скопированный с какой-нибудь типичной рабочей станции под управлением Windows: ведь если такой профиль существует и не обладает высокой степенью уникальности, то это просто означает, что системы идентификации не работают. Ну а тогда, спрашивается, зачем огород городить? Более того, нельзя использовать искусственно созданный стандартный “отпечаток”, тиражируя его по всем пользователям вашего защитного ПО. Во-первых, такой отпечаток будет являться отличным демаскирующим признаком; во-вторых, число пользователей ПО должно быть изначально очень велико, иначе различить их можно будет очень просто, всего лишь добавив какой-нибудь один сетевой признак (например, данные геолокации IP-адреса). Да, конечно, можно использовать TOR для доступа к Сети, и такой комплект обеспечит хорошую защиту от идентификации, но это не тот случай – слишком медленно, слишком сложно для обычного пользователя.

Собственно, именно обычность пользователя и накладывает серьёзные ограничения на возможности по созданию такого массового ПО. Вот системы идентификации, они вполне понятно кому нужны – рекламным агентствам, массовым коммерческим интернет-сервисам (контенкстная реклама, социальные сети и т.п., и т.д.). Такой характер спроса фактически гарантирует коммерческую успешность, как сейчас можно говорить: “монетизацию обещает”. А ПО для маскировки – кому оно нужно? Уж точно не перечисленным только что ключевым игрокам интернет-рынка, которые сейчас заказывают музыку. Возможно, такое защитное ПО требуется для работы сотрудникам специальных служб, или, скажем, представителям дипломатического корпуса. Но это точно не массовый пользователь.

Вот хороший пример, показывающий корни интереса к идентификации. Предположим, у вас есть коммерческий веб-сайт, продающий некоторые услуги/товары (скажем, интернет-магазин), и вы поставили на этот сайт счётчик крупной внешней системы статистики, владельцы которой числят в активах популярную систему контекстной рекламы (примеры: Google, “Яндекс”). Приготовьтесь к тому, что только из-за наличия счётчика вы гарантированно теряете клиентов (несколько процентов, как минимум). Почему? Потому что сеть контекстной рекламы будет показывать заинтересованным посетителям вашего сайта рекламу ваших конкурентов. На то она и сеть с “таргетингом”. Посетители, понятно, определяются по информации счётчика и по оставленным этим счётчиком кукам. Реклама при этом следует за посетителем на других сайтах (это каждый может проверить сам, на примере сети “Яндекса”). Тут мало того, что точная идентификация пользователя крайне полезна, так ещё и далеко не каждый владелец коммерческого веб-сайта задумывается о таком побочном эффекте от безобидных счётчиков и систем статистики.

Кстати, всё больше появляется громко анонсируемых сервисов, предлагающих идентификацию пользовательских устройств, подключенных к Интернету. (Например, сейчас пишут про некий проект BlueCava, который предлагает подобную идентификацию.) Речь, конечно, не о банальной записи IP-адресов и куки-файлов, а о некоторых более развитых технологиях, позволяющих отличить один компьютер от другого.

То есть, интересно решение, которое основывается только на анализе параметров устройства “снаружи”, скажем, со стороны веб-сайта, и работает для подавляющего большинства сочетаний ОС/браузер/аппаратура. Практические демонстрации решений, идентифицирующих с той или иной точностью браузеры (но не компьютеры) вне зависимости от кук и IP-адресов, известны уже несколько лет. Хороший пример – Panopticlick. Попробуем разобраться, какие вообще есть источники информации для подобной идентификации.

Понятно, что информация о типе, настройке и “комплектации” конкретного браузера, то есть, о доступных дополнениях,”плагинах”, о шрифтах, о поддержке Javascript, об установленном разрешении экрана, плюс о типе используемой операционной системы – всё это позволяет составить некоторый “отпечаток”. Нельзя сказать, что такой отпечаток всегда будет строго уникальным, но “повторяемость” его на практике довольно низка.

Для уточнения нужно двигаться дальше. Точнее – глубже. Можно попытаться использовать параметры, привязанные к оборудованию. Скажем, как уже предлагалось, “дрейф” системных часов, в компьютерах, которые не синхронизируются по времени. Можно попытаться определить тип процессора и характеристики производительности. Как? Например, замеряя скорость выполнения функций, написанных на том же Javascript (скорость существенно зависит от браузера, впрочем) или внутри Flash. Кстати, наверняка широкое поле деятельности тут предложит HTML5.

Понятно, что даже если IP-адреса устройства меняются, то оно всё равно соединяется с веб-сайтом по TCP – поэтому особенности реализации этого протокола, которые можно измерить со стороны сервера, тоже нужно положить в копилку источников информации.

Современные смартфоны содержат набор дополнительных сервисных устройств, информация от которых также может поступать через браузер на удалённый сервер. Например, GPS. Особенности конкретных реализаций интерфейсов вполне себе могут дать дополнительные биты информации для уточнения уникальности устройства.

При этом остаётся только надеяться, что те же смартфоны не передают своих уникальных идентификаторов веб-серверам – потому что в таком случае задача идентификации оказывается решена со всей доступной точностью.

(А заказчиками идентификации не обязательно являются рекламные агентства. Другое очевидное применение: детектирование подозрительных действий при использовании, скажем, банковской системы.)

Как один из вариантов “навязывания” доступа к Интернету в тех странах, где его блокируют, обсуждаются перспективные “меш-сети”, построенные “стихийно” на базе устройств, розданных непосредственным участникам сети. То есть, у всех пользователей есть некие устройства связи, которые передают данные друг другу, по соседям, оказавшимся в зоне доступа. Если имеется возможность связываться по Wi-Fi, или через сотовую сеть, то эти средства коммуникации также используются. В теории, такая сеть может представлять собой полезный практический инструмент для обмена информации при нахождении участников где-то в городе. Потому что для обеспечения приемлемой связности нужна достаточно высокая плотность узлов, формирующих сеть.

Кроме того, есть ещё целый ряд проблем: например, нужен специальный протокол передачи сообщений, учитывающий возможное длительное нахождение целых сегментов сети и отдельных узлов “в отрыве” от остальных; для того, чтобы обеспечить связь с Интернетом, потребуется набор специальных узлов-шлюзов, имеющих канал “наружу” – это могут быть спутниковые каналы, или стационарная радиосвязь (как вариант).

Но самое занятное вот что: если такие сети будут созданы, то как с ними бороться? Понятно, что раз отключают Интернет, то потребуется и технология отключения всяких “меш-сетей”. Вариант, предусматривающий поиск пользователей и изъятие у них средств связи – нужно рассматривать отдельно, так как он самый эффективный, это понятно. При этом определить местонахождение пользователей несложно, используя другую “сетевую технологию” – сеть из связанных между собой приёмников. Можно, впрочем, и традиционным пеленгатором ограничиться. С другой стороны, оборудование пользователей может быть устроено таким образом, что сеансы связи очень сложно обнаружить. Тут помогут известные методики с быстрой сменой частот, с одновременной работой нескольких передатчиков на одной частоте, и тому подобные фокусы. Но вот что-то сомнительно выглядит реализация такой технологии в дешёвых и простых базовых коммуникаторах-узлах, это не говоря о сложности соответствующих протоколов. (Хотя, переключение частот – стандартная функция GSM. Но в данном случае это никак не помогает.)

В качестве другого варианта борьбы можно предложить создание помех в радиоэфире. Это метод, содержащий всякие побочные неприятности – нехорошо загрязнять эфир “по площадям”. (Понятно, что если в коммуникаторах всё же реализован механизм смены частот из предыдущего абзаца, то и с помехами возникнут трудности.)

Более изящный вариант такой: противодействующей стороне нужно приобрести в пользование несколько узловых-смартфонов, разобраться с их устройством, активно включиться в сеть и вносить помехи на уровне протокола. Например, рассылать ложные сообщения о доставке пакетов данных, прикидываться другими узлами, активно принимать данные для доставки, но не доставлять их (сообщая, что доставлены) и так далее, и тому подобное. Естественно, сеть можно устроить так, чтобы противодействовать подобным участникам-злоумышленникам. Используя индивидуальные криптографические ключи и некие механизмы формирования “репутации” узлов – можно автоматически определять “вредителей” и игнорировать их. В противном случае, как показывает богатейший опыт Интернета, даже малое число активных узлов противодействия, операторы которых действуют слаженно, быстро сделает невозможной работу всей сети. Тем более, что, в отличие от Интернета, узлы “меш-сети” не управляются квалифицированными администраторами, а находятся в руках неопытных пользователей, непонимающих, что там внутри коробочки происходит. (Возможно, в сеть встроят некую логическую управляющую инфраструктуру, позволяющую контролировать её работу из центра, где и находятся квалифицированные специалисты.)

Что получается в итоге? Получается, что для того, чтобы “меш-сеть”, созданная для “навязывания” Интернета и построения телекоммуникационной среды на некоторой произвольной территории, получила шансы на успех, требуется спроектировать довольно сложные базовые устройства и отладить новые хитрые протоколы связи. А иначе сеть подавят практически так же быстро, как и обычный локальный сегмент Интернета. То есть, затраты на получение подобной технологии и на её использование, оказываются очень ощутимыми. Пойдут ли на такие затраты?

В продолжение темы про IPv6. У этого нового протокола есть интересное математическое (вычислительное, если хотите) отличие от IPv4. Так, в старом протоколе есть не более 2³²=4294967296 (около 4 млрд) потенциально различимых адресов. Предположим, что мы задумали каждому возможному адресу сопоставить один байт с некоторой информацией. Массив займёт примерно 4 гигабайта. Это объём ОЗУ обычного современного настольного компьютера. То есть, подобные таблицы, “перечисляющие” некоторым образом всё пространство IPv4, можно “ворочать” без особых вычислительных затрат. Не важно, для чего используются такие массивы-таблицы, для обозначения каналов доставки пакетов, для подсчёта обращений к некоторым узлам, для балансировки нагрузки глобально доступных сервисов или для чего-то ещё. Главное, что возможен простой, “прямой” способ работы со всем множеством адресов.

Реализовать подобное для IPv6 – не выйдет. 2¹²⁸ элементов невозможно уместить в память никакого существующего суперкомпьютера. Хуже того, их невозможно даже перебрать за разумное время ни на каком суперкомпьютере. Другими словами, множество адресов IPv6, перечислимое математически, не “перечислимо” в суровой программистской реальности, потому как “нет таких компьютеров”. Казалось бы – ну и ладно, кому нужны эти гигантские таблицы?

Но, похоже, эта особенность IPv6 громко аукнется. Так, блоки IPv6-адресов уже нарезают многочисленными кусочками (мощность позволяет же), для которых нужно будет строить не только маршруты доставки пакетов, но и всякие сопутствующие элементы, типа обратных зон DNS для серверов, попавших в данный блок адресов, или записей в “инфраструктурных” базах данных (спам-фильтры, справочники по обмену трафиком, списки “проксей”, геолокационная привязка – можно ещё много придумать). И если раньше, с IPv4, рост объёмов “сопутствующей” информации был ограничен вполне себе обозримым пределом, то IPv6 даёт разгуляться так, что и поддержка обратных зон, как задача, может легко подобраться к границе практической разрешимости.

Хотя, понятно, конечно, что “на свободе” не должно ходить IPv6-адресов сильно больше, чем существует устройств, способных такие адреса использовать.

Мы тут обсуждаем смартфоны и сходную продукцию (ключевые слова: Apple, Android), в том смысле, что если сильно беспокоиться о том, что подобные устройства активно шпионят за “носителем” и “сливают информацию в центр”, то совсем нельзя пользоваться современными, удобными технологиями коммуникации. Действительно, удобно – и альтернативы нет. Куда податься? Ответ теоретика такой: в сторону открытых аппаратных платформ (ОС с открытым исходным кодом и так уже есть).

Проблема в том, что инициативы по созданию открытой аппаратуры для сотовой связи пока существуют в крайне далёком от практического использования состоянии, к сожалению. Но более или менее живые проекты есть. Смотрите, например, в сторону OpenBTS. Технологии дешевеют, поэтому создать открытую платформу “для гиков” реально. Обычным пользователям, понятно, это не интересно. Именно из-за отсутствия такого интереса никто из коммерческих телекоммуникационных гигантов не выпускает ничего подобного.

Впрочем, есть и ещё одна проблема, и она гораздо круче чисто технических трудностей аппаратуры: сейчас ужесточают отслеживание операторами связи уникальных идентификаторов оборудования (IMEI). Это глобальные идентификаторы. Соответственно, если эта тенденция разовьётся, то могут появиться дополнительные ограничительные меры по допуску конкретного оборудования (не SIM-карты!) в сеть провайдера. Ну, раздадут ключи по коммерческим производителям “шпионских” смартфонов, а открытую платформу просто не будут авторизовать в сети связи, даже при использовании вполне легальной SIM-ки. И открытая платформа окажется бесполезной в реальной жизни, так как большие сети под неё силами энтузиастов не построить.

Сейчас вот бурно обсуждают растиражированное заявление представителя Microsoft о том, что корпорация раскроет для специальных служб исходные коды Skype. (Такое раскрытие – это обычная разумная практика: если исходные коды ПО хороши, то вообще нет смысла их прятать, ага.) Сложилась какая-то путаница с отношением этого факта “потенциального раскрытия” к алгоритмам шифрования Skype (как известно, шифрование в этом инструменте голосовой связи давно являлось одним из инструментов маркетингового продвижения). Алгоритм шифрования тоже нет никакого смысла скрывать. Это хорошо, если используется опубликованный алгоритм. Плохо, если некий “секретный”. Очевидно, что используемый алгоритм можно восстановить по исходникам – не понятно, зачем об этом сообщают, как о новости. Хитрость-то не в этом.

Хитрость в том, что исходники сильно упрощают обнаружение дефектов в реализации добротного алгоритма шифрования (дефектов, намеренно внесённых или из-за ошибки разработчиков – не так важно). Дефекты в реализации могут позволить провести вскрытие шифрованного трафика малыми силами, вне зависимости от того, насколько стоек исходный алгоритм.

То есть, можно использовать хоть четырёхкилобитный ключ, но если при этом все значения битов ключа из-за ошибки в коде, через кривой буфер, утекают в “шифрованный” трафик – стойкость ключа уже не имеет значения: достаточно знать, в каких позициях зашифрованных блоков брать значения ключевых битов. И эти позиции можно легко вычислить, имея на руках исходный код. Впрочем, в данном сильно утрированном примере, можно всё вычислить и без исходников, просто подсовывая в программу заданные, правильно подобранные ключи/открытые тексты и выполняя анализ результатов шифрования.

Другими словами, если Skype был кривым внутри, в смысле криптографии, то и раскрытие/нераскрытие исходников никак ситуацию для пользователей не ухудшит (разве что улучшит, кстати, если ПО будет получать соответствующие сертификаты).