Всё описанное ниже — это находка и выводы IT-блогера Marius, изложенные в его посте, а не официально подтверждённая Microsoft уязвимость с присвоенным CVE. Статуса официального заявления у этого нет.
История началась буднично: IT-специалист, ведущий блог Marius World, обновил свои почтовые серверы с Fedora 42 на Fedora Server 43 — и внезапно на него посыпались жалобы. Клиенты перестали получать письма, и все они сталкивались с одной и той же ошибкой сервера: «Cleartext authentication disallowed on non-secure (SSL/TLS) connections». Проще говоря — сервер отказался принимать незашифрованное соединение, которое почтовый клиент пользователя пытался открыть.
Что оказалось не так
Разобравшись, Мариус обнаружил закономерность: все пострадавшие пользовались Outlook — версий примерно с 2007 по 2016.
И вот тут начинается самое неприятное. У всех этих людей галочка «Использовать TLS/SSL» была включена — то есть защита протокола всё это время отключалась без ведома пользователя. Человек был уверен, что его почта зашифрована, а на деле она много лет ходила открытым текстом.
Технически баг срабатывал так: если в настройках выбран порт 110 и протокол POP3, включённый TLS должен был заставить клиент либо автоматически перейти на порт 995, либо хотя бы попытаться поднять TLS на 110-м. Вместо этого Outlook просто продолжал работу вообще без шифрования. Как формулирует сам блогер, клиенты, скорее всего, больше десяти лет забирали почту открытым текстом, будучи уверенными, что шифрование работает.
Почему это заметили только сейчас
Проблема существовала годами, но всплыла именно сейчас по стечению обстоятельств. В Fedora 43 обновился почтовый сервер Dovecot — до версии 2.4.3, где появился бэкенд, полностью запрещающий незашифрованную аутентификацию. Раньше сервер просто пропускал такие соединения, а теперь начал их жёстко отклонять — и проблема стала видимой.
Так долго баг не замечали ещё по двум причинам. Главная — что сегодня почтовые аккаунты по умолчанию создаются через IMAP, где баг не проявляется. Была и вторая: Outlook по умолчанию ставит для POP3 порт 995, так что даже немногие POP3-пользователи чаще всего получали защищённое соединение автоматически. Под удар в итоге попадали в основном нестандартные конфигурации — например, среды хостинг-провайдеров, где приходится поддерживать множество разных настроек.
Масштаб уязвимости точно не определён: затронуты как минимум версии Outlook с 2007 по 2016, возможно и более поздние, но касается ли это Outlook 2019 и новее — пока не подтверждено.
Чем это грозит и что делать
Последствия ровно те же, что и при любой передаче данных открытым текстом: любой, кто находится в вашей сети или на пути к серверу, может читать вашу переписку — а заодно и переписку ваших собеседников. Есть и юридический нюанс: Мариус отмечает, что формально это нарушение GDPR, поскольку закон подразумевает передачу пользовательских данных только по зашифрованным каналам.
Хорошая новость — чинится это в пару кликов: достаточно зайти в настройки учётной записи Outlook и, если используется POP3, убедиться, что порт соединения — 995.
А ещё эта история — наглядный аргумент в пользу того, что шифрование на стороне инфраструктуры должно быть не «галочкой на совести клиента», а требованием по умолчанию. Собственно, вскрыл проблему именно сервер, который перестал принимать plaintext-аутентификацию. По такому же принципу строит облачные сервисы Cloud4Y: защищённые каналы, соответствие ФЗ-152, криптошлюзы и аренда инфраструктуры с шифрованием по умолчанию — так, чтобы данные не утекали открытым текстом даже при кривой настройке клиента.
Комментарии (14)
SerjV
15.07.2026 12:31У всех этих людей галочка «Использовать TLS/SSL» была включена
Кстати, Use the following type of encrypted connections - не галочка, а выпадающий список с 4-мя значениями, из которых два - разные виды инициации TLS/SSL.
Так какой там всё-таки способ воспроизведения-то проблемы, что куда выставить в настройках Outlook для этого надо?
thinkprocess
15.07.2026 12:31У эникейщика 20 лет торчал наружу порт pop3 без шифрования, а виноват outlook?
4kon
15.07.2026 12:31В смысле "галочка шифрования пароля а не сообщения" ? Письмо скачивается в рамках той же tls сессии, что и проверка логина/пароля, поэтому там все зашифровано.
SerjV
15.07.2026 12:31Есть галочка "использовать шифрованную проверку пароля", а есть список значений для "использовать шифрование соединения" с типами шифрования.
И вот ЧТО они там настраивали в оригинале - непонятно.
leveler
Не пойму причём здесь Outlook? Тот же Exchange Server позволяет на любом порту сделать с TLS, без TLS или и так и так. Это проблема кривой настройки у провайдера электронной почты.
aamonster
При том, что он пользовательскую настройку игнорировал.
Хотя, конечно, при настройке сервера нельзя полагаться на правильные настройки пользователя.
SerjV
Причём неправильную пользовательскую настройку - для 110 порта там должно быть значение STARTTLS, а не TSL/SSL.
Возможно, не замечали баг еще и потому, что кто мог заметить - ставили в Outlook правильную настройку...
SerjV
Начнём с того, что для "обычных" портов у Outlook должна быть не «Использовать TLS/SSL» (который legacy implicit encryption), а "Использовать STARTTLS", который explicit encryption (в аглицком варианте Outlook (classic) настройка называется "Use the following type of encrypted connections"), который нынче актуален (не надо новый порт для существующего протокола придумывать, есть почти для всех протоколов, включая POP3, IMAP, SMTP, FTP... Кроме HTTP) и которые именно и преобразует нешифрованное соединение в шифрованное.
Ну и да, на стороне сервера надо запрещать обмен полезной нагрузкой (включая аутентификацию) до прохождения команды протокола STARTTLS.
Странно, если Dovecot этого не умел до недавнего времени...
max9
умел с рождения, дефолтные конфиги просто поменялись. а крутить и харденить их людям обычно лень
непонятно при чем тут федора, в дебиан тот же заехало сильно раньше
Busla
В современных реалиях скорее STARTTLS - легаси, которое должно умереть. Непрозрачное решение, требующее влезать внутрь существующего протокола, все плюсы которого - экономия на стандартизации порта. В противовес TLS - это отдельный уровень, его вообще можно вынести на отдельный сервер/балансировщик и таким образом распределять нагрузку, независимо апгрейдить.
SerjV
Исторически - implicit encryption появилось раньше. Можно было через wrapper на другом порту терминировать SSL (тогда еще не TLS) соединение и перебросить в расшифрованном виде в порт "обычного" серверного демона без всякой модификации оного (даже для поддержки тогда еще SSL).
Ну а когда уже в сами серверы всё проинтегрировали - разницы уже нет, STARTTLS explicit encryption нынче стандарт. Да и балансировщики такое тоже обработают - если не терминировать на них TLS, то вообще без разницы, legacy SSL там схема или STARTTLS, а если терминировать - то всё равно уже у приличных балансировщиков есть поддержка соответствующих протоколов на прикладном уровне.
4kon
Путаете настройки Outlook для IMAP и POP3. Outlook для POP3 не умел и не умеет в STARTTLS, при выборе POP3 в настройках поле "Use the following type of encrypted connections влияет только на SMTP соединение. Проблема с Outlook надуманная, если хочется шифрованного соединения, то Outlook работает только c 995 портом. Всякие “хитрые” уловки из статьи, выберем 995 порт, поменяем руками на 110 и оставим галку “This server required an encrypted connection (SSL/TLS)” не приведут к использованию ни SSL/TLS ни STARTTLS, да собственно и не должны.
dartraiden
Outlook проявлял ненужный ум, пытаясь угадать, чего хочет пользователь.
Если пользователь выбирал порт, на котором обычно используется незащищённый POP3, то Outlook игнорировал включённую опцию про TLS, полагая, что пользователь ошибся, включив её, и хочет незащищённое соединение.