Набор шифров - Cipher suite

А набор шифров представляет собой набор алгоритмов, которые помогают защитить сетевое соединение, использующее Безопасность транспортного уровня (TLS) или его устаревший предшественник Secure Socket Layer (SSL). Набор алгоритмов, которые обычно содержат комплекты шифров, включает: алгоритм обмена ключами, а алгоритм массового шифрования, а код аутентификации сообщения (MAC) алгоритм.[1]

В алгоритм обмена ключами используется для обмена ключом между двумя устройствами. Этот ключ используется для зашифровать и расшифровать сообщения, отправляемые между двумя машинами. В алгоритм массового шифрования используется для шифрования отправляемых данных. Алгоритм MAC обеспечивает проверку целостности данных, чтобы гарантировать, что отправленные данные не изменяются при передаче. Кроме того, комплекты шифров могут включать в себя подписи и алгоритм аутентификации, помогающие аутентифицировать сервер и / или клиента.

В целом, существуют сотни различных наборов шифров, которые содержат различные комбинации этих алгоритмов. Некоторые наборы шифров предлагают лучшую безопасность, чем другие.

Структура и использование концепции набора шифров определены в стандартном документе TLS.[2] TLS 1.2 является наиболее распространенной версией TLS. Следующая версия TLS (TLS 1.3) включает дополнительные требования к комплектам шифров. TLS 1.3 был стандартизирован только недавно и пока не получил широкого распространения. Наборы шифров, определенные для TLS 1.2, нельзя использовать в TLS 1.3, и наоборот, если иное не указано в их определении.

Справочный список именованных наборов шифров предоставляется в реестре TLS Cipher Suite.[3]

История

Использование шифры был частью Уровень защищенных сокетов (SSL) транзитный протокол с момента его создания. SSL был заменен TLS для большинства применений. Однако имя Cipher Suite не использовался в исходном проекте SSL. Вместо этого была названа возможность для клиента и сервера выбирать из небольшого набора шифров для защиты своего соединения. Cipher-Choice.[4][5] Только после SSL v3 (последней версии SSL) имя Cipher Suite использовался.[6] Каждая версия TLS с тех пор использовала Cipher Suite в его стандартизации. Концепция и цель Cipher Suite не изменился с момента появления этого термина. Он имеет и до сих пор используется в качестве структуры, описывающей алгоритмы, которые поддерживает машина, чтобы две машины могли решить, какие алгоритмы использовать для защиты своего соединения. Что изменилось, так это версии алгоритмов, которые поддерживаются в наборах шифров. В каждой версии TLS добавлена ​​поддержка более сильных версий алгоритмов и удалена поддержка версий алгоритмов, которые были определены как небезопасные.

TLS 1.3 знаменует собой изменение способа координации наборов шифров между машинами. Набор шифров, выбранный для использования двумя взаимодействующими машинами, определяется процессом установления связи. В TLS 1.3 были внесены изменения в процесс рукопожатия, чтобы сократить количество сообщений, которые необходимо отправить. Это позволяет уменьшить объем обработки, трафика пакетов и повысить эффективность по сравнению с предыдущими версиями TLS.

Схема именования

Каждый набор шифров имеет уникальное имя, которое используется для его идентификации и описания алгоритмического содержания. Каждый сегмент в имени набора шифров обозначает отдельный алгоритм или протокол. Пример названия набора шифров: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Значение этого имени таково:

  • TLS определяет протокол, для которого предназначен этот набор шифров; Обычно это TLS.
  • ECDHE_RSA указывает на алгоритм обмена ключами быть использованным. Алгоритм обмена ключами используется для определения того, будут ли и как клиент и сервер аутентифицированы во время рукопожатия.
  • AES_128_GCM указывает на блочный шифр используется для шифрования потока сообщений вместе с режимом работы блочного шифрования.
  • SHA256 указывает на алгоритм аутентификации сообщения который используется для аутентификации сообщения.

Полное рукопожатие: координация наборов шифров

Чтобы использовать наборы шифров, клиент и сервер должны согласовать конкретный набор шифров, который будет использоваться при обмене сообщениями. И клиент, и сервер должны поддерживать согласованный набор шифров. Если клиент и сервер не согласны с набором шифров, соединение не будет установлено.[7] Этот процесс выбора происходит во время протокола установления связи TLS. TLS 1.3 включает протокол установления связи TLS, который отличается от прошлой и текущей версии TLS / SSL.

