Comments 28
Онлайн-проверялки это конечно здорово, но по факту достаточно посмотреть заголовки Received: на предмет наличия “with [E]SMTP“ (передачача без транспортного шифрования) или “with [E]SMTPS“ (передача с транспортным шифрованием).
Ну и полезно помнить, что электронная почта by design не пригодна для передачи конфиденциальной информации в незашифрованном виде. Поэтому всё, что не GPG (PGP, S/MIME etc) — скорее иллюзия безопасности.
Вот он, комментарий моей мечты! Большое спасибо за экспертизу, мне не хватало как раз этой информации, чтобы быть на 100% уверенным!
Нету подстроки "SMTPS" в хэдерах сообщения!
Самое интересное, что по-видимому вы имели в виду в первую очередь:
Return-Path: <info@gemotest.ru>
Received: from mx.gemotest.ru (mx.gemotest.ru. [185.11.199.177])
by mx.google.com with ESMTP id 38308e7fff4ca-330a9246e72si4380551fa.368.2025.07.18.07.16.54
for <мойимэйл@gmail.com>;
Fri, 18 Jul 2025 07:16:55 -0700 (PDT)Вот это, как я понимаю, самая интересная нам часть, тот самый обмен между двумя серверами по открытой сети. Сравним с хорошим сервером gosuslugi.ru, про который Gmail говорит: "security: Standard encryption (TLS)":
Return-Path: <no-reply@gosuslugi.ru>
Received: from smtp68.gosuslugi.ru (smtp68.gosuslugi.ru. [213.59.254.1])
by mx.google.com with ESMTPS id 2adb3069b0e04-55a35dc53c0si1527328e87.565.2025.07.20.07.24.40
for <мойимэйл@gmail.com>
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Sun, 20 Jul 2025 07:24:41 -0700 (PDT)Добавил UPD в конце поста, закрепил ваш комментарий и вот этот мой ответ.
Тут Почта России свои уведомления без шифрования отправляет, а вы гемотест...
ну вообще то есть наш славный "роскомнадзор" , слей туда, и они начнут процесс насилия по всем правилам...
Я, конечно, не сетевой безопасник, но "So email is encrypted but the recipient domain is not verified", наверное, означает что email таки зашифрован, но домен получателя верифицировать не получилось.
В теории, они перешли на пресловутый серт Минцифры.
Ваша правда, означает именно это. Однако эту фразу сказала онлайн-проверялка. Целевой сервис, Gmail, сказал что-то более страшное. И кажется, у него (и/или у других почтовых серверов) были основания на такое более страшное поведение.
Даже если перешли, то всё равно могли бы параллельно поддерживать работу с зарубежными серверами по зарубежным алгоритмам. Благо, через Let's Encrypt такие сертификаты вообще бесплатно можно сделать. Сейчас проверялки однозначно говорят: сертификаты есть, сертификаты на иностранных алгоритмах, цепочки идут к иностранным корневым... Короче, всё как надо, только вот просрочились сертификаты.
А разве важно какие сертификаты у MX серверов самого Гемотеста, если мы говорим про почту отправляемую ими? Это ведь должно влиять только на возможность послать им почту по зашифрованному каналу.
А в случае когда канал устанавливается от их почтового сервера к серверам Gmail, то для установки зашифрованного соединения используются серты Gmail. Другое дело, если почтовый сервер отправителя нестроен так, что он даже не пытается устанавливать защищенное соединение.
Очень хороший и интересный вопрос! Спасибо!
Не знаю, как настроены конкретные сервера, например сервер Gmail. Возможно, они требуют двустороннего TLS, а без него не работают. Возможно, при неуспехе двустороннего TLS они делают фолбэк на менее безопасный односторонний. Это две разные технологии защиты SMTP, как я нагуглил: https://stackoverflow.com/questions/69527396/does-inter-mail-server-connection-use-mutual-tls-mtls
В то же время, даже если рассуждать максимально оптимистично, то проблема ведь всё равно есть. Даже если например Gmail вполне удовлетворится односторонним, это будет означать, что письма в обратном направлении, на домен gemotest.ru, будут незашифрованными, что конечно убирает мой главный поинт про результаты анализов, но для компании Гемотест всё равно является серьёзной уязвимостью. А ещё это означает, что промежуточные узлы в сети всё равно могут получать информацию из писем с домена gemotest.ru, но стоимость атаки увеличивается: нужно провести не пассивную атаку прослушивания канала, а активную атаку имперсонации, т.е. сказать по сети: "Да-да, gemotest.ru это я, но пруфов не будет! Со мной устанавливайте односторонний TLS и мне шлите письма!"
Чтобы полагаться на почтовый сервер, он должен быть свой собственный. И почтовые клиенты должны быть настроены своими руками. Тогда Вы можете быть уверенными в письмах внутри него. Также Вы можете написать письмо наружу и быть уверенными что Ваш почтовый сервер проверит сертификат сервера получателя и доставит до него. Все остальное под вопросом.
Здесь уже надо использовать внешнее шифрование. То есть Вы создаете ключевую пару. Например это может быть личная УКЭП, передаете сертификат Гемотесту. ПО Гемотеста шифрует результат анализов Вашим сертификатом и в зашифрованном виде передает на свой почтовый сервер (ПС), откуда уходит на ПС GMail. Здесь все зашифровано и оператор сервиса не может прочитать письмо. Дальше Вы скачиваете письмо к себе на компьютер и здесь уже локально расшифровываете с помощью закрытого ключа УКЭП.
Это так в теории, возможно ли на практике, я не уверен. Хотя если они снабжают анализы своей УКЭП, возможно готовы и шифровать на сертификат пациента.
Ваша правда. Это идеальный сценарий. Но очень сильно сомневаюсь, что они что-то такое проворачивают, судя по моей с ними переписке.
Попробуйте попросить их. Мотивируйте тем, что Вы не имеете необходимых знаний, чтобы настроить собственный почтовый сервер, поэтому вынуждены пользоватся общедоступными. В тоже время вправе рассчитывать на защиту ПДн от доступа третьих лиц (в т.ч. операторов почтовых сервисов), тем более что медицинские данные это особая категория. А получить их в офисе на бумаге Вам не удобно. Обосновать можно например тем что по работа связана с командировками в труднодоступные места, где нет их офисов. А получить результаты анализов важно оперативно, в т.ч. могут выявиться заболевания которые требуют немедленного реагирования: назначения / отмены препаратов, изменения условий труда и т.п.
Онлайн-проверялки это конечно здорово, но по факту достаточно посмотреть заголовки Received: на предмет наличия “with [E]SMTP“ (передачача без транспортного шифрования) или “with [E]SMTPS“ (передача с транспортным шифрованием).
Ну и полезно помнить, что электронная почта by design не пригодна для передачи конфиденциальной информации в незашифрованном виде. Поэтому всё, что не GPG (PGP, S/MIME etc) — скорее иллюзия безопасности.
Вот он, комментарий моей мечты! Большое спасибо за экспертизу, мне не хватало как раз этой информации, чтобы быть на 100% уверенным!
Нету подстроки "SMTPS" в хэдерах сообщения!
Самое интересное, что по-видимому вы имели в виду в первую очередь:
Return-Path: <info@gemotest.ru>
Received: from mx.gemotest.ru (mx.gemotest.ru. [185.11.199.177])
by mx.google.com with ESMTP id 38308e7fff4ca-330a9246e72si4380551fa.368.2025.07.18.07.16.54
for <мойимэйл@gmail.com>;
Fri, 18 Jul 2025 07:16:55 -0700 (PDT)Вот это, как я понимаю, самая интересная нам часть, тот самый обмен между двумя серверами по открытой сети. Сравним с хорошим сервером gosuslugi.ru, про который Gmail говорит: "security: Standard encryption (TLS)":
Return-Path: <no-reply@gosuslugi.ru>
Received: from smtp68.gosuslugi.ru (smtp68.gosuslugi.ru. [213.59.254.1])
by mx.google.com with ESMTPS id 2adb3069b0e04-55a35dc53c0si1527328e87.565.2025.07.20.07.24.40
for <мойимэйл@gmail.com>
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Sun, 20 Jul 2025 07:24:41 -0700 (PDT)Добавил UPD в конце поста, закрепил ваш комментарий и вот этот мой ответ.
Вы совершенно верно выполнили анализ заголовков, и привели именно ключевые строки Received: — ключевая передача письма через «полный опасностей дикий интернет» от gemotest.ru была выполнена без транспортного шифрования (соответственно, все промежуточные сетевые узлы могли беспрепятственно получить доступ к его содержимому); а от gosuslugi.ru с транспортным шифрованием (что правильно со всех сторон).
При отправке письма Гемотестом на GMail:
Сначала ПО Гемотеста где хранятся результаты анализов подключается к почтовому серверу (далее - ПС) Гемотеста. Это подключение скорее всего идет по внутреннему маршруту без выхода в Интернет или VPN соединению и шифрование тут роли не играет.
После этого ПС Гемотеста подключается к ПС Gmail. Я не пользуюсь GMail, но насколько мне известно, все крупные почтовые сервисы уже лет 10 как разрешают только шифрованные соединения. И здесь соединение скорее всего шифрованное. Шифрование в TLS соединении устроено так, что нельзя "записать трафик", а потом расшифровать его, даже если удастся получить закрытый ключ сервера. Для того, чтобы расшифровать данные, нужна MITM атака - пропуск атакующим соединения через свой сервер в реальном времени.
Для защиты от MITM атаки используются сертификаты. Так как соединение устанавливает почтовый сервер Гемотеста, то он будет проверять сертификат у почтового сервера Gmail. Сертификат самого ПС Гемотеста при этом никак не используется. Но может и не проверить (тогда будет возможна MITM атака). Со стороны GMail узнать, выполняет ли ПС Гемотеста проверку сертификата при подключении к ПС Gmail невозможно. Только администраторы ПС Гемотеста знают это. То есть возможна ситуация, когда у ПС отправителя быть валидный сертификат и GMail будет показывать зеленую отметку, а реально проверки на входящем письме нет.
Что именно означает пометка в интерфейсе Gmail я не знаю. Могут предположить что Gmail осуществляет отдельную (не связанную с приемом почты) проверку сертификата ПС Гемотеста на случай если Вы захотите написать им письмо.
Для меня странно, что Вас беспокоит MITM атака. которую еще надо организовать. Для этого понадобится либо наличие уязвимости на оборудовании / софте интернет-провайдера либо сообщник у них. При этом не беспокоит что на GMail Ваши данные лежат в открытом для оператора сервиса виде.
Если Вас беспокоит тема безопасности, то Вы можете проверить наличие в письме валидной DKIM подписи. Она гарантирует что письмо пришло непосредственно от ПС Гемотеста. А не было такого что письмо из Гемотеста ушло мошенникам, те прочитали его и потом отправили Вам, подставив адрес ПС Гемотеста. Например я получаю анализы по емейл от Инвитро и у них этой подписи нет. Пробовал писать им, причем даже комментарий писал для первой линии - вопрос технический по настройке почтового сервера - бесполезно. Прикладывал скриншоты заголовков, где виден ИНЗ (уникальный номер моего анализа в их системе) - бесполезно, даже не понимают о чем речь. Начинают запрашивать ФИО пациента, дату рождения и прочее что не имеет отношения к делу. Если у них есть DKIM подпись, но это именно мне так приходит без нее, ИНЗ достаточно, чтобы найти мой анализ, письмо с ним и разобраться с проблемой.
вот что сказала она о первом сервере mx.gemotest.ru
Что при обращении к нему по HTTPS (а не SMTP) мы видим такую картину. Должен ли SMTP-сервер вообще что-то отдавать по HTTPS - вопрос дискутируемый, но и совсем другой.
Как я понимаю, нет, этот тест специально заточен под почтовые сервера, соединяется с ними и пытается перевести SMTP-соединение на зашифрованные рельсы (STARTTLS). Об этом написано в справке к проверялке, об этом написано в логе её работы. По HTTPS эти адреса вообще не резолвятся -- проверил вот сейчас в браузере.
Тест - да, но выложенная Вами часть лога - про попытку установить TLS-сессию, ни про что больше. Что там они потом договорятся обернуть в эту сессию, из лога никак не понять. И, теоретически возможно, что дальше будет установка именно SMTP-соединения на другом, действительном сертификате. Впрочем, насчет HTTPS я и сам переврал в изначальном комменте.
Ваша правда -- в урезанной мной версии лога не видно, что это всё про SMTP, видно только, что это про TLS. Вот полный лог, раз уж речь зашла: https://pastebin.com/SgbRwsG9
Тоже заметил отсутствие шифрования в письмах от гемотеста. Только присвистнул, потому что настройка корректных заголовков это 5-10 минут времени. Подумал, что, видимо, в гемотесте совсем ленивые админы. Спасибо, что довели до статьи. Есть надежда, что кому-то прилетит по шапке, и таки наведут порядок.
Так шифруется же в итоге: So email is encrypted but the recipient domain is not verified
Иначе Gmail бы не пропустил, просто стерты просроченые
Это написала онлайн-проверялка, поведение которой может отличаться от продовых серверов. Меня всё-таки в первую очередь интересуют последние. Мне Gmail в пользовательском интерфейсе писал, что ничего не зашифровано. А ещё см. закреплённые комментарии: более меня разбирающийся в теме хабравчанин рекомендовал посмотреть на хедеры письма, и согласно ним, шифрования действительно не было.
В Яндекс-почте отображение шифрования непонятное. Принудительно выключил шифрование на исходящих письмах в Postfix (smtp_tls_security_level = none), отправил себе письмо на Яндекс-почту. Письмо пришло с ESMTP в заголовке, но в пользовательском интерфейсе зеленый замок и Шифрование:Да. Хотя в Gmail при таких настройках замок перечеркнутый красный и написано шифрования нет. Час потратил на чат с техподдержкой, в итоге пообещали ответить уже по почте в течение 2х недель.
Это кстати очень забавно — у меня в почте почтовый адрес на который гемотест присылает свои письма, лидирует по количеству спама.
Наравне с ним — вкусвилл, сдек и циан.
Связано ли это с отсуствием шифрования? Не знаю.
Берём анализы на болезни TLS у Гемотеста