Мы включили TLS 1.3. Почему вам стоит сделать то же самое

27 апреля 2019

В начале года, в отчете о проблемах и доступности интернета за 2018-2019 мы уже писали, что распространение TLS 1.3 неизбежно. Некоторое время назад мы сами развернули версию 1.3 протокола Transport Layer Security и, после сбора и анализа данных, наконец, готовы рассказать об особенностях этого перехода.

Председатели рабочей группы IETF TLS пишут:
«Вкратце, TLS 1.3 должен предоставить фундамент более безопасного и эффективного Интернета на следующие 20 лет».

Разработка TLS 1.3 заняла долгих 10 лет. Мы в Qrator Labs, вместе со всей остальной отраслью, внимательно следили за процессом создания протокола от первоначального проекта. За это время потребовалось написать 28 последовательных версий черновика для того, чтобы в конечном счёте в 2019 году свет увидел сбалансированный и удобный в развертывании протокол. Активная поддержка TLS 1.3 рынком уже очевидна: внедрение проверенного и надежного протокола безопасности отвечает требованиям времени.

По словам Эрика Рескорлы (технического директора Firefox и единственного автора TLS 1.3) в интервью The Register:

«Это полная замена TLS 1.2, использующая те же ключи и сертификаты, поэтому клиент и сервер могут автоматически общаться по TLS 1.3, если оба его поддерживают», — сказал он. «Уже есть хорошая поддержка на уровне библиотек, а Chrome и Firefox по умолчанию включают TLS 1.3».

Параллельно в рабочей группе IETF TLS заканчивается подготовка RFC, объявляющего старые версии TLS (за исключением только TLS 1.2) устаревшими и непригодными для использования. Вероятнее всего, финальный RFC увидит свет до конца лета. Это ещё один сигнал IT-индустрии: обновление протоколов шифрования не стоит откладывать.

Список текущих реализаций TLS 1.3 доступен на Github для всех, кто ищет наиболее подходящую библиотеку: https://github.com/tlswg/tls13-spec/wiki/Implementations. Очевидно, что принятие и поддержка обновленного протокола будет — и уже идет — быстрыми шагами. Понимание того, насколько фундаментальным стало шифрование в современном мире, распространилось достаточно широко.
 

Что изменилось по-сравнению с TLS 1.2?

Из заметки Internet Society:
«Как TLS 1.3 делает мир лучше?

TLS 1.3 включает определённые технические преимущества — такие, как упрощенный процесс рукопожатия (handshake) для установления безопасного соединения — а также позволяет клиентам быстрее возобновлять сессии с серверами. Эти меры призваны уменьшить задержку на установку соединения и количество неудачных соединений на слабых каналах, которые часто используются в качестве оправдания для предоставления только нешифрованных HTTP-соединений.

Не менее важно и то, что устранена поддержка нескольких устаревших и небезопасных алгоритмов шифрования и хеширования, которые все еще разрешено (хотя и не рекомендуется) использовать с более ранними версиями TLS, включая SHA-1, MD5, DES, 3DES и AES-CBC, одновременно добавляя поддержку новых наборов шифров. Другие усовершенствования включают в себя больше зашифрованных элементов рукопожатия (например, теперь зашифрован обмен информацией о сертификате), чтобы уменьшить объем подсказок потенциальному перехватчику трафика, а также улучшения в forward secrecy при использовании определенных режимов обмена ключами, так что связь в любой момент времени должна оставаться безопасной, даже если алгоритмы, используемые для ее шифрования, будут скомпрометированы в будущем».
 

Разработка современных протоколов и DDoS

Как вы, возможно, уже читали, во время разработки протокола и даже после, в рабочей группе IETF TLS возникали серьезные противоречия. Уже теперь очевидно, что отдельным предприятиям (включая финансовые учреждения) придется изменить способ обеспечения безопасности собственной сети для того, чтобы приспособиться к ныне встроенной в протокол perfect forward secrecy.

Причины, по которым это может потребоваться, изложены в документе, написанном Стивом Фентером. В 20-страничной бумаге упоминается несколько примеров, когда предприятие может захотеть выполнить расшифровку out-of-band трафика (что PFS делать не позволяет), в целях мониторинга, соответствия нормативным требованиям или обеспечения защиты от DDoS-атак на прикладном уровне (L7).

 

Хотя мы определенно не готовы рассуждать о нормативных требованиях, наш собственный продукт для нейтрализации прикладных DDoS-атак (включая решение, не требующее раскрытиячувствительной и/или конфиденциальной информации) был создан в 2012 году с учётом PFS, поэтому нашим клиентам и партнёрам никаких изменений в их инфраструктуре после обновления версии TLS на стороне сервера производить не потребовалось.

Также, за прошедшее с момента внедрения время никаких проблем, связанных с транспортным шифрованием, выявлено не было. Официально: TLS 1.3 готов к использованию в продакшене.

Впрочем, есть всё же проблема, связанная с разработкой протоколов следующего поколения. Она заключается в том, что обычно прогресс в развитии протоколов в IETF сильно зависит от результатов научных исследований, а состояние академических исследований в отрасли нейтрализации распределенных атак на отказ в обслуживании — весьма плачевное.

Так, хорошим примером может выступать раздел 4.4 черновика IETF “QUIC Manageability” («Управление QUIC»), являющегося частью будущего набора протоколов QUIC: в нем говорится, что «современные методы обнаружения и нейтрализации [DDoS-атак] обычно включают пассивное измерение с использованием данных о сетевых потоках». 