После согласования того, какой набор шифров использовать, сервер и клиент по-прежнему имеют возможность изменять согласованные шифры с помощью ChangeCipherSpec протокол в текущем или новом рукопожатии.

Чтобы проверить, какие шифры TLS поддерживает сервер, можно использовать сканер SSL / TLS.[1]

Рукопожатие TLS 1.0–1.2

Визуальное представление о том, как клиент и сервер, работающие на TLS 1.2, координируют, какой набор шифров использовать

Этот клиент запускает процесс, отправляя клиент привет сообщение серверу, которое включает версию используемого TLS и список наборов шифров в порядке предпочтений клиента. В ответ сервер отправляет серверПривет сообщение который включает выбранный набор шифров и идентификатор сеанса. Затем сервер отправляет клиенту цифровой сертификат для подтверждения своей личности. При необходимости сервер также может запросить цифровую сертификацию клиента.

Если клиент и сервер не используют предварительные общие ключи, клиент затем отправляет зашифрованное сообщение на сервер, что позволяет клиенту и серверу вычислить, какой секретный ключ будет использоваться во время обмена.

После успешной проверки аутентификации сервера и, при необходимости, обмена секретным ключом, клиент отправляет законченный сообщение, чтобы сигнализировать, что это сделано с процессом рукопожатия. После получения этого сообщения сервер отправляет законченный сообщение, подтверждающее, что рукопожатие завершено. Теперь клиент и сервер согласовали, какой набор шифров использовать для связи друг с другом.

Визуальное представление того, как клиент и сервер, работающие на TLS 1.3, координируют, какой набор шифров использовать

Рукопожатие TLS 1.3

Если две машины соответствуют TLS 1.3, они координируют, какой набор шифров использовать, используя протокол установления связи TLS 1.3. Рукопожатие в TLS 1.3 было сокращено до одного кругового обхода по сравнению с двумя круглые поездки требуется в предыдущих версиях TLS / SSL.

Сначала клиент отправляет клиент привет сообщение на сервер, которое содержит список поддерживаемых шифров в порядке предпочтений клиента и делает предположение о том, какой алгоритм ключа используется, чтобы он мог отправить секретный ключ для совместного использования в случае необходимости.

Догадываясь о том, какой ключевой алгоритм используется, он исключает обход. После получения клиент привет, сервер отправляет сервер привет с его ключом, сертификатом, выбранным набором шифров и законченный сообщение.

После того, как клиент получит законченный сообщение теперь согласовано с сервером, на котором нужно использовать набор шифров.[8]

Поддерживаемые алгоритмы

В TLS 1.0–1.2

Алгоритмы, поддерживаемые в наборах шифров TLS 1.0–1.2
Обмен ключами / соглашениеАутентификацияБлочные / потоковые шифрыАутентификация сообщения
ЮАРЮАРRC4MD5 на основе хеша
Диффи – ХеллманаDSAТройной DESХэш-функция SHA
ECDHECDSAAES
SRPИДЕЯ
PSKDES
Камелия
ChaCha20

Для получения дополнительной информации об алгоритмах, поддерживаемых TLS 1.0–1.2, см. Также: Безопасность транспортного уровня § Приложения и внедрение

TLS 1.3

В TLS 1.3 многие устаревшие алгоритмы, которые поддерживались в ранних версиях TLS, были исключены, чтобы сделать протокол более безопасным.[9] Кроме того, все алгоритмы шифрования и аутентификации объединены в аутентифицированное шифрование со связанными данными (AEAD) алгоритм шифрования. Кроме того, теперь должен использоваться алгоритм хеширования при выводе ключей на основе HMAC (HKDF ).[10] Все шифры, не относящиеся к AEAD, были удалены из-за возможных слабых мест или уязвимостей, и шифры должны использовать алгоритм обмена эфемерными ключами, чтобы новые пары ключей генерировались для каждого обмена.[11]

DTLS с наборами шифров

