Теоретически, да (для некоторого определения «транзит»), но на практике для «Зашифровано ли это сообщение при передаче?» ответ может быть. Короче говоря, просто ssl = True или эквивалентное место, где-то, почти ничего не гарантирует, по всем причинам, объясненным ниже.
Следовательно, вам, вероятно, не понравится следующий подробный ответ, так как в основном он показывает, что все просто и что у вас нет 100% гарантии, даже если вы все делаете правильно и у вас МНОГИЕ вещи нужно делать правильно.
Кроме того, TLS - это настоящее истинное имя используемой вами функции, SSL не используется уже 20 дней, да, все используют старое имя, но это, тем не менее, не дает права на такое использование.
Во-первых, и это очень важно, TLS предоставляет различные гарантии, среди которых конфиденциальность (содержимое зашифровывается при передаче), а также аутентификация, которая в вашем случае гораздо важнее, и по следующим причинам.
Вам необходимо убедиться, что smtp.gmail.com разрешено правильно, в противном случае, если ваш сервер использует лежачие преобразователи и находится внутри вредоносной сети, которая перезаписывает DNS-запросы или ответы, вы можете отправить зашифрованный контент ... другому стороной, чем настоящий smtp.gmail.com, который делает контент больше не конфиденциальным, потому что вы отправляете его незнакомцу или активному злоумышленнику.
Чтобы решить эту проблему, вам нужен DNSSEC, если вы серьезно.
Нет, и вопреки тому, что многие люди, похоже, считают и передают, TLS в одиночку или даже DOH - DNS через HTTPS - не решают эту проблему.
Зачем? Из-за следующего, что не является чисто теоретическим, так как
произошло недавно (https://www.bleepingcomputer.com/news/security/hacker-hijacks-dns-server-of-myetherwallet-to-steal-160-000/),, даже если это было в мире WWW, а не в электронной почте, сценарий может быть таким же:
- вам удается захватить IP-адреса, связанные с именем, с которым вы связались (это может быть сделано с помощью BGP-перехвата, и это происходит из-за неправильной конфигурации, по причинам «политики» или активных атак)
- теперь, когда вы контролируете все коммуникации, вы ставите в конце любой сервер, который вам нужен
- вы связываетесь с любым центром сертификации, предоставляющим сертификаты DV, включая полностью автоматизированные
- , поскольку теперь имя в основном соответствует IP-адресу, которым вы управляете, веб-проверка (или даже DNS), которую может выполнить ЦС, будет успешной, и ЦС предоставит вам сертификат для этого имени (который может продолжать работать даже после конец перехвата BGP, потому что центры сертификации могут не быстро отзывать сертификаты, а клиенты могут не проверять это должным образом).
- следовательно, любой стек TLS, принимающий этот ЦС, с радостью примет этот сертификат, и ваш клиент отправит надежно контент с TLS ... другой цели, отличной от намеченной, следовательно 0 реальной безопасности.
На самом деле, как показывает приведенная выше ссылка, злоумышленникам даже не нужно быть настолько умным: даже самозаверяющий сертификат или несоответствие имени хоста могут пройти, потому что пользователям будет все равно, и / или библиотека будет иметь некорректное поведение по умолчанию и / или программист, использующий библиотеку, не будет использовать ее должным образом (см. этот увлекательный, хотя и немного устаревший, документ, показывающий очень печальное состояние многих наборов инструментов "SSL" с некорректным поведением по умолчанию, сбивающими с толку API и различными ошибками, делающими недопустимое использование этого гораздо более вероятно, чем правильные операции TLS: https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf)
Правильное использование TLS не делает DNSSEC неуместным . Обе цели и защищает от различных атак. Вам нужно, чтобы оба были более безопасными, чем один, и любой из двух (правильно использованный) не заменяет другой. Никогда не имел и никогда не будет.
Теперь, даже если разрешение правильное, кто-то может похитить (благодаря BGP) IP-адрес. Затем вы снова отправляете на какой-то хост какой-то зашифрованный контент, за исключением того, что вы на самом деле не аутентифицируете, кто этот хост, так что это может быть кто угодно, если злоумышленнику удалось перехватить IP-адреса smtp.gmail.com (это не нужно делать глобально, только локально, «вокруг», где выполняется ваш код).
Именно здесь включается очень важное свойство TLS аутентификации. Обычно это делается с помощью сертификатов X.509 (которые будут вызываться - неправильно - SSL-сертификаты везде).Каждый конец сообщения проверяет подлинность другого, просматривая представленный сертификат: либо он распознает этот сертификат как особый, либо он признает орган, выдавший этот сертификат, как доверенный.
Так что вам не нужно простодля соединения с TLS на smtp.gmail.com вам также необходимо дважды проверить, что сертификат, представленный тогда:
- предназначен для
smtp.gmail.com (а не для любого другого имени), принимая во внимание подстановочные знаки - выдан центром сертификации, которому вы доверяете
Все это обычно обрабатывается используемой вами библиотекой TLS, за исключением того, что во многих случаях вам необходимо хотя бы явно включить это поведение (проверку) и вам нужно, если вы хотите быть более уверенным, четко определиться с CA, которым вы доверяете.В противном случае происходит слишком много атак, о чем в прошлом могли судить мошеннические, некомпетентные или другие прилагательные CA, которые выдавали сертификаты там, где они не должны (и да, никто не застрахован от этого, даже Google и Microsoft получали в прошлом неправильно выпущенные сертификаты спотенциальные разрушительные последствия).
Теперь у вас есть другая проблема, более специфичная для SMTP и SMTP через TLS: сервер обычно объявляет, что он выполняет TLS, и клиент, увидев это, может затем начать обмен TLS.Тогда все хорошо (за исключением всего вышеперечисленного).Но в пути между SMTP-сервером и вами кто-то может переписать первую часть (что ясно), чтобы удалить информацию о том, что этот SMTP-сервер говорит по TLS.Тогда клиент не увидит TLS и продолжит работу (в зависимости от того, как он разрабатывается, и, конечно, для обеспечения безопасности в таких случаях клиент должен прервать связь), а затем говорить открыто.Это называется атакой с понижением рейтинга.См. Это подробное объяснение, например: https://elie.net/blog/understanding-how-tls-downgrade-attacks-prevent-email-encryption/
Как указывает Стеффен, в зависимости от порта, который вы используете, указанная выше проблема SMTP STARTTLS и, следовательно, возможного понижения не существует, поскольку это для порта 25, которыйВы не используете.Однако я предпочитаю по-прежнему предупреждать пользователей об этом случае, потому что он может быть недостаточно известен, и атаки с понижением рейтинга часто трудно обнаружить и от них сложно защититься (все это потому, что используемые в настоящее время протоколы были разработаны в то время, когда не было необходимостидаже подумайте о защите одного от злоумышленника на пути)
Тогда, конечно, у вас есть проблема используемой версии TLS и ее параметров.В настоящее время стандартом является TLS версии 1.3, но он все еще медленно внедряется повсеместно.Вы найдете много TLS-серверов, знающих только о 1.2. Это может быть достаточно, если принять некоторые меры предосторожности.Но вы также найдете старые вещи, говорящие на TLS 1.1, 1.0 или даже хуже (это SSL 3).Защищенный клиентский код должен отказаться от продолжения обмена пакетами, если он не смог защитить хотя бы соединение TLS 1.2.Опять же, как правило, все это обрабатывается вашей библиотекой «SSL», но опять же вы должны проверить это, включить правильные настройки и т. Д. У вас также есть похожая проблема атаки понижения: без заботы сервер сначала объявляет, что он предлагает, вочистить, и, следовательно, злоумышленник может изменить это, чтобы удалить «самые высокие» безопасные версии, чтобы заставить клиента использовать более низкие версии, которые имеют больше атак (существуют различные атаки на TLS 1.0 и 1.1).Существуют решения, особенно в TLS 1.3 и 1.2 (https://tools.ietf.org/html/rfc7633: «Целью расширения функции TLS является предотвращение атак с понижением версии, которые не предотвращаются иным образом протоколом TLS.»)
В сторонуи вопреки мнению Штеффена, я не думаю, что атаки на понижение TLS являются чисто теоретическими.Некоторые примеры:
- (с 2014 г.): https://p16.praetorian.com/blog/man-in-the-middle-tls-ssl-protocol-downgrade-attack (в основном из-за того, что веб-браузеры стремятся подключиться независимо от того, что обычно происходит, если попытка с наивысшими настройками не удалась, они переходят на более низкие версии, пока не обнаружат случай, когда происходит соединение)
- https://tools.ietf.org/html/rfc7507 специально предлагает защиту, утверждая, что: «Все ненужные понижения протокола нежелательны (например, с TLS 1.2 до TLS 1.1, если и клиент, и сервер действительно поддерживают TLS 1.2); они могут быть особенно вредными, когда результатом является потеря функции расширения TLS при понижении до SSL 3.0. В этом документе определяется SCSV, который можно использовать для предотвращения непреднамеренного понижения протокола между клиентами и серверами, которые соответствуют этому документу, если клиент указываетчто текущая попытка подключения является просто резервной версией и что сервер возвращает фатальное предупреждение, если обнаруживает несоответствующий запасной вариант. "
- https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2019/february/downgrade-attack-on-tls-1.3-and-vulnerabilities-in-major-tls-libraries/ обсуждает не менее 5 CVE в 2018 году, которые допускают атаки TLS: "Два путиXist для атаки TLS 1.3.В каждой атаке сервер также должен поддерживать более старую версию протокола.[..] Второй основан на том факте, что оба партнера поддерживают более старую версию TLS с набором шифров, поддерживающим обмен ключами RSA. »И« Это мастерство достигается благодаря единственной известной атаке с понижением версии на TLS 1.3 ». И«Помимо понижения протокола, существуют другие методы, чтобы заставить клиентов браузера переключаться на более старые версии TLS: сбои в работе сети, подделка TCP-пакета RST, отсутствие ответа и т. Д. (См. POODLE)».
Даже если вы используете правильную версию, вам нужно убедиться, что вы используете правильные алгоритмы, размеры ключей и т. Д. Иногда некоторые серверы / библиотеки включают алгоритм шифрования «NULL», что фактически означает отсутствие шифрования. Глупо, конечно, но этосуществует, и это простой случай, есть гораздо более сложные.
Этот другой пост от Штеффена: https://serverfault.com/a/696502/396475 суммирует и затрагивает различные вышеупомянутые пункты, и дает другое представление о том, что является наиболееважно (мы не согласны с этим, но он ответил и здесь, так что любой может свободно принять оба мнения вучесть и составить собственное мнение).
Следовательно MTA-STS вместо SMTP STARTTLS, https://tools.ietf.org/html/rfc8461 с этим ясным резюме:
SMTP MTA Strict Transport Security (MTA-STS) - это механизм, позволяющий поставщикам почтовых услуг (СП) заявлять о своей способности получать защищенные SMTP-соединения на уровне безопасности транспортного уровня (TLS) и указывать, следует ли отправляющим SMTP-серверам отказывать в доставке на узлы MX, которые не предлагают TLS ссертификат доверенного сервера.
Следовательно, вам необходимо убедиться, что хост, которому вы отправляете свою электронную почту, тоже использует эту функцию, и что ваш клиент правильно запрограммирован для ее обработки.Опять же, возможно, это сделано внутри вашей «Библиотеки SSL», но это ясно показывает, что вам нужен определенный бит для SMTP, и вам нужно связаться с веб-сервером для получения политик SMTP удаленного конца, а также вам нужно выполнить запросы DNS, которые возвращаютсяодин из предыдущих пунктов о том, доверяете ли вы своему распознавателю или нет, и защищены ли записи с помощью DNSSEC.
И со всем вышеперечисленным, которое уже охватывает многие области и действительно трудно сделать правильно,Есть еще много других вопросов ... Транзит безопасен, допустим.Но тогда как получить контент?Вы можете сказать, что это больше не ваша проблема.Может быть.Возможно, нет.Вы хотите нести ответственность за это?Это означает, что вам, возможно, следует также зашифровать само вложение, это является дополнением (а не заменой) защищаемого транспорта.Механизмы по умолчанию для защиты содержимого электронной почты используют либо OpenPGP (имеет более сложный характер), либо S / MIME (имеет более корпоративный характер). Это работает для всего. Затем у вас есть конкретные решения в зависимости от документа (но это не решает проблему защиты тела письма), например, документы PDF могут быть защищены паролем (предупреждение: это было взломано в прошлом).
Я отправляю конфиденциальную информацию
В таком случае это, вероятно, охватывается каким-то контрактом или некоторыми нормами, в зависимости от сферы вашей деятельности. Возможно, вы захотите углубиться в них, чтобы понять, какие именно требования предъявляются к вам, чтобы вы не несли ответственности за некоторые проблемы, если все остальное правильно обеспечено.