Из Википедии, бесплатной энциклопедии
  (Перенаправлено с STARTTLS )
Перейти к навигации Перейти к поиску

"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 библиотек. Например, расширение SMTP RFC 3207 иллюстрирует в следующем диалоговом окне, как клиент и сервер могут начать безопасный сеанс: [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 СУБЪЕКТ: 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Передача файла21 годFTPS990

По крайней мере, для протоколов, связанных с электронной почтой, 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 от Electronic Frontier Foundation . Тем не менее, 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% исходящей электронной почты было зашифровано с использованием как Perfect Forward Secrecy, так и строгой проверки сертификатов. [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. ^ a b Хоффман-Эндрюс, Джейкоб (11 ноября 2014 г.). «Интернет-провайдеры, удаляющие шифрование электронной почты своих клиентов» . Фонд электронных рубежей . Проверено 19 января 2019 .
  6. ^ "Google, Yahoo SMTP почтовые серверы поражены в Таиланде" . 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. ↑ Thomas Ptacek (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 .

Внешние ссылки [ править ]

  • Тесты безопасной электронной почты и инструменты проверяют STARTTLS в диалоговом окне в реальном времени, как в примере выше
  • Убедитесь, что в принимающем домене включен STARTTLS для электронной почты и с каким уровнем безопасности
  • Марголис, Дэниел; Ришер, Марк; Рамакришнан, Бину; Бротман, Александр; Джонс, Джанет. «Строгая транспортная безопасность SMTP MTA (MTA-STS)» . IETF. Механизм, позволяющий поставщикам почтовых услуг заявлять о своей способности получать безопасные SMTP-соединения TLS.