Всё описанное ниже — это находка и выводы 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, криптошлюзы и аренда инфраструктуры с шифрованием по умолчанию — так, чтобы данные не утекали открытым текстом даже при кривой настройке клиента.