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