Введение
Мировая статистика показывает, что доля шифрованного трафика сети Интернет неуклонно растет ( еще в июне 2017 года превысила 50%) и эта тенденция будет сохраняться. Для обеспечения конфиденциальности и целостности данных во всемирной сети используются протоколы SSL/TLS. Одним из самых распространённых применений TLS является HTTPS, который вытесняет свой незащищенный аналог HTTP.
По причине выхода новой версии протокола становится актуальной проблема ее досконального изучения для дальнейшего анализа данных, передаваемых по TLS 1.3.
История SSL/TLS
Протокол TLS (Transport Layer Security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном компанией Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL реализован над TCP, позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. При корректной реализации SSL/TLSсторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.
Первая выпущенная версия протокола имела название SSL 2.0, но была довольно быстро заменена на SSL 3.0 из-за обнаруженных уязвимостей. Как уже упоминалось, SSL был разработан Netscape, так что в январе 1999 года IETF (Internet Engineering Task Force) открыто стандартизирует его под именем TLS 1.0. Затем в апреле 2006 года была опубликована версия TLS 1.1, которая расширяла первоначальные возможности протокола и закрывала известные уязвимости. Актуальная версия протокола на данный момент – TLS 1.2, выпущенная в августе 2008 года.
Как уже говорилось, TLS был разработан для работы над TCP, однако для работы с протоколами дейтаграмм, такими как UDP, была разработана специальная версия TLS, получившая название DTLS (Datagram Transport Layer Security).
Записи TLS
Представлены основные выдержки, касающиеся протокола TLS.
Протокол TLS состоит из двух уровней.
-Первый уровень передает данные в виде записей (records). Это нижний транспортный уровень TLS. Если рассматривать сеанс TLS на уровне сокета (TCP), то каждая передаваемая запись представляет собой блок, состоящий из короткого заголовка и данных.
-На втором уровне происходит передача сообщений (подробно будет рассмотрено в пункте 1.1.3). На рисунке 1.1 представлена модель, демонстрирующая место TLS в стеке протоколов.
Рисунок 1.1 – Место протоколов TLS (SSL) в стеке протоколов
В TLS используется сетевой порядок байтов (старший байт идёт первым, слева направо). Заголовок записи имеет длину 5 байтов, и формат, представленный на рисунке 1.2.
Рисунок 1.2 – Формат заголовка записи
Тип - это тип записи. Определено четыре типа: 20 (0x14) - сообщение Change Cipher Spec (CCS); 21 (0x15) - сообщение Alert (предупреждения); 22 (0x16) - сообщение Handshake (установление соединения); 23 (0x17) - Application Data (данные приложения/полезная нагрузка). При передаче информации, основные преобразования с шифрами и кодами аутентификации происходят в блоке данных. Прочие записи обычно передаются в открытом виде, но могут быть и зашифрованы, в зависимости от типа записи и текущего состояния TLS-соединения;
Версия протокола - это версия, записанная в двух байтах: 03 00 - это SSLv3, 03 01 - TLS 1.0; 03 02 - TLS 1.1; 03 03 - TLS 1.2;
Длина данных - количество байтов, содержащих данные (сами байты следуют после заголовка). Протокол предусматривает возможность передачи пустых блоков данных. Заголовок всегда передаётся в открытом виде.
За заголовком должно следовать определённое число байтов (>=0), которые представляют собой содержимое данной записи. Максимальное значение - 18432 байта. 18432 = 16384 + 2048. То есть, 16 килобайт + два раза по килобайту. Версия записи, описанная в спецификации, предполагает блок данных в 16 килобайт. Но такой размер относится только к записям, содержащим открытый текст (TLS Plaintext). Например, к сообщениям, управляющим установлением соединения.
Для защищённых записей ситуация меняется. Во-первых, спецификацией предписано, что в TLS все данные защищённой записи должны сжиматься. Однако на практике по умолчанию установлен алгоритм null, который сжатие не производит. Некоторое время можно было встретить алгоритм DEFLATE (сейчас он относится к нерекомендованным из-за обнаруженных уязвимостей). Тем не менее, реально сжатые данные могут оказаться длиннее, из-за особенностей алгоритма. TLS отводит на такое увеличение длины 1024 байта (хорошо реализованные алгоритмы используют значительно меньше). Во-вторых, для проверки целостности зашифрованных данных к ним приписывается код аутентификации сообщения (MAC) и дополнительная информация (векторы инициализации шифров) - на это отводится 1024 байта. В реальности, длина записи TLS заметно меньше 16Kбайт.
Код аутентификации - важнейший элемент защиты информации в TLS. Обычно используется HMAC - версия с той или иной хеш-функцией. Типичный выбор: SHA-1 или SHA-256. Код аутентификации приписывается к блоку данных. Один из архитектурных дефектов всех используемых сейчас версий TLS состоит в том, что спецификация предписывает сперва вычислять MAC, а потом шифровать сообщение. То есть, вычисленный код аутентификации присоединяется к открытому тексту сообщения, а потом все вместе шифруется. При этом принимающая сторона должна сперва расшифровать полученные данные, а потом - проверить MAC. Такой метод приводит к возникновению "криптографических оракулов", на использовании которых основано несколько эффективных атак против TLS. Современный подход: код аутентификации добавляется после шифрования открытого текста, то есть MAC вычисляется для уже зашифрованного сообщения и прикрепляется к нему. Для внедрения современного подхода в спецификацию добавлено специальное расширение, позволяющее клиенту и серверу договориться о том, в какой последовательности они генерируют коды аутентификации -RFC 7366. Более того, современные шифры в TLS используются в режиме аутентифицированного шифрования (AEAD), который не нуждается в отдельном MAC, так как целостность данных гарантирует сам алгоритм шифрования. Наиболее предпочтительным вариантом является AES в режиме GCM: поддерживается всем современным ПО, в 2016 году получил очень большое распространение.
Используемые криптосистемы в TLS объединяются в типовые шифронаборы (Cipher Suites). Чтобы начать обмен информацией по защищённому каналу, клиент и сервер должны согласовать используемый шифронабор. Параметры шифров и обмена сопутствующей информацией должны быть совместимы между собой. Согласование проводится на этапе установления соединения (Handshake).
В шифронабор входят:
1...Криптосистема, используемая для аутентификации сервера и сеансового секрета.
2...Шифр, который послужит для защиты передаваемых данных.
3...Хеш-функция, являющаяся основой для HMAC.
Шифронаборы имеют важнейшее значение для безопасности TLS. Выбор нестойкой комбинации означает, что достаточной защиты конкретная реализация TLS не обеспечивает. Реестр IANA в настоящий момент содержит свыше 300 шифронаборов. Наличие шифронабора в котором означает, что этому шифронабору присвоен индекс и обозначение. Данный реестр не является показателем того какие шифры и криптосистемы рекомендованы или не рекомендованы для использования.
В 2017 году наиболее предпочтительным вариантом считается TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA256: то есть, генерация общего секрета проводится по протоколу Диффи-Хеллмана на эллиптических кривых, для аутентификации данных на этапе установления соединения используется криптосистема электронной подписи ECDSA (тоже работающая на эллиптических кривых), полезная нагрузка шифруется AES со 256-битным ключом в режиме GCM, а в качестве хеш-функции служит SHA-256 (используется при генерации сеансовых ключей).
В дальнейшем планируется написание подробных статей о процессе установления соединения (Handshake) по протоколам TLS версий 1.2 и 1.3.
Мировая статистика показывает, что доля шифрованного трафика сети Интернет неуклонно растет ( еще в июне 2017 года превысила 50%) и эта тенденция будет сохраняться. Для обеспечения конфиденциальности и целостности данных во всемирной сети используются протоколы SSL/TLS. Одним из самых распространённых применений TLS является HTTPS, который вытесняет свой незащищенный аналог HTTP.
По причине выхода новой версии протокола становится актуальной проблема ее досконального изучения для дальнейшего анализа данных, передаваемых по TLS 1.3.
История SSL/TLS
Протокол TLS (Transport Layer Security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном компанией Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL реализован над TCP, позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. При корректной реализации SSL/TLSсторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.
Первая выпущенная версия протокола имела название SSL 2.0, но была довольно быстро заменена на SSL 3.0 из-за обнаруженных уязвимостей. Как уже упоминалось, SSL был разработан Netscape, так что в январе 1999 года IETF (Internet Engineering Task Force) открыто стандартизирует его под именем TLS 1.0. Затем в апреле 2006 года была опубликована версия TLS 1.1, которая расширяла первоначальные возможности протокола и закрывала известные уязвимости. Актуальная версия протокола на данный момент – TLS 1.2, выпущенная в августе 2008 года.
Как уже говорилось, TLS был разработан для работы над TCP, однако для работы с протоколами дейтаграмм, такими как UDP, была разработана специальная версия TLS, получившая название DTLS (Datagram Transport Layer Security).
Записи TLS
Представлены основные выдержки, касающиеся протокола TLS.
Протокол TLS состоит из двух уровней.
-Первый уровень передает данные в виде записей (records). Это нижний транспортный уровень TLS. Если рассматривать сеанс TLS на уровне сокета (TCP), то каждая передаваемая запись представляет собой блок, состоящий из короткого заголовка и данных.
-На втором уровне происходит передача сообщений (подробно будет рассмотрено в пункте 1.1.3). На рисунке 1.1 представлена модель, демонстрирующая место TLS в стеке протоколов.
Рисунок 1.1 – Место протоколов TLS (SSL) в стеке протоколов
В TLS используется сетевой порядок байтов (старший байт идёт первым, слева направо). Заголовок записи имеет длину 5 байтов, и формат, представленный на рисунке 1.2.
Рисунок 1.2 – Формат заголовка записи
Версия протокола - это версия, записанная в двух байтах: 03 00 - это SSLv3, 03 01 - TLS 1.0; 03 02 - TLS 1.1; 03 03 - TLS 1.2;
Длина данных - количество байтов, содержащих данные (сами байты следуют после заголовка). Протокол предусматривает возможность передачи пустых блоков данных. Заголовок всегда передаётся в открытом виде.
За заголовком должно следовать определённое число байтов (>=0), которые представляют собой содержимое данной записи. Максимальное значение - 18432 байта. 18432 = 16384 + 2048. То есть, 16 килобайт + два раза по килобайту. Версия записи, описанная в спецификации, предполагает блок данных в 16 килобайт. Но такой размер относится только к записям, содержащим открытый текст (TLS Plaintext). Например, к сообщениям, управляющим установлением соединения.
Для защищённых записей ситуация меняется. Во-первых, спецификацией предписано, что в TLS все данные защищённой записи должны сжиматься. Однако на практике по умолчанию установлен алгоритм null, который сжатие не производит. Некоторое время можно было встретить алгоритм DEFLATE (сейчас он относится к нерекомендованным из-за обнаруженных уязвимостей). Тем не менее, реально сжатые данные могут оказаться длиннее, из-за особенностей алгоритма. TLS отводит на такое увеличение длины 1024 байта (хорошо реализованные алгоритмы используют значительно меньше). Во-вторых, для проверки целостности зашифрованных данных к ним приписывается код аутентификации сообщения (MAC) и дополнительная информация (векторы инициализации шифров) - на это отводится 1024 байта. В реальности, длина записи TLS заметно меньше 16Kбайт.
Код аутентификации - важнейший элемент защиты информации в TLS. Обычно используется HMAC - версия с той или иной хеш-функцией. Типичный выбор: SHA-1 или SHA-256. Код аутентификации приписывается к блоку данных. Один из архитектурных дефектов всех используемых сейчас версий TLS состоит в том, что спецификация предписывает сперва вычислять MAC, а потом шифровать сообщение. То есть, вычисленный код аутентификации присоединяется к открытому тексту сообщения, а потом все вместе шифруется. При этом принимающая сторона должна сперва расшифровать полученные данные, а потом - проверить MAC. Такой метод приводит к возникновению "криптографических оракулов", на использовании которых основано несколько эффективных атак против TLS. Современный подход: код аутентификации добавляется после шифрования открытого текста, то есть MAC вычисляется для уже зашифрованного сообщения и прикрепляется к нему. Для внедрения современного подхода в спецификацию добавлено специальное расширение, позволяющее клиенту и серверу договориться о том, в какой последовательности они генерируют коды аутентификации -RFC 7366. Более того, современные шифры в TLS используются в режиме аутентифицированного шифрования (AEAD), который не нуждается в отдельном MAC, так как целостность данных гарантирует сам алгоритм шифрования. Наиболее предпочтительным вариантом является AES в режиме GCM: поддерживается всем современным ПО, в 2016 году получил очень большое распространение.
Используемые криптосистемы в TLS объединяются в типовые шифронаборы (Cipher Suites). Чтобы начать обмен информацией по защищённому каналу, клиент и сервер должны согласовать используемый шифронабор. Параметры шифров и обмена сопутствующей информацией должны быть совместимы между собой. Согласование проводится на этапе установления соединения (Handshake).
В шифронабор входят:
1...Криптосистема, используемая для аутентификации сервера и сеансового секрета.
2...Шифр, который послужит для защиты передаваемых данных.
3...Хеш-функция, являющаяся основой для HMAC.
Шифронаборы имеют важнейшее значение для безопасности TLS. Выбор нестойкой комбинации означает, что достаточной защиты конкретная реализация TLS не обеспечивает. Реестр IANA в настоящий момент содержит свыше 300 шифронаборов. Наличие шифронабора в котором означает, что этому шифронабору присвоен индекс и обозначение. Данный реестр не является показателем того какие шифры и криптосистемы рекомендованы или не рекомендованы для использования.
В 2017 году наиболее предпочтительным вариантом считается TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA256: то есть, генерация общего секрета проводится по протоколу Диффи-Хеллмана на эллиптических кривых, для аутентификации данных на этапе установления соединения используется криптосистема электронной подписи ECDSA (тоже работающая на эллиптических кривых), полезная нагрузка шифруется AES со 256-битным ключом в режиме GCM, а в качестве хеш-функции служит SHA-256 (используется при генерации сеансовых ключей).
В дальнейшем планируется написание подробных статей о процессе установления соединения (Handshake) по протоколам TLS версий 1.2 и 1.3.
