3 неизбежно. В начале года, в отчете о проблемах и доступности интернета за 2018-2019 мы уже писали, что распространение TLS 1. 3 протокола Transport Layer Security и, после сбора и анализа данных, наконец, готовы рассказать об особенностях этого перехода. Некоторое время назад мы сами развернули версию 1.
3 должен предоставить фундамент более безопасного и эффективного Интернета на следующие 20 лет». Председатели рабочей группы IETF TLS пишут:
«Вкратце, TLS 1.
3 заняла долгих 10 лет. Разработка TLS 1. За это время потребовалось написать 28 последовательных версий черновика для того, чтобы в конечном счёте в 2019 году свет увидел сбалансированный и удобный в развертывании протокол. Мы в Qrator Labs, вместе со всей остальной отраслью, внимательно следили за процессом создания протокола от первоначального проекта. 3 рынком уже очевидна: внедрение проверенного и надежного протокола безопасности отвечает требованиям времени. Активная поддержка TLS 1.
3) в интервью The Register:
По словам Эрика Рескорлы (технического директора Firefox и единственного автора TLS 1.
2, использующая те же ключи и сертификаты, поэтому клиент и сервер могут автоматически общаться по TLS 1. «Это полная замена TLS 1. «Уже есть хорошая поддержка на уровне библиотек, а Chrome и Firefox по умолчанию включают TLS 1. 3, если оба его поддерживают», — сказал он. 3».
Параллельно в рабочей группе IETF TLS заканчивается подготовка RFC, объявляющего старые версии TLS (за исключением только TLS 1.2) устаревшими и непригодными для использования. Вероятнее всего, финальный RFC увидит свет до конца лета. Это ещё один сигнал IT-индустрии: обновление протоколов шифрования не стоит откладывать.
3 доступен на Github для всех, кто ищет наиболее подходящую библиотеку: https://github.com/tlswg/tls13-spec/wiki/Implementations. Список текущих реализаций TLS 1. Понимание того, насколько фундаментальным стало шифрование в современном мире, распространилось достаточно широко. Очевидно, что принятие и поддержка обновленного протокола будет — и уже идет — быстрыми шагами.
Что изменилось по-сравнению с TLS 1.2?
Из заметки Internet Society:
«Как TLS 1.3 делает мир лучше?
3 включает определённые технические преимущества — такие, как упрощенный процесс рукопожатия (handshake) для установления безопасного соединения — а также позволяет клиентам быстрее возобновлять сессии с серверами. TLS 1. Эти меры призваны уменьшить задержку на установку соединения и количество неудачных соединений на слабых каналах, которые часто используются в качестве оправдания для предоставления только нешифрованных HTTP-соединений.
Другие усовершенствования включают в себя больше зашифрованных элементов рукопожатия (например, теперь зашифрован обмен информацией о сертификате), чтобы уменьшить объем подсказок потенциальному перехватчику трафика, а также улучшения в forward secrecy при использовании определенных режимов обмена ключами, так что связь в любой момент времени должна оставаться безопасной, даже если алгоритмы, используемые для ее шифрования, будут скомпрометированы в будущем». Не менее важно и то, что устранена поддержка нескольких устаревших и небезопасных алгоритмов шифрования и хеширования, которые все еще разрешено (хотя и не рекомендуется) использовать с более ранними версиями TLS, включая SHA-1, MD5, DES, 3DES и AES-CBC, одновременно добавляя поддержку новых наборов шифров.
Разработка современных протоколов и DDoS
Как вы, возможно, уже читали, во время разработки протокола и даже после, в рабочей группе IETF TLS возникали серьезные противоречия. Уже теперь очевидно, что отдельным предприятиям (включая финансовые учреждения) придется изменить способ обеспечения безопасности собственной сети для того, чтобы приспособиться к ныне встроенной в протокол perfect forward secrecy.
В 20-страничной бумаге упоминается несколько примеров, когда предприятие может захотеть выполнить расшифровку out-of-band трафика (что PFS делать не позволяет), в целях мониторинга, соответствия нормативным требованиям или обеспечения защиты от DDoS-атак на прикладном уровне (L7). Причины, по которым это может потребоваться, изложены в документе, написанном Стивом Фентером.
Хотя мы определенно не готовы рассуждать о нормативных требованиях, наш собственный продукт для нейтрализации прикладных DDoS-атак (включая решение, не требующее раскрытия чувствительной и/или конфиденциальной информации) был создан в 2012 году с учётом PFS, поэтому нашим клиентам и партнёрам никаких изменений в их инфраструктуре после обновления версии TLS на стороне сервера производить не потребовалось.
Официально: TLS 1. Также, за прошедшее с момента внедрения время никаких проблем, связанных с транспортным шифрованием, выявлено не было. 3 готов к использованию в продакшене.
Она заключается в том, что обычно прогресс в развитии протоколов в IETF сильно зависит от результатов научных исследований, а состояние академических исследований в отрасли нейтрализации распределенных атак на отказ в обслуживании — весьма плачевное. Впрочем, есть всё же проблема, связанная с разработкой протоколов следующего поколения.
4 черновика IETF “QUIC Manageability” («Управление QUIC»), являющегося частью будущего набора протоколов QUIC: в нем говорится, что «современные методы обнаружения и нейтрализации [DDoS-атак] обычно включают пассивное измерение с использованием данных о сетевых потоках». Так, хорошим примером может выступать раздел 4.
Последние, в силу хотя бы всемирного развертывания TLS, очевидно никак не могут быть обнаружены пассивным измерением сетевых пакетов и потоков. Последнее, на самом деле, очень редко встречается в реальных корпоративных средах (и лишь отчасти применимо к интернет-провайдерам), и в любом случае вряд ли является «общим случаем» в реальном мире — но постоянно фигурирует в научных публикациях, обычно не подкрепленных тестированием всего спектра потенциальных DDoS-атак, включая атаки прикладного уровня.
3. Аналогично, мы пока не знаем, как производители оборудования для нейтрализации DDoS будут адаптироваться к реалиям TLS 1. Из-за технической сложности поддержки out-of-band протокола, может уйти некоторое время на апгрейд.
Одна из областей, в которой можно начать развитие — исследовательская группа SMART в IRTF, где исследователи могут сотрудничать с отраслью для уточнения собственных знаний в проблемной отрасли и поиска новых направлений исследований. Постановка правильных целей для направления научных исследований — серьёзная задача для провайдеров услуг нейтрализации DDoS. Мы также готовы тепло поприветствовать всех исследователей, если таковые найдутся — с нами можно связаться по вопросам или предложениям, связанным DDoS-исследованиями или с исследовательской группой SMART, по адресу rnd@qrator.net