Безопасность на транспортном уровне дейтаграмм (DTLS) основан на TLS, но специально используется для UDP связи вместо TCP соединения. Поскольку DTLS основан на TLS, он может использовать большинство наборов шифров, описанных для TLS. Есть особые случаи, которые необходимо учитывать при использовании наборов шифров TLS с DTLS. DTLS не поддерживает потоковый шифр RC4, что означает, что никакой шифр TLS, использующий RC4, не может использоваться с DTLS.[12]

Чтобы определить, совместим ли набор шифров TLS с DTLS, просмотр его имени не поможет. Каждый набор шифров TLS по-прежнему будет включать в себя пространство идентификаторов TLS в своем имени. например.: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Вместо этого все реестры параметров TLS теперь включают флаг ДТЛС-ОК чтобы сигнализировать, поддерживает ли набор шифров DTLS.[13]

Уязвимости

Набор шифров так же безопасен, как и содержащиеся в нем алгоритмы. Если версия алгоритма шифрования или аутентификации в наборе шифров имеет известные уязвимости, набор шифров и соединение TLS становятся уязвимыми. Поэтому обычная атака на TLS и наборы шифров известна как атака на понижение версии. Переход на более раннюю версию TLS происходит, когда современный клиент подключается к устаревшим серверам, которые используют более старые версии TLS или SSL.

При инициировании рукопожатия современный клиент предложит самый высокий протокол, который он поддерживает. Если соединение не удается, оно автоматически повторяет попытку снова с более низким протоколом, таким как TLS 1.0 или SSL 3.0, до тех пор, пока подтверждение связи с сервером не будет успешным. Целью перехода на более раннюю версию является обеспечение совместимости новых версий TLS со старыми версиями. Однако злоумышленник может воспользоваться этой функцией и сделать так, чтобы клиент автоматически переходил на версию TLS или SSL, которая поддерживает наборы шифров с алгоритмами, которые известны слабой безопасностью и уязвимостями.[14] Это привело к таким атакам, как ПУДЕЛЬ.

Один из способов избежать этого недостатка безопасности - отключить возможность для сервера или клиента перейти на SSL 3.0. Недостаток этого исправления заключается в том, что оно сделает так, что некоторое устаревшее оборудование не будет доступно для нового оборудования. Если для устаревшего оборудования требуется поддержка SSL 3.0, существует утвержденный набор шифров TLS_FALLBACK_SCSV, который проверяет, что переход на более раннюю версию не запускается из-за злонамеренных намерений.[15]

Наборы шифров для ограниченных устройств

Алгоритмы шифрования, обмена ключами и аутентификации обычно требуют большого количества вычислительной мощности и памяти. Для обеспечения безопасности ограниченные устройства с ограниченной вычислительной мощностью, памятью и временем автономной работы, например, питающие Интернет вещей есть специально подобранные наборы шифров. Два примера включают:

  1. TLS_PSK_WITH_AES_128_CCM_8 (предварительный общий ключ )[16]
  2. TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (сырой открытый ключ )

Каждый из этих наборов шифров был реализован для работы на устройствах с ограничениями в вычислительной мощности и памяти. Оба они реализованы в проекте с открытым исходным кодом. TinyDTLS. Причина, по которой они могут работать с этими ограниченными устройствами, заключается в том, что они могут быть реализованы легким способом. Реализации набора шифров с предварительным общим ключом использовали только 1889 байт ОЗУ и 38266 байт флэш-ПЗУ, что очень требовательно к ресурсам по сравнению с большинством алгоритмов шифрования и безопасности.[17] Такое низкое использование памяти связано с тем, что эти комплекты шифров используют проверенные эффективные алгоритмы, которые являются безопасными, но, возможно, не такими безопасными, как алгоритмы, требующие большего количества ресурсов; exp: Использование 128-битного шифрования против 256-битного шифрования. Кроме того, они используют предварительный общий ключ или сырой открытый ключ, который требует меньше памяти и вычислительной мощности по сравнению с использованием традиционных инфраструктура открытого ключа (PKIX).[18]

Ссылки по программированию

В программировании набор шифров упоминается как во множественном, так и во множественном числе. У каждого из них разные определения:

