Деятельность IETF в области конфиденциальности
Андрей РобачевськийОсновные протоколы Интернета, такие как DNS, HTTP, SMTP, были разработаны во время, когда вопросы безопасности и сценарии атак выглядели более безобидно. Хотя работа по усилению защиты велась давно, разоблачения Эдварда Сноудена заставили многих по-другому взглянуть на проблему. Ведущая организация по разработке интернет-стандартов IETF не осталась в стороне и начала массивную работу по защите данных и конфиденциальности. О последних достижениях в этой области - эта статья.
Шифрование
Когда мы говорим о конфиденциальности и защите данных, шифрование безусловно является основной технологией. Поэтому шифрование по-прежнему является приоритетом в IETF. На протяжении нескольких декад IETF неустанно работает над повышением защищенности существующих и разрабатываемых протоколов посредством, в частности, поддержки аутентичности, конфиденциальности и целостности данных. Разоблачения Эдварда Сноудена придали сильный импульс этой работе.
Основная работа в этой области происходит в рабочей группе по безопасности транспортного уровня TLS, разрабатывающей основные спецификации, нескольких рабочих группах, посвященных тому, как применять работу рабочей группы TLS к различным приложениям, и исследовательской группе Crypto-Forum (CFRG),в которой основное внимание уделяется деталям основных криптографических алгоритмов.
Рабочая группа TLS является ключевой задачей IETF, разрабатывающей основные протоколы безопасности для Интернета. Итогом колоссальной работы стало утверждение спецификации TLS 1.3 в качестве стандарта IETF – RFС 8446.
«Колоссальной» – не является преувеличением: разработка стандарта заняла более четырех лет и 28 ревизий спецификации протокола. TLS 1.3 появился ровно десять лет спустя своего предшественника – протокола TLS 1.2. Неудивительно, что его появление представляет собой существенный шаг вперед в превращении Интернета в более безопасное и надежное место.
TLS1.3 предлагает ряд технических преимуществ, таких как существенное уменьшение времени на создание соединения и возможность клиентам быстро возобновлять сеансы с серверов.
Не менее важно, что он также удаляет поддержку нескольких устаревших и небезопасных алгоритмов шифрования и хэширования, которые в настоящее время разрешены (хотя и не рекомендуются) для использования с более ранними версиямиTLS, включая SHA-1, MD5, DES, 3DES и AES-CBC, и добавляет поддержку новых наборов шифров.
Другим важным изменением является переход от обмена ключами с использованием алгоритма RSA к алгоритму Ephemeral Diffie-Hellman (DHE). Причина в том, что ключ RSA сервера обычно не меняется в течение значительного периода времени, что означает, что любой компромисс этого ключа может привести к расшифровке ранее сохраненных сообщений. В новом протоколе ключ RSA используется только для аутентификации. Фактические ключи шифрования генерируются заново каждый сеанс с использованием Diffie-Hellman. Таким образом реализуется так называемая Forward Secrecy –невозможность декодирования ранее перехваченных сообщений в случае скомпрометированного ключа.
Это существенное усиление защищенности передачи данных представляет значительную проблему для так называемых решений сетевой безопасности, а проще – защитных экранов и других устройств инспектирования трафика. При использовании TLS 1.2 на этих устройствах достаточно было установить секретный ключ сервера для декодирования проходящего трафика. Схема работы по перехвату трафика показана на рис. 1. Как видно, при наличии предустановленного секретного RSA-ключа, устройство безопасности имеет возможность сгенерировать секретный ключ сеанса и таким образом инспектировать проходящий трафик.
В случае TLS 1.3 это возможно только путем создания двух защищенных каналов – от клиента к устройству и от устройства к серверу. Неудивительно, что эта проблема вызвала серьезные обсуждения, которые, к счастью, не привели к ослаблению защищенности протокола.
Протокол TLS 1.3 работает поверх TCP. Защита передачи данных на основе датаграммного протокола UDP не менее важна, тем более что все большее число приложений используют именно этот протокол. Рабочая группа TLS завершает работу над спецификацией DTLS 1.3. Основная философия DTLS заключается в построении «TLS над транспортом датаграмм». Передача датаграмм не требует и не обеспечивает надежную или упорядоченную доставку данных. Протокол DTLS сохраняет это свойство для приложений, использующих такой тип передачи. Такие приложения, как потоковое мультимедиа, интернет-телефония и онлайн-игры, используют UDP для связи из-за чувствительного к задержке характера переносимых данных. Поведение таких приложений не изменяется, когда протокол DTLS используется для защиты связи, поскольку протокол DTLS не компенсирует потерянный или повторно запрошенный трафик данных. DTLS 1.3 обеспечивает такой же уровень защищенности передачи данных, что и TLS 1.3.
Server Name Indication (SNI)
Исторически сложилось так, что злоумышленники отслеживали использование веб-сервисов по трем каналам: поиск DNS-запросов, просмотр IP-адресов в заголовках пакетов и просмотр потока данных между пользователем и службами. Эти каналы постепенно закрываются. Растущая часть интернет-связи зашифровывается, в основном, с использованием TLS. Постепенное развертывание решений, таких как DNS в TLS RFC 7858 «Specification for DNSover Transport LayerSecurity (TLS)», затрудняет раскрытие информации DNS.
В то же время, все больше и больше сервисов размещаются на мультиплексированных серверах, исключая однозначную связь между IP-адресом и веб-сервисом. Типичным примером может служить несколько веб-сайтов, обслуживаемых одним и тем же веб-сервером. Однако для возможности использования защищенной сессии с помощью TLS, серверу необходимо знать, для какого имени предоставить серверный сертификат. Проблема в том, что в HTTPS обмен ключами происходит до того, как сервер получит первый веб-запрос; другими словами – сервер заранее не знает доменное имя веб-сервера, к которому хочет получить доступ клиент. Решением этой проблемы является информация об именах сервисов (SNI), а проще – имя виртуального веб-сервера, которое клиент посылает в процессе установления сеанса TLS.
Расширение SNI было стандартизовано в 2003 году в RFC3546 «Transport LayerSecurity (TLS) Extensions».Оно содержит имя виртуального сервера, позволяющее установить соединение TLS с требуемым контекстом сервера. Текущую спецификацию расширения SNI можно найти в RFC6066.
Этот элемент протокола передается в виде открытого текста. Поскольку другие методы мониторинга блокируются, мониторинг фокусируется на понятном SNI.
Спецификация SNI допускала разные типы имен серверов, но только вариант «имя хоста» был стандартизирован и развернут. В этом варианте расширение SNI несет доменное имя целевого сервера. Расширение SNI отображается в текстовом виде в сообщении TLS «ClientHello».
Доступность имени хоста даже при использовании шифрования широко используется – и не всегда с хорошими намерениями. Известно, что эта информация полезна для блокирования трафика в целях цензуры, а также сбора частной информации о посещаемых сайтах. Рабочая группа TLS озадачилась этой проблемой и обсуждает возможное ее решение. Обсуждение возможных подходов описано в проекте стандарта «Issues andRequirements for SNI Encryption in TLS».
Например, в отсутствие шифрования SNI на уровне TLS многие сайты полагаются на решение «HTTP Co-Tenancy». Соединение TLS устанавливается с единым фронт-сервером, а затем HTTP-запросы, принятые по этому соединению, направляются на соответствующий скрытый сервер. Например, TLS SNI может быть настроен на «fronting.example.com», фронт-сервер, и HTTP-запросы, отправленные по этому соединению, могут быть направлены на «hidden.example.com/some-content», обращаясь к скрытой службе. Это решение хорошо работает на практике, когда фронт-сервер и скрытый сервер являются «соарендаторами» одного и того же мультиплексированного сервера.
Это решение можно развернуть без изменения протокола TLS и оно не требует использования какой-либо конкретной версии TLS.
Шифрование на уровне протоколов приложений
Рабочая группа «Использование TLS в приложениях» (UTA) была сформирована, чтобы разработать подходы для использования TLS с различными протоколами приложений. Она уже завершила работу над рядом документов, включая рекомендации по безопасному использованию TLS и DTLS, использование TLS для XMPP и использование процедур проверки подлинности сервера TLS для электронной почты.
Недавно завершилась работа над стандартизацией так называемой строгой транспортной безопасности (Strict Transport Security, STS) для почтовых серверов и пользовательских почтовых агентов, использующих протокол обмена почтовыми сообщениями SMTP.
Как известно, протокол SMTP не обеспечивает защиты данных. Для решения этой проблемы в настоящее время используется расширение STARTTLS для SMTP, задокументированное в RFC3207 «SMTP Service Extension for Secure SMTP overTransport Layer Security»,которое позволяет клиентам и серверам SMTP согласовывать использование канала TLS для шифрованной передачи почты.
Хотя этот оппортунистический протокол шифрования сам по себе обеспечивает высокий барьер против пассивного перехвата трафика, любой злоумышленник, который сможет удалить части сеанса SMTP (например, приглашение «250 STARTTLS»), или тот, кто может перенаправить весь SMTP-сеанс (возможно, перезаписав DNS-запись MX для доставки почты на домен), может выполнять атаки с понижением или перехватом.
Разработанный группой UTA механизм позволяет для доменов получателей, используя комбинацию DNS и HTTPS, указать:
- могут ли почтовые транспортные агенты MTA[1], отправляющие почту в этот домен, ожидать PKIX-аутентифицированной поддержки TLS;
- что клиент должен делать с сообщениями, когда TLS-сеанс не может быть успешно установлен.
Отчасти решение похоже на технологию DANE, которая использует наличие записей DANE TLSA для надежного оповещения поддержки TLS и публикации средств, с помощью которых клиенты SMTP могут успешно аутентифицировать законные SMTP-серверы. Однако, в отличие от DANE, использование которой требует поддержки DNSSEC, MTA-STS полагается на систему серверных сертификатов, обеспечивающих сегодня защиту веб-трафика.
Этот механизм задокументирован в RFC8461 «SMTP MTA Strict Transport Security(MTA-STS)».
Как мы видим, работа по обновлению ключевых протоколов Интернета для лучшей защиты передаваемых данных и большей конфиденциальности не только не прекращается, но охватывает все новые области.
——
[1] Для более подробного знакомства с работой электронной почты в Интернете и используемым терминам, я рекомендую прочитать статью «Всеобъемлющая безопасность электронной почты в Интернете» Уильяма Стеллингса, которую мы также публикуем в этом номере.