Оппортунистический TLS
Оппортунистический TLS (Transport Layer Security) относится к расширениям протоколов обмена открытым текстом, которые предлагают способ обновления обычного текстового соединения до зашифрованного ( TLS или SSL ) соединения вместо использования отдельного порта для зашифрованной связи. Некоторые протоколы используют для этой цели команду под названием « STARTTLS ». Это форма оппортунистического шифрования , которая в первую очередь предназначена для противодействия пассивному мониторингу .
Команда STARTTLS для IMAP и POP3 определена в RFC 2595 для SMTP в RFC 3207 для XMPP в RFC 6120 и для NNTP в РФК 4642 . Для IRC рабочая группа IRCv3 определила расширение STARTTLS, хотя позже оно было признано устаревшим. [ 1 ] FTP использует команду «AUTH TLS», определенную в RFC 4217 и LDAP расширения протокола определяют OID в РФК 2830 . HTTP использует заголовок обновления .
Многослойность
[ редактировать ]TLS не зависит от приложений; по словам RFC 5246 :
- Одним из преимуществ TLS является то, что он не зависит от протокола приложения. Протоколы более высокого уровня могут прозрачно накладываться поверх протокола TLS. Однако стандарт TLS не определяет, как протоколы повышают безопасность с помощью TLS; решения о том, как инициировать установление связи TLS и как интерпретировать обмен сертификатами аутентификации, оставляются на усмотрение разработчиков и разработчиков протоколов, работающих поверх TLS. [ 2 ]
Стиль, используемый для указания способа использования TLS, соответствует тому же различению уровней, которое также удобно поддерживается несколькими библиотечными реализациями TLS. Например, Расширение SMTP RFC 3207 иллюстрирует в следующем диалоговом окне, как клиент и сервер могут начать безопасный сеанс: [ 3 ]
S: <waits for connection on TCP port 25> C: <opens connection> S: 220 mail.example.org ESMTP service ready C: EHLO client.example.org S: 250-mail.example.org offers a warm hug of welcome S: 250 STARTTLS C: STARTTLS S: 220 Go ahead C: <starts TLS negotiation> C & S: <negotiate a TLS session> C & S: <check result of negotiation> C: EHLO client.example.org[4] . . .
Последняя команда EHLO, указанная выше, выдается по защищенному каналу. Обратите внимание, что аутентификация в SMTP необязательна, и пропущенный ответ сервера теперь может безопасно рекламировать расширение SMTP AUTH PLAIN , которого нет в ответе в виде открытого текста.
SSL-порты
[ редактировать ]Помимо использования гибкого TLS, был определен ряд TCP-портов для версий известных протоколов, защищенных SSL. Они устанавливают безопасную связь, а затем предоставляют поток связи, идентичный старому незашифрованному протоколу. Преимущество отдельных портов SSL состоит в меньшем количестве циклов передачи данных ; также меньше метаданных передается в незашифрованном виде. [ 5 ] Вот некоторые примеры:
| Протокол | Цель | Обычный порт | SSL variant | SSL-порт |
|---|---|---|---|---|
| SMTP | Отправить письмо | 25/587 | СМТПС | 465 |
| POP3 | Получить электронную почту | 110 | POP3S | 995 |
| IMAP | Читать электронную почту | 143 | ИМАПС | 993 |
| ННТП | Читатель новостей | 119/433 | ННТПС | 563 |
| ЛДАП | Доступ к каталогу | 389 | ЛДАПС | 636 |
| FTP | Передача файлов | 21 | FTPS | 990 |
По крайней мере, для протоколов, связанных с электронной почтой, RFC 8314 предпочитает отдельные порты SSL вместо STARTTLS.
Слабые стороны и меры по их устранению
[ редактировать ]Оппортунистический 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 ]
220 smtp.gmail.com ESMTP mail.redacted.com - gsmtp ehlo a 250-smtp.gmail.com at your service, [REDACTED SERVICE] 250-SIZE 35882577 250-8BITMIME # The STARTTLS command is stripped here 250-ENHANCEDSTATUSCODES 250-PIPELINING 250 SMTPUTF8 |
220 smtp.gmail.com ESMTP - gsmtp ehlo a 250-smtp.gmail.com at your service 250-SIZE 35882577 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250 SMTPUTF8
|
Эта проблема решается с помощью проверки подлинности именованных объектов на основе 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 представляет механизм отчетности о сбоях и режим только отчетов, что обеспечивает постепенное развертывание и проверку соответствия требованиям.
Популярность
[ редактировать ]![[икона]](http://upload.wikimedia.org/wikipedia/commons/thumb/1/1c/Wiki_letter_w_cropped.svg/20px-Wiki_letter_w_cropped.svg.png){kind=small} | Этот раздел нуждается в расширении . Вы можете помочь, добавив к нему . ( май 2016 г. ) |
После разоблачений Эдварда Сноудена в свете глобального скандала с массовой слежкой популярные провайдеры электронной почты улучшили безопасность своей электронной почты, включив STARTTLS. [ 13 ] Facebook сообщил, что после включения STARTTLS и поощрения других провайдеров [ двусмысленный ] Чтобы сделать то же самое, до тех пор, пока Facebook не прекратил свою службу электронной почты в феврале 2014 года, 95% исходящей электронной почты шифровались как с помощью Perfect Forward Secrecy , так и со строгой проверкой сертификатов. [ 14 ]
Ссылки
[ редактировать ]- ^ «Расширение tls» . Рабочая группа IRCv3. 2012 . Проверено 6 апреля 2024 г.
- ^ Тим Диркс; Эрик Рескорла (август 2008 г.). «Протокол безопасности транспортного уровня (TLS)» . Редактор RFC . Проверено 8 октября 2009 г.
- ^ Пол Хоффман (февраль 2002 г.). «Расширение службы SMTP для защиты SMTP через безопасность транспортного уровня» . Редактор RFC . Проверено 8 октября 2009 г.
- ^ Последняя строка в примере добавлена для ясности. См., например, тему, начатую Пол Смит (26 января 2009 г.). «СТАРТТЛС И ЭХЛО» . список рассылки ietf-smtp . Консорциум Интернет-почты . Проверено 16 сентября 2015 г.
- ^ Dovecot Документация SSL: http://wiki2.dovecot.org/SSL.
- ^ Jump up to: а б Хоффман-Эндрюс, Джейкоб (11 ноября 2014 г.). «Интернет-провайдеры снимают шифрование электронной почты своих клиентов» . Фонд электронных границ . Проверено 19 января 2019 г.
- ^ «SMTP-серверы электронной почты Google и Yahoo пострадали в Таиланде» . 12 сентября 2014 года . Проверено 31 июля 2015 г.
- ^ «Федеральная комиссия связи США должна запретить интернет-провайдерам блокировать шифрование» . 4 ноября 2014 года . Проверено 31 июля 2015 г.
- ^ «Exim Internet Mailer — транспорт smtp» . exim.org .
hosts_require_tls — Exim будет настаивать на использовании сеанса TLS при доставке на любой хост, соответствующий этому списку.
- ^ «Кто это стучится в мою дверь? Понимание наблюдения в Таиланде» (PDF) . Privacy International : 21 января 2017 г. Проверено 7 февраля 2020 г.
- ^ Томас Птачек (18 марта 2016 г.). «Против DNSSEC» .
- ^ Рамакришнан, Бину; Бротман, Александр; Джонс, Джанет; Марголис, Дэниел; Ришер, Марк. «Строгая транспортная безопасность SMTP MTA (MTA-STS)» . www.tools.ietf.org . Проверено 22 февраля 2019 г.
- ^ Петерсон, Андреа (12 августа 2014 г.). «Руководитель службы безопасности Facebook об эффекте Сноудена, негативной реакции на приложение Messenger и сохранении оптимизма» . Вашингтон Пост . Проверено 2 ноября 2014 г.
- ^ Коэн, Дэвид (19 августа 2014 г.). «Facebook: 95% электронных писем с уведомлениями зашифрованы благодаря развертыванию STARTTLS провайдерами» . allfacebook.com . Архивировано из оригинала 22 сентября 2014 года.
Внешние ссылки
[ редактировать ]- Тесты и инструменты безопасной электронной почты проверяют STARTTLS в диалоговом окне в реальном времени, как показано в примере выше.
- Проверьте, включен ли в принимающем домене STARTTLS для электронной почты и какой уровень безопасности.
- Марголис, Дэниел; Ришер, Марк; Рамакришнан, Бину; Бротман, Александр; Джонс, Джанет. «Строгая транспортная безопасность SMTP MTA (MTA-STS)» . IETF. Механизм, позволяющий поставщикам почтовых услуг заявлять о своей способности получать безопасные SMTP-соединения Transport Layer Security (TLS).