Мало знаний, большой вызов! Эта статья участвует в "Необходимые знания для программистов«Творческая деятельность

Эта статья приняла участие"Проект "Звезда раскопок"", чтобы выиграть творческий подарочный пакет и бросить вызов творческим поощрительным деньгам.

«Добро пожаловать для обсуждения в области комментариев, официальный представитель NuggetsПроект «Звезда раскопок»После мероприятия в комментариях будет разыграно 100 штук Наггетсов.Подробнее о лотерее читайте в статье о мероприятии».

Введение

Все изменилось с тех пор, как HTTP был обновлен с 1.1 до 2. Хотя HTTP2 не требует обязательного использования зашифрованного протокола для передачи, отраслевые стандарты, включая самые популярные браузеры, поддерживают только протокол HTTP2 в случае HTTPS.

Так как же добавить поддержку протокола HTTP2 в HTTPS? Сегодня в этой статье мы поговорим о расширениях NPN и ALPN протокола SSL/TLS.

SSL/TLS-протокол

SSL (Secure Socket Layer) — это набор протоколов, разработанный Netscape в 1994 году и выпущенный в версии 3.0 в 1995 году.

TLS (Transport Layer Security) — это протокол, разработанный IETF на основе SSL 3.0, фактически эквивалентный последующей версии SSL.

SSL/TLS — это инфраструктура криптографической связи, наиболее широко используемый метод криптографической связи в мире.

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

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

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

Далее шаг за шагом вводим смысл каждого шага:

client hello

Клиент отправляет приветственное сообщение клиента на сервер, включая следующее:
- Доступные номера версий
- Текущее время
- Случайное число клиента
- идентификатор сессии
- Список доступных наборов шифров
- Список доступных методов сжатия

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

Клиентский одноразовый номер — это случайное число, сгенерированное клиентом для создания симметричного ключа.

server hello

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

Используемый номер версии, используемый набор шифров, используемое сжатие — это ответ на шаг 1.

Случайное число сервера — это случайное число, сгенерированное сервером для создания симметричного ключа.

Необязательный шаг: сертификат

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

Если информации о сертификате на третьем шаге недостаточно, вы можете отправить ServerKeyExchange для создания зашифрованного канала.

Содержимое ServerKeyExchange может иметь две формы:
- Если выбран протокол RSA, то передаются параметры (E, N) для RSA для построения криптографии с открытым ключом. Вспомним формулу построения открытого ключа в RSA: $Зашифрованный текст = открытый текст ^ E \ mod \ N$ , Пока известны E и N, известен открытый ключ RSA, и здесь передаются два числа E и N. Конкретное содержание может относиться кПодробное объяснение алгоритма RSA
- Если выбран протокол обмена ключами Diff-Hellman, то передаются параметры обмена ключами, подробнее см.Более безопасный метод генерации ключей Диффи-Хеллмана
Необязательный шаг: CertificateRequest

Если он находится в среде с ограниченным доступом, такой как фабрика, серверу также необходимо запросить у клиента сертификат. Этот шаг не требуется, если не требуется аутентификация клиента.
сервер привет сделал Сервер отправляет серверу сообщение hello done, чтобы сообщить клиенту, что его сообщение закончилось.
Необязательный шаг: Сертификат

В ответ на шаг 5 клиент отправляет сертификат клиента на сервер.
ClientKeyExchange

Есть еще два случая:
- В случае открытого ключа или режима RSA клиент сгенерирует предварительный мастер-пароль в соответствии со случайным числом, сгенерированным клиентом, и случайным числом, сгенерированным сервером, зашифрует его с помощью открытого ключа и вернет на сервер.
- Если используется протокол обмена ключами Diff-Hellman, клиент отправляет значение, которое его собственная сторона должна раскрыть, чтобы сгенерировать ключ Diff-Hellman. Конкретное содержание может относиться кБолее безопасный метод генерации ключей Диффи-Хеллмана, чтобы сервер мог вычислить предварительный мастер-пароль на основе этого общедоступного значения.
Необязательный шаг: CertificateVerify

