Набор шифров
Набор шифров — это набор алгоритмов, которые помогают защитить сетевое соединение. Пакеты обычно используют Transport Layer Security (TLS) или его устаревший предшественник Secure Socket Layer (SSL). Набор алгоритмов, которые обычно содержат наборы шифров, включает в себя: алгоритм обмена ключами , алгоритм массового шифрования и алгоритм кода аутентификации сообщения (MAC). [1]
Алгоритм обмена ключами используется для обмена ключом между двумя устройствами. Этот ключ используется для шифрования и дешифрования сообщений, передаваемых между двумя компьютерами. Алгоритм массового шифрования используется для шифрования отправляемых данных. Алгоритм MAC обеспечивает проверку целостности данных, чтобы гарантировать, что отправленные данные не изменяются при передаче. Кроме того, наборы шифров могут включать подписи и алгоритм аутентификации, помогающие аутентифицировать сервер и/или клиент.
В целом существуют сотни различных наборов шифров, которые содержат разные комбинации этих алгоритмов. Некоторые наборы шифров обеспечивают более высокий уровень безопасности, чем другие. Но с принятием TLS 1.3 официально поддерживаются и определены только 5 наборов шифров. [2]
Структура и использование концепции набора шифров определены в стандартном документе TLS. [3] TLS 1.2 — наиболее распространенная версия TLS. Новейшая версия TLS (TLS 1.3) включает дополнительные требования к наборам шифров. Наборы шифров, определенные для TLS 1.2, не могут использоваться в TLS 1.3 и наоборот, если иное не указано в их определении.
Справочный список именованных наборов шифров представлен в реестре наборов шифров TLS. [4]
История
[ редактировать ]Использование шифров было частью транзитного протокола Secure Socket Layer (SSL) с момента его создания. На смену SSL в большинстве случаев пришел TLS. Однако название Cipher Suite не использовалось в первоначальном проекте SSL. Вместо этого возможность клиента и сервера выбирать из небольшого набора шифров для защиты своего соединения называлась Cipher-Choice. [5] [6] Только после SSL v3 (последняя версия SSL) название Cipher Suite . использовалось [7] С тех пор каждая версия TLS использовала Cipher Suite для стандартизации. Концепция и цель набора шифров не изменились с момента первого появления этого термина. Он использовался и до сих пор используется как структура, описывающая алгоритмы, поддерживаемые машиной, чтобы две машины могли решить, какие алгоритмы использовать для защиты своего соединения. Что изменилось, так это версии алгоритмов, которые поддерживаются наборами шифров. В каждой версии TLS добавлена поддержка более сильных версий алгоритмов и удалена поддержка версий алгоритмов, которые были определены как небезопасные.
TLS 1.3 знаменует собой изменение в том, как координируются наборы шифров между машинами. Набор шифров, выбранный для использования двумя взаимодействующими машинами, определяется процессом установления связи. В TLS 1.3 были внесены изменения в процесс установления связи, чтобы сократить количество отправляемых сообщений. Это позволяет сократить объем обработки, уменьшить пакетный трафик и повысить эффективность по сравнению с предыдущими версиями TLS.
Схема именования
[ редактировать ]Каждый набор шифров имеет уникальное имя, которое используется для его идентификации и описания его алгоритмического содержания. Каждый сегмент в имени набора шифров обозначает отдельный алгоритм или протокол. Пример имени набора шифров: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Значение этого имени следующее:
- ТЛС
- определяет протокол, для которого предназначен этот набор шифров; обычно это TLS.
- ECDHE
- указывает алгоритм обмена ключами . используемый
- ЮАР
- механизм аутентификации во время рукопожатия.
- АЕС
- сеансовый шифр.
- 128
- размер ключа шифрования сеанса (в битах) для шифрования.
- ГКМ
- тип шифрования (зависимость шифр-блока и дополнительные опции).
- НАПИТОК
- (SHA2)хеш-функция. Для дайджеста 256 и выше. Механизм подписи. Указывает алгоритм аутентификации сообщения , который используется для аутентификации сообщения.
- 256
- Размер дайджеста (в битах).
Полное рукопожатие: координация наборов шифров
[ редактировать ]Чтобы использовать наборы шифров, клиент и сервер должны согласовать конкретный набор шифров, который будет использоваться при обмене сообщениями. И клиент, и сервер должны поддерживать согласованный набор шифров. Если клиент и сервер не согласовали набор шифров, соединение не будет установлено. [8] Этот процесс выбора происходит во время протокола TLS Handshake. TLS 1.3 включает протокол установления связи TLS, который отличается от предыдущей и текущей версии TLS/SSL.
После согласования того, какой набор шифров использовать, сервер и клиент по-прежнему имеют возможность изменять скоординированные шифры с помощью протокола ChangeCipherSpec в текущем или новом рукопожатии.
Чтобы проверить, какие шифры TLS поддерживает сервер, можно использовать сканер SSL/TLS. [1]
Рукопожатие TLS 1,0–1,2
[ редактировать ]
Этот клиент начинает процесс, отправляя на сервер сообщение clientHello , которое включает используемую версию TLS и список наборов шифров в порядке предпочтений клиента. В ответ сервер отправляет сообщение serverHello , которое включает выбранный набор шифров и идентификатор сеанса. Затем сервер отправляет цифровой сертификат для проверки его личности клиенту. При необходимости сервер также может запросить цифровую сертификацию клиента.
Если клиент и сервер не используют предварительно общие ключи , клиент затем отправляет на сервер зашифрованное сообщение, которое позволяет клиенту и серверу вычислить, какой секретный ключ будет использоваться во время обмена.
После успешной проверки аутентификации сервера и, при необходимости, обмена секретным ключом, клиент отправляет готовое сообщение, сигнализирующее о завершении процесса установления связи. После получения этого сообщения сервер отправляет готовое сообщение, подтверждающее завершение рукопожатия. Теперь клиент и сервер договорились, какой набор шифров использовать для связи друг с другом.
Рукопожатие TLS 1.3
[ редактировать ]Если две машины переписываются по TLS 1.3, они координируют, какой набор шифров использовать, используя протокол рукопожатия TLS 1.3. Рукопожатие в TLS 1.3 было сокращено до одного обратного обмена по сравнению с двумя двусторонними проходами, которые требовались в предыдущих версиях TLS/SSL.
Сначала клиент отправляет на сервер сообщение clientHello , которое содержит список поддерживаемых шифров в порядке предпочтений клиента, и делает предположение о том, какой ключевой алгоритм используется, чтобы при необходимости он мог отправить секретный ключ для обмена.
Делая предположение о том, какой ключевой алгоритм используется, он исключает обход туда и обратно. После получения clientHello сервер отправляет serverHello со своим ключом, сертификатом, выбранным набором шифров и готовым сообщением.
сообщение от сервера, После того, как клиент получает готовое оно согласовывается с сервером, какой набор шифров использовать. [9]
Поддерживаемые алгоритмы
[ редактировать ]В TLS 1.0–1.2
[ редактировать ]| Обмен ключами/договор | Аутентификация | Блочные/потоковые шифры | Аутентификация сообщения |
|---|---|---|---|
| ЮАР | ЮАР | RC4 | MD5 на основе хеша |
| Диффи-Хеллман | ДПО | Тройной DES | Хеш-функция SHA (SHA-1 и SHA-2) |
| ECDH | ECDSA | AES (128-бит и 256-бит) | |
| рекомендуемая розничная цена | ИДЕЯ | ||
| ПСК [10] | ПРИНАДЛЕЖАЩИЙ | ||
| Камелия | |||
| ЧаЧа20 |
Дополнительную информацию об алгоритмах, поддерживаемых в TLS 1.0–1.2, см. также: Безопасность транспортного уровня § Приложения и внедрение.
ТЛС 1.3
[ редактировать ]В TLS 1.3 многие устаревшие алгоритмы, которые поддерживались в ранних версиях TLS, были исключены, чтобы сделать протокол более безопасным. [11] Кроме того, все алгоритмы шифрования и аутентификации объединены в алгоритм шифрования аутентифицированного шифрования со связанными данными (AEAD). ) необходимо использовать алгоритм хеширования Кроме того, теперь при получении ключей на основе HMAC ( HKDF . [12] Все шифры, не относящиеся к AEAD, были удалены из-за возможных недостатков или уязвимостей, и шифры должны использовать алгоритм обмена эфемерными ключами, чтобы для каждого обмена генерировались новые пары ключей. [13]
DTLS с наборами шифров
[ редактировать ]Безопасность транспортного уровня дейтаграмм (DTLS) основана на TLS, но специально используется для соединений UDP, а не TCP -соединений. Поскольку DTLS основан на TLS, он может использовать большинство наборов шифров, описанных для TLS. Существуют особые случаи, которые необходимо учитывать при использовании наборов шифров TLS с DTLS. DTLS не поддерживает потоковый шифр RC4, что означает, что шифр TLS, использующий RC4, не может использоваться с DTLS. [14]
Чтобы определить, совместим ли набор шифров TLS с DTLS, просмотр его имени не поможет. Каждый набор шифров TLS по-прежнему будет включать в свое имя пространство идентификатора TLS. например: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 . Вместо этого все реестры параметров TLS теперь включают флаг DTLS-OK , чтобы указать, поддерживает ли набор шифров DTLS. [15]
Уязвимости
[ редактировать ]Набор шифров так же безопасен, как и содержащиеся в нем алгоритмы. Если версия алгоритма шифрования или аутентификации в наборе шифров имеет известные уязвимости, набор шифров и соединение TLS могут быть уязвимыми. Поэтому распространенная атака на TLS и наборы шифров известна как атака на понижение версии . Переход на более раннюю версию TLS происходит, когда современный клиент подключается к устаревшим серверам, использующим более старые версии TLS или SSL.
При инициировании рукопожатия современный клиент предложит протокол самого высокого уровня, который он поддерживает. Если соединение не удалось, оно будет автоматически повторять попытку с использованием более низкого протокола, такого как TLS 1.0 или SSL 3.0, до тех пор, пока рукопожатие с сервером не будет успешным. Цель перехода на более раннюю версию — обеспечить совместимость новых версий TLS со старыми версиями. Однако злоумышленник может воспользоваться этой функцией и сделать так, чтобы клиент автоматически перешел на версию TLS или SSL, которая поддерживает наборы шифров с алгоритмами, известными слабой безопасностью и уязвимостями. [16] Это привело к таким атакам, как POODLE .
Один из способов избежать этого недостатка безопасности — отключить возможность перехода сервера или клиента на SSL 3.0. Недостаток этого исправления заключается в том, что новое оборудование не может получить доступ к некоторому устаревшему оборудованию. Если для устаревшего оборудования необходима поддержка SSL 3.0, существует утвержденный набор шифров TLS_FALLBACK_SCSV, который проверяет, что переход на более раннюю версию не инициируется злонамеренными намерениями. [17]
Наборы шифров для устройств с ограниченными возможностями
[ редактировать ]Алгоритмы шифрования, обмена ключами и аутентификации обычно требуют большого объема вычислительной мощности и памяти. Чтобы обеспечить безопасность ограниченных устройств с ограниченной вычислительной мощностью, памятью и временем автономной работы, например тех, которые обеспечивают работу Интернета вещей, существуют специально выбранные наборы шифров. Два примера включают в себя:
- TLS_PSK_WITH_AES_128_CCM_8 ( предварительный общий ключ ) [18]
- TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 ( необработанный открытый ключ )
Каждый из этих наборов шифров был реализован для работы на устройствах с ограничениями по вычислительной мощности и памяти. Оба они реализованы в проекте с открытым исходным кодом TinyDTLS . Причина, по которой они могут работать на этих ограниченных устройствах, заключается в том, что их можно реализовать легковесным способом. Реализации набора шифров с предварительным общим ключом использовали только 1889 байт ОЗУ и 38266 байт флэш-ПЗУ, что очень ресурсоемко по сравнению с большинством алгоритмов шифрования и безопасности. [19] Такое низкое использование памяти связано с тем, что эти комплекты шифров используют проверенные эффективные алгоритмы, которые безопасны, но, возможно, не так безопасны, как алгоритмы, требующие большего количества ресурсов; exp: использование 128-битного шифрования вместо 256-битного шифрования. Кроме того, они используют предварительно общий ключ или необработанный открытый ключ, который требует меньше места в памяти и вычислительной мощности по сравнению с использованием традиционной инфраструктуры открытых ключей (PKIX). [20]
Ссылки по программированию
[ редактировать ]В программировании набор шифров упоминается как во множественном, так и в немножественном числе. У каждого из них разные определения:
- CipherSuite cipher_suites
- список опций шифрования, поддерживаемых клиентом. [21] Пример того, как cipher_suites в процессе установления связи: обычно используется
struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ClientHello;- CipherSuite cipher_suite
- клиента набор шифров, выбранный сервером из cipher_suites . [22] Пример того, как cipher_suite обычно используется в процессе установления связи:
struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ServerHello;См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ «Наборы шифров в TLS/SSL (Schannel SSP) (Windows)» . docs.microsoft.com . Проверено 2 июля 2018 г.
- ^ «Настройка списка наборов шифров с использованием TLS v1.3» . www.microfocus.com . Проверено 30 ноября 2023 г.
- ^ RFC 5246
- ^ Реестр набора шифров TLS
- ^ «Протокол SSL 0.2» . www-archive.mozilla.org . Проверено 7 декабря 2017 г.
- ^ "draft-hickman-netscape-ssl-00" . www.tools.ietf.org . Проверено 7 декабря 2017 г.
- ^ «Спецификация SSL 3.0» . www.freesoft.org . Проверено 7 декабря 2017 г.
- ^ Вильянуэва, Джон Карл. «Введение в наборы шифров» . Проверено 25 октября 2017 г.
- ^ Вальсорда, Филиппо (23 сентября 2016 г.). «Обзор TLS 1.3 и вопросы и ответы» . Блог Cloudflare . Проверено 1 сентября 2020 г.
- ^ ECDHE_PSK с наборами шифров AES-GCM и AES-CCM для TLS 1.2 и DTLS 1.2 . дои : 10.17487/RFC8442 . RFC 8442 .
- ^ «Поддержка протокола TLS 1.3 | Встроенная библиотека SSL/TLS wolfSSL» . волкSSL . Проверено 26 октября 2017 г.
- ^ Э. Рескорла (4 ноября 2016 г.). «Протокол безопасности транспортного уровня (TLS) версии 1.3» . Проверено 11 ноября 2016 г.
- ^ Салливан, Ник (11 августа 2018 г.). «Подробный обзор RFC 8446 (он же TLS 1.3)» . Блог Cloudflare . Проверено 11 августа 2020 г. .
- ^ Н., Модадугу; Э., Рескорла. «Безопасность транспортного уровня дейтаграмм» . www.tools.ietf.org . Проверено 25 октября 2017 г.
- ^ Эрик, Рескорла; Нагендра, Модадугу. «Безопасность транспортного уровня дейтаграмм, версия 1.2» . www.tools.ietf.org . Проверено 25 октября 2017 г.
- ^ Бодо, Мёллер; Адам, Лэнгли. «Значение резервного набора шифров сигнализации TLS (SCSV) для предотвращения атак с понижением версии протокола» . www.tools.ietf.org . Проверено 25 октября 2017 г.
- ^ Бодо, Мёллер; Адам, Лэнгли. «Значение резервного набора шифров сигнализации TLS (SCSV) для предотвращения атак с понижением версии протокола» . www.tools.ietf.org . Проверено 25 октября 2017 г.
- ^ Дэниел, Бейли; Дэвид, МакГрю. «Наборы шифров AES-CCM для безопасности транспортного уровня (TLS)» . www.tools.ietf.org . Проверено 26 октября 2017 г.
- ^ Перельмен, Владислав (29 июня 2012 г.). «Безопасность в беспроводных сенсорных сетях с поддержкой IPv6: реализация TLS/DTLS для операционной системы Contiki» (PDF) : 38. Архивировано из оригинала (PDF) 29 августа 2017 г. . Проверено 7 декабря 2017 г.
{{cite journal}}: Для цитирования журнала требуется|journal=( помощь ) - ^ Сэмюэл, Вейлер; Джон, Гилмор; Ханнес, Чофениг; Теро, Кивинен; Пол, Воутерс. «Использование необработанных открытых ключей в безопасности транспортного уровня (TLS) и безопасности транспортного уровня дейтаграмм (DTLS)» . www.tools.ietf.org . Проверено 7 декабря 2017 г.
- ^ RFC 5246 , стр. 41
- ^ RFC 5246 , стр. 42–43, 64.