Последнее, на самом деле, очень редко встречается в реальных корпоративных средах (и лишь отчасти применимо к интернет-провайдерам), и в любом случае вряд ли является «общим случаем» в реальном мире — но постоянно фигурирует в научных публикациях, обычно не подкрепленных тестированием всего спектра потенциальных DDoS-атак, включая атаки прикладного уровня. Последние, в силу хотя бы всемирного развертывания TLS, очевидно никак не могут быть обнаружены пассивным измерением сетевых пакетов и потоков.

Аналогично, мы пока не знаем, как производители оборудования для нейтрализации DDoS будут адаптироваться к реалиям TLS 1.3. Из-за технической сложности поддержки out-of-band протокола, может уйти некоторое время на апгрейд.

Постановка правильных целей для направления научных исследований — серьёзная задача для провайдеров услуг нейтрализации DDoS. Одна из областей, в которой можно начать развитие — исследовательская группа SMART в IRTF, где исследователи могут сотрудничать с отраслью для уточнения собственных знаний в проблемной отрасли и поиска новых направлений исследований. Мы также готовы тепло поприветствовать всех исследователей, если таковые найдутся — с нами можно связаться по вопросам или предложениям, связанным DDoS-исследованиями или с исследовательской группой SMART, по адресу rnd@qrator.net

Ознакомьтесь со всеми функциями
в 7-дневной пробной версии

Наши специалисты готовы оказать вам поддержку

Будьте в курсе наших новостей и продуктов!

Подпишитесь на ежемесячный обзор самых популярных идей Интернета от CURATOR!

E-mail *

Читайте также

Curator
БД ClickHouse в нейтрализации DDoS
Двухуровневая схема фильтрации трафика с машинным обучением На высоком уровне сервис фильтрации Qrator состоит из двух уровней: на первом мы незамедлительно оцениваем, если определенный запрос является злонамеренным с помощью проверок с сохранением состояния и без и, на втором, принимаем решение о том, задержать ли источник в черном списке и на какой срок. Получающийся в итоге черный список может быть представлен в виде уникальной таблицы IP-адресов.
04 марта 2019
Curator
Ускорение SQLAlchemy для архитектурных космонавтов
Это доклад инженера-программиста Алексея Старкова на конференции Moscow Python Conf++ 2018 в Москве. Видео в конце поста. Всем привет! Меня зовут Алексей Старков — это я, в свои лучшие годы, работаю на заводе. Теперь я работаю в Qrator Labs. В основном, всю свою жизнь, я занимался C и C++ — люблю Александреску, «Банду Четырех», принципы SOLID — вот это всё. Что и делает меня архитектурным космонавтом. Последние пару лет пишу на Python, потому что мне это нравится. Собственно, кто такие «архитектурные космонавты»? Первый раз я встретил данный термин у Джоэля Спольски, вы наверное его читали. Он описывает «космонавтов», как людей, которые хотят построить идеальную архитектуру, которые навешивают абстракцию, над абстракцией, над абстракцией, которая становится все более и более общей. В конце концов, эти уровни идут так высоко, что описывают все возможные программы, но не решают никаких практических задач. В этот момент у «космонавта» (это последний раз, когда данный термин окружен кавычками) кончается воздух и он умирает. Я тоже имею тенденции к архитектурной космонавтике, но в этом докладе я расскажу немного о том, как это меня укусило и не позволило построить систему с необходимой производительностью. Главное — как я это поборол. Краткое содержание моего доклада: было / стало.
23 ноября 2018
Curator
ENOG 15: «Почему Интернет до сих пор онлайн?»
Это — одновременно транскрипция и частичный перевод часовой сессии под названием «Почему Интернет до сих пор онлайн?» с пятнадцатой встречи «Евразийской группы сетевых операторов». Qrator Labs благодарит всех участников обсуждения: Алексея Семеняку, RIPE NCC; Игнаса Багдонаса, Equinix; Мартина Дж. Леви, Cloudflare; Александра Азимова, Qrator Labs и модератора Алексея Учакина из команды подкаста LinkmeUp за разрешение опубликовать данный текст. В данном обсуждении участвуют сетевые инженеры-исследователи, поэтому разговор идет в основном о междоменной маршрутизации. Видео в конце публикации. Приятного прочтения. Алексей Учакин : Всем привет, меня зовут Алексей, команда LinkmeUp — первый подкаст для связистов. За меня, на самом деле, коллега из Qrator Labs очень много рассказал о том, как защищаться от спуфинга, но я хотел бы поговорить, на самом деле, более широко. Потому что интернет – это штука безусловно децентрализованная и создавалась, в том числе, для того, чтобы выжить после ядерного взрыва, но, как показывает практика, обладая дешевым оборудованием и не имея прав на настройку BGP, можно это все очень успешно поломать. Поэтому я хотел сегодня вместе с экспертами обсудить, как от этого защищаться, как это мониторить и что со всем этим делать. Сегодня участвуют: Александр Азимов — Qrator Labs, Алекс Семеняка — RIPE NCC, Игнас Багдонас — Equinix и Мартин Дж. Леви — Cloudflare. Собственно, коллеги, первое, с чего хотелось бы начать, первый вопрос: насколько сейчас интернет защищен от того, что условно маленький региональный оператор начнет вдруг анонсировать префиксы условного Google, Яндекс или кого-либо. Есть ли какая-нибудь оценка того, как сейчас с этим дело обстоит?
16 ноября 2018
Ваша подписка успешно активирована
На главную