Клиент доказывает серверу, что он является держателем клиентского сертификата.
ChangeCipherSpec (готов к переключению шифров)

ChangeCipherSpec — это сообщение протокола изменения спецификации шифра, указывающее, что следующее сообщение будет зашифровано ранее согласованным ключом.
завершено (конец протокола рукопожатия)

Клиент сообщает серверу, что протокол рукопожатия завершен.
ChangeCipherSpec (готов к переключению шифров)

Сервер сообщает клиенту, что хочет сменить пароль.
завершено (конец протокола рукопожатия)

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

После этого сервер и клиент обмениваются данными в зашифрованном виде.

НПН и АЛПН

Когда мы представили протокол SSL/TLS выше, последним шагом было переключение на протокол данных приложения.Так как же клиент обсуждает и согласовывает с сервером, какой протокол данных приложения использовать? Используется HTTP1.1? Или HTTP2? Или как насчет SPDY?

Здесь используется протокол расширения TLS. А NPN (согласование следующего протокола) и ALPN (согласование протокола прикладного уровня) являются двумя протоколами расширения TLS.

В основном они используются в TLS для согласования того, какой протокол данных приложения клиент и сервер должны использовать для связи.

где NPN — это расширение, используемое SPDY, а ALPN — это расширение, используемое HTTP2.

В чем разница между ними двумя?

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

Ниже приведена конкретная блок-схема взаимодействия:

пример взаимодействия

Ниже в качестве примера для объяснения конкретного процесса взаимодействия используется ALPN.Во-первых, клиент отправляет сообщение «Client Hello»:

    Handshake Type: Client Hello (1)
    Length: 141
    Version: TLS 1.2 (0x0303)
    Random: dd67b5943e5efd0740519f38071008b59efbd68ab3114587...
    Session ID Length: 0
    Cipher Suites Length: 10
    Cipher Suites (5 suites)
    Compression Methods Length: 1
    Compression Methods (1 method)
    Extensions Length: 90
    [other extensions omitted]
    Extension: application_layer_protocol_negotiation (len=14)
        Type: application_layer_protocol_negotiation (16)
        Length: 14
        ALPN Extension Length: 12
        ALPN Protocol
            ALPN string length: 2
            ALPN Next Protocol: h2
            ALPN string length: 8
            ALPN Next Protocol: http/1.1

Видно, что в поле Extension в приветственном сообщении клиента используется ALPN, и перечислены два протокола ALPN, которые можно использовать: h2 и http/1.1.

Соответствующее сообщение «сервер привет» выберет конкретный протокол ALPN, используемый следующим образом:

    Handshake Type: Server Hello (2)
    Length: 94
    Version: TLS 1.2 (0x0303)
    Random: 44e447964d7e8a7d3b404c4748423f02345241dcc9c7e332...
    Session ID Length: 32
    Session ID: 7667476d1d698d0a90caa1d9a449be814b89a0b52f470e2d...
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
    Compression Method: null (0)
    Extensions Length: 22
    [other extensions omitted]
    Extension: application_layer_protocol_negotiation (len=5)
        Type: application_layer_protocol_negotiation (16)
        Length: 5
        ALPN Extension Length: 3
        ALPN Protocol
            ALPN string length: 2
            ALPN Next Protocol: h2

Как показано выше, серверная сторона выбирает h2, и, наконец, когда рукопожатие TLS на стороне клиента и сервера завершено, HTTP2 будет выбран в качестве последующего протокола данных прикладного уровня.

Суммировать

И NPN, и ALPN являются расширениями TLS, для сравнения, ALPN проще в использовании.

Эта статья была включена вwoohoo.floydpress.com/08-ratings-torres-…

Самая популярная интерпретация, самая глубокая галантерея, самые краткие уроки и множество трюков, о которых вы не знаете, ждут вас!

Добро пожаловать, чтобы обратить внимание на мой официальный аккаунт: «Программируйте эти вещи», разбирайтесь в технологиях, лучше поймите себя!