Выбор мессенджера — сначала модель угроз, потом шифрование
🛡 Выбор мессенджера — сначала модель угроз, потом шифрование
Статья Александра Баулина — честный ликбез для не-специалиста, но с точки зрения ИБ его тезис ценнее, чем ему кажется. Угроза не в уязвимости E2EE-протокола («золотой век» атак на криптографию мессенджеров прошёл), а в цепочке компрометации конечной точки. Упомянутая в материале iOS-уязвимость 2023 года с zero-click в iMessage — классический пример, когда уровень шифрования канала не имеет значения, потому что атакующий читает открытый текст на экране жертвы. AMD-уязвимость, закрытая в конце мая 2026, работает по той же модели: компрометация на уровне UEFI, до загрузки ОС.
По данным habr_infosec, спектр атак на устройства стал шире: кейлогеры, снятие скриншотов, извлечение файлов из-под шифрования на лету. В Linux-инфраструктуре проблема недооценивается сильнее всего — рост пользовательских дистрибутивов привёл к тому, что уязвимости ядра эксплуатируют не реже, чем в Windows. И отдельный пункт — BIOS/UEFI: если вендором не закрыты векторы Meltdown/Spectre-класса, то мессенджер с самым сильным шифрованием теряет смысл.
Упомянутое в статье разделение — Signal, Telegram, Threema, Briar — описывает только транспортный уровень. Пробел в другом: управление устройством. Мессенджеры без привязки к SIM (SimpleX) действительно снижают утечку метаданных и усложняют первоначальную идентификацию абонента. Но как только пользователь установил приложение на скомпрометированный хост, игра окончена. Даже хвалёный открытый код не панацея: Heartbleed в OpenSSL жил годами, несмотря на аудит.
Дискуссия о «самом безопасном мессенджере» уводит CISO в сторону. Вместо рейтинга приложений пора признать: если конечная точка не соответствует модели zero trust endpoint, вопрос транспортного шифрования — третичный. И вот здесь — честный вопрос к сообществу: почему мы всё ещё обсуждаем мессенджеры так, будто проблема на транспортном уровне, когда основная дыра — на хосте, который читает всё в открытом виде?
#мессенджеры #модельугроз #EndToEndEncryption #OperationalSecurity #threatmodeling