stringtranslate.com

Оппортунистический TLS

Opportunistic TLS (Transport Layer Security) относится к расширениям в протоколах связи с открытым текстом, которые предлагают способ обновления соединения с открытым текстом до зашифрованного ( TLS или SSL ) соединения вместо использования отдельного порта для зашифрованной связи. Несколько протоколов используют команду с именем " STARTTLS " для этой цели. Это форма оппортунистического шифрования , которая в первую очередь предназначена как контрмера для пассивного мониторинга .

Команда STARTTLS для IMAP и POP3 определена в RFC  2595, для SMTP — в RFC  3207, для XMPP — в RFC  6120 и для NNTP — в RFC  4642. Для IRC рабочая группа IRCv3 определила расширение STARTTLS, хотя позже оно было объявлено устаревшим. [1] FTP использует команду «AUTH TLS», определенную в RFC  4217, а LDAP определяет OID расширения протокола в RFC  2830. HTTP использует заголовок обновления .

Наслаивание

TLS не зависит от приложений; как гласит RFC  5246:

Одним из преимуществ TLS является то, что он не зависит от протокола приложения. Протоколы более высокого уровня могут прозрачно располагаться поверх протокола TLS. Однако стандарт TLS не определяет, как протоколы добавляют безопасность с помощью TLS; решения о том, как инициировать квитирование TLS и как интерпретировать обмениваемые сертификаты аутентификации, оставлены на усмотрение разработчиков и реализаторов протоколов, работающих поверх TLS. [2]

Стиль, используемый для указания того, как использовать TLS, соответствует тому же различию слоев, которое также удобно поддерживается несколькими реализациями библиотеки TLS. Например, расширение RFC  3207 SMTP иллюстрирует с помощью следующего диалога, как клиент и сервер могут начать защищенный сеанс: [3]

 S: <ждет соединения на TCP-порту 25> C: <открывает соединение> S: 220 mail.example.org ESMTP-сервис готов C: EHLO клиент.example.org S: 250-mail.example.org предлагает теплые объятия приветствия S: 250 STARTTLS C: STARTTLS С: 220 Продолжайте C: <начинает согласование TLS> C & S: <согласовать сеанс TLS> C & S: <проверить результат переговоров> C: EHLO client.example.org [4] . . .

Последняя команда EHLO выше выдается по защищенному каналу. Обратите внимание, что аутентификация необязательна в SMTP, и пропущенный ответ сервера теперь может безопасно рекламировать расширение AUTH PLAIN SMTP, которое отсутствует в ответе в виде простого текста.

SSL-порты

Помимо использования оппортунистического TLS, ряд портов TCP были определены для версий известных протоколов, защищенных SSL. Они устанавливают защищенные соединения и затем представляют поток связи, идентичный старому незашифрованному протоколу. Отдельные порты SSL имеют преимущество меньшего количества циклов передачи данных ; также меньше метаданных передается в незашифрованном виде. [5] Вот некоторые примеры:

По крайней мере для протоколов, связанных с электронной почтой, RFC  8314 отдает предпочтение отдельным портам SSL вместо STARTTLS.

Слабые стороны и смягчения

Opportunistic TLS — это механизм оппортунистического шифрования . Поскольку первоначальное рукопожатие происходит в виде открытого текста, злоумышленник, контролирующий сеть, может изменить сообщения сервера с помощью атаки «человек посередине», чтобы создать видимость недоступности TLS (так называемая атака STRIPTLS ). Большинство клиентов SMTP затем отправят электронное письмо и, возможно, пароли в виде открытого текста, часто без уведомления пользователя. [ необходима цитата ] В частности, многие соединения SMTP происходят между почтовыми серверами, где уведомление пользователя нецелесообразно.

В сентябре 2014 года было обнаружено, что два интернет-провайдера в Таиланде делают это со своими клиентами. [6] [7] В октябре 2014 года было обнаружено, что Cricket Wireless , дочерняя компания AT&T , делает это со своими клиентами. Такое поведение началось еще в сентябре 2013 года с Aio Wireless , которая позже объединилась с Cricket, где эта практика продолжилась. [8] [6]

Атаки STRIPTLS можно заблокировать, настроив SMTP-клиенты на требование TLS для исходящих соединений (например, агент передачи сообщений Exim может требовать TLS через директиву "hosts_require_tls" [9] ). Однако, поскольку не каждый почтовый сервер поддерживает TLS, нецелесообразно просто требовать TLS для всех соединений.

Пример атаки STRIPTLS, используемой в тайской технологии массового наблюдения : [10]

