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

"StartTLS" перенаправляется сюда. Для центра сертификации см. StartCom § StartSSL.

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

Команда STARTTLS для IMAP и POP3 определяется в RFC 2595, за SMTP в RFC 3207, за XMPP в RFC 6120 и для NNTP в RFC 4642. За IRC рабочая группа IRCv3 определила STARTTLS расширение. FTP использует команду "AUTH TLS", определенную в RFC 4217 и LDAP определяет расширение протокола OID в RFC 2830. HTTP использует заголовок обновления.

Наслоение

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

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

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

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

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

SSL порты

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

ПротоколЦельНормальный портВариант SSLПорт SSL
SMTPОтправить письмо25/587SMTPS465
POP3Получить электронную почту110POP3S995
IMAPЧитать электронную почту143IMAPS993
NNTPЧитатель новостей119/433NNTPS563
LDAPДоступ к каталогу389LDAPS636
FTPПередача файла21FTPS990

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

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

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

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

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

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

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

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

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

Рекомендации

  1. ^ Тим Диркс; Эрик Рескорла (август 2008 г.). «Протокол безопасности транспортного уровня (TLS)». Редактор RFC. Получено 8 октября 2009.
  2. ^ Пол Хоффман (февраль 2002 г.). «Расширение службы SMTP для безопасного SMTP через безопасность транспортного уровня». Редактор RFC. Получено 8 октября 2009.
  3. ^ Последняя строка в примере добавлена ​​для ясности. См. Например тема, начатая Пол Смит (26 января 2009 г.). "STARTTLS & EHLO". список рассылки ietf-smtp. Консорциум Интернет-почты. Получено 16 сентября 2015.
  4. ^ Dovecot Документация по SSL: http://wiki2.dovecot.org/SSL
  5. ^ а б Хоффман-Эндрюс, Джейкоб (11 ноября 2014 г.). «Интернет-провайдеры удаляют шифрование электронной почты своих клиентов». Фонд электронных рубежей. Получено 19 января 2019.
  6. ^ "Серверы электронной почты SMTP Google и Yahoo поражены в Таиланде". 12 сентября 2014 г.. Получено 31 июля 2015.
  7. ^ «Федеральная комиссия связи США должна запретить интернет-провайдерам блокировать шифрование». 4 ноября 2014 г.. Получено 31 июля 2015.
  8. ^ "Exim Internet Mailer - SMTP-транспорт". exim.org. hosts_require_tls - Exim будет настаивать на использовании сеанса TLS при доставке на любой хост, который соответствует этому списку.
  9. ^ «Кто это стучится в мою дверь? Что такое слежка в Таиланде» (PDF). Privacy International: 21. января 2017. Получено 7 февраля 2020.
  10. ^ Томас Птачек (18 марта 2016 г.). "Против DNSSEC".
  11. ^ Рамакришнан, Бину; Бротман, Александр; Джонс, Джанет; Марголис, Дэниел; Ришер, Марк. "Строгая транспортная безопасность SMTP MTA (MTA-STS)". tools.ietf.org. Получено 22 февраля 2019.
  12. ^ Петерсон, Андреа (12 августа 2014 г.). "Руководитель службы безопасности Facebook об эффекте Сноудена, ответной реакции на приложение Messenger и сохранении оптимизма". Вашингтон Пост. Получено 2 ноября 2014.
  13. ^ Коэн, Дэвид. «Facebook: 95% уведомлений по электронной почте зашифрованы благодаря развертыванию STARTTLS провайдеров». allfacebook.com. Получено 2 ноября 2014.

внешняя ссылка