CipherSuite cipher_suites
список криптографических опций, поддерживаемых клиентом.[19] Пример того, как cipher_suites обычно используется в процессе рукопожатия:
   структура {       Протокол Версия client_version;       Случайный случайный;       Идентификатор сессии идентификатор сессии;       CipherSuite cipher_suites<2..2^16-2>;       CompressionMethod Compression_methods<1..2^8-1>;       Выбрать (extension_present) {           дело ложный:               структура {};           дело истинный:               Расширение расширения<0..2^16-1>;       };   } Клиент привет;
CipherSuite cipher_suite
набор шифров, выбранный сервером из клиентских cipher_suites.[20] Пример того, как cipher_suite обычно используется в процессе рукопожатия:
      структура {          Протокол Версия server_version;          Случайный случайный;          Идентификатор сессии идентификатор сессии;          CipherSuite cipher_suite;          CompressionMethod сжатие_метод;          Выбрать (extension_present) {              дело ложный:                  структура {};              дело истинный:                  Расширение расширения<0..2^16-1>;          };      } СерверПривет;

Смотрите также

Рекомендации

  1. ^ «Наборы шифров в TLS / SSL (Schannel SSP) (Windows)». docs.microsoft.com. Получено 2018-07-02.
  2. ^ RFC  5246
  3. ^ Реестр TLS Cipher Suite
  4. ^ «Протокол SSL 0.2». www-archive.mozilla.org. Получено 2017-12-07.
  5. ^ "Проект-Хикман-Netscape-SSL-00". tools.ietf.org. Получено 2017-12-07.
  6. ^ «Спецификация SSL 3.0». www.freesoft.org. Получено 2017-12-07.
  7. ^ Вильянуэва, Джон Карл. "Введение в наборы шифров". Получено 2017-10-25.
  8. ^ Валсорда, Филиппо (23 сентября 2016 г.). «Обзор TLS 1.3 и вопросы и ответы». Блог Cloudflare. Получено 1 сентября 2020.
  9. ^ «Поддержка протокола TLS 1.3 | Встроенная библиотека SSL / TLS wolfSSL». wolfSSL. Получено 2017-10-26.
  10. ^ Э. Рескорла (4 ноября 2016 г.). «Протокол безопасности транспортного уровня (TLS) версии 1.3». Получено 2016-11-11.
  11. ^ Салливан, Ник (11 августа 2018 г.). «Подробный взгляд на RFC 8446 (он же TLS 1.3)». Блог Cloudflare. Получено 11 августа 2020.
  12. ^ Н., Модадугу; Э., Рескорла. «Безопасность на транспортном уровне дейтаграмм». tools.ietf.org. Получено 2017-10-25.
  13. ^ Эрик, Рескорла; Нагендра, Модадугу. «Дейтаграмная версия безопасности транспортного уровня 1.2». tools.ietf.org. Получено 2017-10-25.
  14. ^ Бодо, Мёллер; Адам, Лэнгли. «Значение набора шифров аварийной сигнализации TLS (SCSV) для предотвращения атак на более раннюю версию протокола». tools.ietf.org. Получено 2017-10-25.
  15. ^ Бодо, Мёллер; Адам, Лэнгли. «Значение набора шифров аварийной сигнализации TLS (SCSV) для предотвращения атак на понижение версии протокола». tools.ietf.org. Получено 2017-10-25.
  16. ^ Дэниел, Бейли; Дэвид, МакГрю. «Наборы шифров AES-CCM для безопасности транспортного уровня (TLS)». tools.ietf.org. Получено 2017-10-26.
  17. ^ Перельмен, Владислав (29 июня 2012 г.). «Безопасность в беспроводных сенсорных сетях с поддержкой IPv6: реализация TLS / DTLS для операционной системы Contiki» (PDF): 38. Архивировано с оригинал (PDF) 29 августа 2017 г.. Получено 7 декабря, 2017. Цитировать журнал требует | журнал = (помощь)
  18. ^ Самуэль, Вейлер; Джон, Гилмор; Ханнес, Чофениг; Теро, Кивинен; Пол, Воутерс. «Использование необработанных открытых ключей в безопасности транспортного уровня (TLS) и безопасности транспортного уровня дейтаграмм (DTLS)». tools.ietf.org. Получено 2017-12-07.
  19. ^ RFC  5246, п. 41 год
  20. ^ RFC  5246, стр. 42–43, 64