Предположим, что клиентская сторона поддерживает это (разрешение имен клиента и вышестоящего DNS-сервера клиента), эта проблема может быть решена с помощью аутентификации именованных сущностей на основе DNS (DANE), части DNSSEC , и в частности RFC  7672 для SMTP. DANE позволяет объявить о поддержке безопасного SMTP через запись TLSA. Это сообщает подключающимся клиентам, что им следует требовать TLS, тем самым предотвращая атаки STRIPTLS. Проект STARTTLS Everywhere от Electronic Frontier Foundation работает аналогичным образом. Однако DNSSEC из-за сложностей развертывания и особой [ требуется разъяснение ] критики [11] столкнулся с низкой скоростью принятия, и новый протокол под названием SMTP MTA Strict Transport Security или MTA-STS был разработан [12] группой крупных поставщиков услуг электронной почты, включая Microsoft, Google и Yahoo. MTA-STS не требует использования DNSSEC для аутентификации записей DANE TLSA, но полагается на систему центра сертификации (CA) и подход доверия при первом использовании (TOFU) для предотвращения перехватов. Модель TOFU снижает сложность, но без гарантий при первом использовании, предлагаемых DNSSEC. Кроме того, MTA-STS вводит механизм для сообщения об ошибках и режим только для отчетов, что позволяет постепенное развертывание и аудит на предмет соответствия.

Популярность

После разоблачений Эдварда Сноудена в свете глобального скандала с массовой слежкой популярные поставщики электронной почты улучшили безопасность своей электронной почты, включив STARTTLS. [13] Facebook сообщил, что после включения STARTTLS и поощрения других поставщиков [ неоднозначно ] сделать то же самое, до тех пор, пока Facebook не прекратил свою службу электронной почты в феврале 2014 года, 95% исходящих сообщений были зашифрованы как с помощью Perfect Forward Secrecy , так и с помощью строгой проверки сертификатов. [14]

Ссылки

  1. ^ "tls Extension". IRCv3 Working Group. 2012. Получено 6 апреля 2024 .
  2. ^ Тим Диркс; Эрик Рескорла (август 2008 г.). «Протокол безопасности транспортного уровня (TLS)». Редактор RFC . Получено 8 октября 2009 г.
  3. ^ Пол Хоффман (февраль 2002 г.). "SMTP Service Extension for Secure SMTP over Transport Layer Security". Редактор RFC . Получено 8 октября 2009 г.
  4. ^ Последняя строка в примере добавлена ​​для ясности. См., например, ветку, начатую Полом Смитом (26 января 2009 г.). "STARTTLS & EHLO". Список рассылки ietf-smtp . Internet Mail Consortium . Получено 16 сентября 2015 г.
  5. ^ Документация Dovecot SSL: http://wiki2.dovecot.org/SSL
  6. ^ ab Hoffman-Andrews, Jacob (11 ноября 2014 г.). «ISPs Removing Their Customers’ Email Encryption» (Интернет-провайдеры отменяют шифрование электронной почты своих клиентов). Electronic Frontier Foundation . Получено 19 января 2019 г.
  7. ^ "Почтовые серверы Google и Yahoo SMTP атакованы в Таиланде". 12 сентября 2014 г. Получено 31 июля 2015 г.
  8. ^ «FCC должна запретить интернет-провайдерам блокировать шифрование». 4 ноября 2014 г. Получено 31 июля 2015 г.
  9. ^ "Exim Internet Mailer - Транспорт smtp". exim.org . hosts_require_tls - Exim будет настаивать на использовании сеанса TLS при доставке на любой хост, соответствующий этому списку.
  10. ^ «Кто стучится в мою дверь? Понимание наблюдения в Таиланде» (PDF) . Privacy International : 21. Январь 2017. Получено 7 февраля 2020 .
  11. ↑ Томас Птачек (18 марта 2016 г.). «Против DNSSEC».
  12. ^ Рамакришнан, Бину; Бротман, Александр; Джонс, Джанет; Марголис, Дэниел; Ришер, Марк. "SMTP MTA Strict Transport Security (MTA-STS)". tools.ietf.org . Получено 22 февраля 2019 г. .
  13. ^ Петерсон, Андреа (12 августа 2014 г.). «Глава службы безопасности Facebook об эффекте Сноудена, негативной реакции на приложение Messenger и сохранении оптимизма». The Washington Post . Получено 2 ноября 2014 г.
  14. ^ Коэн, Дэвид (19 августа 2014 г.). «Facebook: 95% уведомлений по электронной почте зашифрованы благодаря развертыванию STARTTLS поставщиками». allfacebook.com . Архивировано из оригинала 22 сентября 2014 г.

Внешние ссылки