Подробное объяснение протоколов HTTP2.0 и HTTPS.

задняя часть HTTP

до начала

Как мы все знаем, HTTP-протокол — это протокол без защитного шифрования.Поскольку он использует передачу открытого текста, сайты, использующие HTTP-протокол, могут быть легко перехвачены, подделаны и взломаны.С развитием Интернета становится все больше и больше. данные, финансы, бизнес, платежи, конфиденциальные данные и т. д., важность безопасности данных становится все более и более заметной, и все больше и больше веб-сайтов используют HTTPS для обеспечения безопасности передачи веб-данных. Кроме того, HTTP 2.0, как новое поколение веб-протокола, обеспечивает улучшенный и более производительный веб-сервис с новыми мощными функциями. В этой статье с точки зрения эксплуатации и обслуживания объясняются преимущества анализа протокола HTTP2.0 по сравнению с HTTP1.1, а также описывается принцип работы протокола HTTPS и в качестве примера рассматривается реальный бизнес-сценарий. освоить протоколы HTTP2.0 и HTTPS с помощью этой статьи и понять принцип с возможностью обнаружения, устранения неполадок и настройки.

1. HTTP1.1 VS HTTP2

Строго говоря, между HTTP2.0 и HTTPS нет необходимой связи, но использовать вместе вкуснее.HTTP2 — это первое обновление после HTTP1.1 в 1999 году. Да, протокол HTTP 1.1, который до сих пор активно используется, существует уже 20 лет, и с учетом скорости технологических изменений в Интернете очевидно, что HTTP 1.1 очень стар. HTTP2 имеет лучшую эффективность и использование ресурсов и особенно подходит для сценариев с тяжелыми страницами и большим количеством загрузки ресурсов (бизнес компании - типичный сценарий).Согласно тестовым данным в сети, в сценариях, где большое количество изображения и ресурсы должны быть загружены Далее, HTTP2 решает проблему блокировки заголовка строки HTTP1.1 (одно взаимодействие запроса должно ждать завершения предыдущего взаимодействия запроса).По сравнению с HTTP1.1, скорость может быть улучшено более чем в 5 раз.В настоящее время Taobao, Tmall, Jingdong и другие платформы имеют Включить HTTP2, если на странице есть много шокирующих ресурсов для загрузки, включение HTTP2.0 абсолютно стоит своих денег.

1. Новые возможности HTTP 2.0

Бинарное кадрирование

  • HTTP/2 передает данные в двоичном формате, а не в текстовом формате HTTP 1.x, а двоичный протокол более эффективен для анализа. Сообщения запроса и ответа HTTP/1 состоят из начальной строки, заголовка и тела объекта (необязательно), и каждая часть отделена разрывом текстовой строки. HTTP/2 разбивает данные запроса и ответа на более мелкие кадры, и они двоично кодируются. Хотя обычная текстовая форма HTTP1.1 выглядит понятной с первого взгляда и очень интуитивно понятна, это только для человеческого опыта.На самом деле, в этом методе есть неоднозначность, такая как использование заглавных букв, пробелы, возврат каретки и перевод строки и т. д. слов и меньше слов Подождите, программа требует сложной обработки, когда дело доходит до обработки. Эффективность относительно низкая и хлопотная, а бинарный метод только 0 и 1, что может строго указывать размер поля, порядок, биты флага и т. Д., Нет двусмысленности, представление небольшое, а эффективность передачи данных в сети также улучшилось.

мультиплексирование

В HTTP 1.1 взаимодействие между запросом и ответом должно ожидать завершения предыдущего взаимодействия запроса, в противном случае последний может только ждать. Если вы столкнетесь с ресурсом, который долго загружается, это снизит скорость загрузки всего сайта. В HTTP 2.0 после успешной связи, если ссылка не отключена, клиентская сторона может одновременно инициировать несколько запросов по одной ссылке, и ответ на каждый запрос не должен ждать других запросов.

  • Мультиплексирование вместо исходной последовательности и механизма блокировки. Все, что запрошено, делается одновременно по одному TCP-соединению. В HTTP 1.x, если вы хотите делать несколько запросов одновременно, вы должны использовать несколько TCP-соединений, а для управления ресурсами браузер также имеет ограничение в 6-8 запросов TCP-соединений для одного доменного имени. Распространенная ситуация заключается в том, что если странице нужно загрузить слишком много статических ресурсов, потому что одновременно их всего 6-8, время ожидания клиентского браузера будет больше, например, основного сайта Zhengcaiyun. Для открытия страницы требуются десятки запросов на получение статических ресурсов. Провел здесь много времени.

пуш сервера

  • В HTTP2 сервер может активно использовать другие ресурсы при отправке HTML страницы, вместо того, чтобы ждать, пока браузер проанализирует соответствующее место, инициирует запрос и затем ответит. Например, сервер может активно отправлять файлы JS и CSS клиенту, не отправляя эти запросы, когда клиент анализирует HTML.

В методе HTTP1.1 клиентский браузер анализирует, какие ресурсы необходимы, а затем загружает их.В HTTP2 сервер может активно отправлять данные, а в сочетании с бизнес-сценариями сервер может сначала передавать клиенту ключевые первичные ресурсы. Для взаимодействия с пользователем требуется только один HTTP-запрос, браузер получает основной ресурс, а производительность страницы значительно повышается. Конечно, если вы запушите слишком много ресурсов сразу, потому что браузеру нужно обработать все запушенные ресурсы. Вместо этого это снизит производительность. Следовательно, компромиссы должны быть сделаны в соответствии с бизнес-сценариями.

сжатие заголовка

  • Запросы HTTP 1.1 становятся все больше и больше, иногда даже больше, чем первоначальный размер окна TCP, потому что им нужно дождаться ответа с ACK, прежде чем они смогут продолжить отправку. HTTP/2 использует HPACK (формат сжатия, специально разработанный для заголовков http/2) для сжатия и передачи заголовков сообщений, что может сэкономить сетевой трафик, занимаемый заголовками сообщений. Однако каждый запрос HTTP/1.x будет содержать много избыточной информации в заголовке, что тратит впустую много ресурсов пропускной способности. Такая информация, как файлы cookie, прикрепляется к каждому запросу, что приводит к ненужному потреблению ресурсов. Чтобы уменьшить потребление ресурсов этим блоком и повысить производительность, HTTP/2 использует стратегию сжатия для этих заголовков:
    • HTTP/2 использует «таблицы заголовков» на стороне клиента и сервера для отслеживания и хранения ранее отправленных пар ключ-значение и больше не отправляет каждый запрос и ответ для одних и тех же данных;
    • Таблица заголовков всегда существует во время соединения HTTP/2 и постепенно обновляется клиентом и сервером;
    • Каждая новая пара ключ-значение заголовка либо добавляется в конец текущей таблицы, либо заменяет предыдущее значение в таблице.

2. Согласование прикладного протокола ALPN

  • Во время рукопожатия HTTPS клиент сначала сообщает серверу, какие протоколы он поддерживает, а сервер выбирает протоколы, поддерживаемые как клиентом, так и сервером. Если Nginx на стороне сервера включает поддержку HTTP2, на стороне сервера будет выбран протокол HTTP2, в противном случае для связи на стороне сервера будет выбран протокол HTTP1.1.

2. Модель SSL/TLS

1. TLS-версия

Историческая версия TLS/SSL постепенно превратилась в пыль истории из-за уязвимостей в системе безопасности и проблем с производительностью.В настоящее время наиболее широко используемой версией является TLS1.2, а TLS1.3 представляет собой обновление до TLS1.2, обеспечивающее более высокий уровень безопасности и более высокая производительность.

2. Наборы шифров

  • Набор шифров: объяснение TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA
    • На основе протокола TLS в качестве алгоритма обмена ключами используются ECDHE и RSA, алгоритм шифрования — AES GCM, длина ключа — 128 бит, а алгоритм хеширования использует sha256.
    • AES-GCM является широко используемым алгоритмом блочного шифрования, но его недостатком является большой объем вычислений, что приводит к относительно высокой производительности и накладным расходам электроэнергии. Чтобы решить эту проблему, Intel выпустила набор расширений инструкций x86 под названием AES NI (новые инструкции Advanced Encryption Standard), который обеспечивает аппаратную поддержку AES. Использование AES-GCM — лучший вариант для хостов, поддерживающих команды AES NI. Преимущество AES-GCM заключается в том, что он может использовать несколько ядер для повышения производительности шифрования и дешифрования.

3. Симметричное и асимметричное шифрование

Алгоритм симметричного шифрования

Алгоритм симметричного шифрования — это метод шифрования, использующий расшифровку с одним ключом, а шифрование и расшифровка используют этот пароль.

  • Широко используемый, признанный в настоящее время алгоритм шифрования с наивысшим уровнем безопасности: AES.
    • Количество битов ключа AES: 128, 192, 256, 512, чем больше длина ключа, тем выше безопасность, но это одновременно повлияет на производительность шифрования и дешифрования. На данный момент ключ длиной 128 бит является достаточно безопасным.
  • Преимущества алгоритма симметричного шифрования: небольшой объем вычислений, высокая скорость шифрования и высокая эффективность шифрования.
  • Недостатки алгоритма симметричного шифрования: Перед передачей данных отправитель и получатель должны согласовать секретный ключ.Если получатель может зашифровать и расшифровать данные, секретный ключ должен быть сообщен. Это принесет массу неудобств в управлении ключами.

Алгоритм асимметричного шифрования

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

  • Широко используемый алгоритм: RSA
  • Преимущества алгоритмов асимметричного шифрования:
    • По сравнению с симметричным шифрованием шифрование и дешифрование разделены. В простом сценарии закрытый ключ хранится, а открытый ключ раскрывается. Расшифровать можно только закрытый ключ. Типичным сценарием является аутентификация SSH.
    • гибкий. Простое управление ключами.
  • Недостатки алгоритмов асимметричного шифрования:
    • Объем вычислений велик, а производительность шифрования ниже, чем у симметричного шифрования. Эффективность выполнения алгоритмов асимметричного шифрования ограничивает практические приложения, большинство из которых используются для аутентификации.

Отступление: анализ сценариев применения симметричного и асимметричного шифрования в программе-вымогателе WannaCry с технической точки зрения

Нет никаких сомнений в разрушительности вируса-вымогателя WannaCry. В одночасье пострадали правительства, банки и предприятия по всему миру. В таком случае, почему технологические гиганты отрасли не смогли предоставить эффективные решения для ремонта и восстановления?

  • Принцип реализации программы-вымогателя: Помимо уязвимости нулевого дня (это связано только с путем передачи инфекции, а не с технологией шифрования) После запуска на компьютере WannaCry будет использовать симметричное шифрование AES для шифрования файлов с указанным суффиксом. , Причина выбора AES здесь заключается в том, что это симметричное шифрование требует относительно небольшого объема вычислений и высокой скорости.Попробуйте зашифровать файлы с указанным суффиксом на полном диске.Эта величина относительно велика, поэтому симметричное шифрование является более подходящим выбор, но проблема в том, что симметричное шифрование выставит пароль дешифрования во время шифрования. , если этот пароль хранится в клиенте, он будет получен, а затем напрямую разблокирован. Невозможно бросить вызов мировым богам технологий слепыми методами. Если пароль будет удален, зашифрованный файл никогда не будет расшифрован, поэтому цель вымогательства не может быть достигнута. Поэтому разработчики WannaCry также использовали алгоритм асимметричного шифрования RSA для шифрования ключа AES, а затем сохраняли его в заголовке зашифрованного файла. В этом случае автору WannaCry нужно только освоить закрытый ключ RSA, и он может сначала расшифровать ключ AES в заголовке файла с помощью закрытого ключа, а затем расшифровать файл с помощью ключа AES. Так почему бы не зашифровать файл напрямую через RSA? На самом деле, есть также некоторые вирусы-вымогатели, которые делают это.Недостатком является то, что процесс шифрования занимает много времени, потому что асимметричное шифрование требует много вычислений, а процесс шифрования потребляет много системных ресурсов и его легко найти.
  • Сложность взлома AES: если вы используете взлом грубой силы для операций хранения с каждой песчинкой на земле, не будет преувеличением сказать, что вы не сможете вычислить его до того, как солнце расширится или земля будет разрушена. Короче говоря, в настоящее время нет возможности быть взорванным.

4. Процесс рукопожатия HTTPS

    1. Фаза приветствия клиента

      Client-hello — это первое сообщение, отправляемое клиентом после установления TCP-соединения.Основная цель — передать серверу функции и параметры, поддерживаемые клиентом.

      • После завершения ввода адреса в браузере разрешите доменное имя для получения IP-адреса хоста, браузер выполнит трехстороннее рукопожатие с 443 этого хоста (по умолчанию, если указан другой порт, этот порт будет подключен) установить TCP-соединение, а затем войти в Client-hello. На этом этапе браузер отправит набор шифров, поддерживаемый клиентом, целевой хост и другую информацию на сервер, а также прикрепит случайно сгенерированный билет сеанса1.

 + ALPN协商: 应用层可以协商在安全连接层之上使用什么协议, 避免了额外的往返通讯,  如上图

  • Этап приветствия сервера

    • После того, как сервер получает запрос установления связи TLS, отправленный браузером, он сохраняет билет сеанса1, отправленный браузером, а затем ищет соответствующий сертификат сервера в соответствии с отправленным узлом, а затем преобразует сертификат сервера и сервер из поддерживаемого шифрования. клиентом, предоставленным Client Hello серверу.В списке пакетов выберите пакет, поддерживаемый обеими сторонами по приоритету (если пересечение пакета, поддерживаемого сервером, и пакета, поддерживаемого клиентом, пусто, рукопожатие не выполняется ), и случайно сгенерированный билет сеанса2 возвращается в браузер.

image.png

Шаги Client-hello и server-hello очень похожи на покупки: Клиент: Сколько у меня денег, я могу заплатить через Alipay или WeChat, Сервер: Мне нужно xxx RMB, давайте воспользуемся Alipay.

  • Этап спецификации шифра

    После Client Hello и Server Hello клиент и сервер завершают согласование набора шифров. Переход на этап Cipher-spec проверит действительность сертификата и

    • После того, как браузер получит сертификат, возвращенный сервером, он проверит действительность сертификата.Этапы проверки следующие:
      • Проверить срок действия сертификата
      • Убедитесь, что доменное имя сертификата соответствует фактическому хосту.
      • Проверьте состояние отзыва сертификата (CRL+OCSP), чтобы убедиться, что сертификат отозван.
      • Проверьте центр сертификации, если центр является промежуточным сертификатом (в основном все), затем проверьте срок действия/издателя/статус отзыва промежуточного сертификата.Вплоть до последнего уровня сертификата, если какая-либо часть процесса провалится, это вызовет недоверие.
      • Если проверка проходит успешно, генерируется сеансовый билет 3 случайным образом (это второй билет, сгенерированный браузером), а открытый ключ в сертификате возвращается, шифруется с помощью согласованного алгоритма шифрования и возвращается на сервер. время браузер использует билет сеанса 1 (браузер), билет сеанса 2 (сервер) и билет сеанса 3 (браузер) объединяются в ключ сеанса.

  • Этап доставки контента

    • После того, как TLS-соединение установлено, до того, как соединение будет разрушено, интерактивные данные между браузером и сервером симметрично шифруются сеансовым ключом.
  • Процесс рукопожатия HTTPS для захвата пакетов:

Первые три строки представляют собой трехстороннее рукопожатие TCP, четвертая строка — клиент инициирует приветствие клиента, пятая строка — ответ подтверждения сервера, шестая строка — сервер приветствия, девятая строка выполняет проверку сертификата на этапе спецификации шифра, а 13-я строка вводит обмен данными после завершения рукопожатия.

5. HSTS

Обычно, когда мы посещаем веб-сайт, большинство из нас намеренно не пишут https впереди, и мы редко обращаем внимание на то, просматриваем ли мы протокол HTTP или протокол HTTPS. И сайты, которым требуется доступ https, в основном перенаправляются на адрес HTTPS путем перенаправления, когда пользователь получает доступ через http, и если я перехватываю пользовательский трафик, перехватываю запрос перенаправления на https, а затем выступаю в качестве прокси, честно говоря, запрос клиента пересылаются и возвращаются, но взаимодействие между клиентом и посредником использует открытый текстовый протокол HTTP.Поскольку SSL-соединение не установлено, информация, отправленная клиентом, будет раскрыта. Исходя из этой проблемы, Международная инженерная организация Интернета IETF выпустила механизм политики безопасности HSTS, заставляющий браузеры использовать HTTPS для связи с сайтами.

  • Роль HSTS (HTTP Strict Transport Security) заключается в том, чтобы заставить клиента (например, браузер) использовать HTTPS для создания соединения с сервером. HSTS в основном контролирует операции браузера, отправляя заголовки ответов с сервера:

    • Когда клиент делает запрос через HTTPS, сервер включает в возвращаемый заголовок HTTP-ответаStrict-Transport-SecurityПоле (переключатель HSTS управляется сервером).

    • После того, как браузер получит такую ​​информацию, любой запрос к веб-сайту в течение определенного периода времени будет инициирован с помощью HTTPS (перенаправление 307 внутри браузера), а не с HTTP, а затем перенаправлен сервером на HTTPS.

3. SSL-сертификат

Сертификат SSL конкретно относится к цифровому сертификату, выданному доверенным центром цифровой сертификации (ЦС). Сертификаты SSL обеспечивают аутентификацию (DV/OV/EV) и шифрование передачи данных.

1. Доверие к CA

  • Всем нужно только использовать OpenSSL с открытым исходным кодом, чтобы легко сгенерировать корневой сертификат, а затем выдать его, и это почти ничего не стоит. Его даже можно настроить для предоставления службы HTTPS на веб-сервере, но браузер не доверяет ему. Почему нам все еще нужно платить большие деньги, чтобы купить сертификаты, выданные агентствами CA? В системе сертификатов корневой сертификат сертификата ЦС очень важен.Если человек получает закрытый ключ корневого сертификата ЦС, теоретически он может расшифровать данные HTTPS с точки зрения Бога, угнать и подделать данные через посредника. Таким образом, текущий корневой сертификат ЦС предъявляет очень высокие требования к безопасности.Если организация ЦС хочет пройти проверку, закрытый ключ имеет не менее 365 дней x 24 часа непрерывного патрулирования безопасности. Карта контроля доступа + радужная оболочка отпечатков пальцев и другая биометрическая двойная защита, каждая запись будет записываться в неизменяемую систему журналов, сам закрытый ключ ЦС физически изолирован, а модуль шифрования ЦС гарантирует, что закрытый ключ не может быть физически скопирован и может быть только используется для выдачи. Вполне возможно, что лично сгенерированный ЦС не может иметь такой высокий уровень безопасности.
  • В конечном счете, CA выживает за счет доверия. Если ему не доверяют, он ничем не отличается от сертификата, выданного физическим лицом. Печальный случай: Wotong в Китае изначально был доверенным корневым центром сертификации с квалификацией CA, а также был единственным CA в Китае.Человек или организация с сертификатом может расшифровать подслушивание, захватить github.com) и быть остановленным Firefox и Гугл Хром. таким образом становясь подчиненным агентом.

2. Институциональная роль

  • Корневой центр сертификации CA (CA, центр сертификации) может существовать ROOT CA, первичный CA, вторичный CA... и так далее. Многоуровневый ЦС можно понимать как корневой ЦС, который выдает полномочия на выдачу сертификатов подчиненным ЦС для целей распространения, а корневой ЦС обычно не выдает сертификаты напрямую.
  • Центр регистрации сертификатов RA (Registration Authority, RA) эквивалентен агенту, действующему в качестве CA для идентификации и идентификации заявителей сертификатов, утверждения или отклонения заявок на сертификаты, активного отзыва или приостановки действия сертификатов в определенных средах и обработки подписчиков для отзыва или приостановки их действия. сертификаты запрашивают предоставление или отклонение запроса пользователя на обновление его сертификата или ключа. Но сертификат выдать нельзя. Например, Alibaba Cloud — это RA.
  • SRCA — это ненадежный ЦС. На самом деле все сертификаты, выпущенные частными или ненадежными организациями, относятся к этому типу.

3. Процесс выдачи сертификата

3. Тип сертификата

DV (домен подтвержден)

  • Сертификат проверки доменного имени проверяет только доменное имя, поскольку необходимо подтвердить только право собственности на доменное имя, а скорость выдачи самая высокая. Почти в режиме реального времени бесплатные сертификаты Let's Encrypt относятся к этому типу.

OV (Организация подтверждена)

  • Сертификат проверки организации, в дополнение к проверке доменного имени, также проверит организацию.Например, если вы хотите приобрести сертификат OV, будет проверено не только право собственности на доменное имя, но и то, заполнена ли организация при подаче заявки на сертификат правильный. Поэтому скорость выдачи медленнее, обычно около 3 дней, а цена намного выше, чем у сертификата DV. Этот тип сертификата в настоящее время используется Zhengcaiyun. Выдача происходит медленнее и занимает 3-5 рабочих дней.

EV (расширенная проверка)

  • Сертификат расширенной проверки очень удобен для браузеров. Он будет отображать название организации прямо в адресной строке браузера, что более способствует созданию бренда. Он также известен как сертификат верхнего уровня с самым высоким уровнем безопасности. это также самый дорогой тип сертификата. Применение и проверка сертификата EV очень строгие, это занимает 5-7 рабочих дней, в дополнение к проверке сертификата DV / OV, также необходимо пройти стороннюю проверку, юридические сертификационные документы и т. д., и EV не имеет подстановочной версии сертификата. Можно приобрести только версию с одним доменом.

4. Цепочка сертификатов

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

корневой сертификат (корень)

  • Для основных систем, таких как Windows, Android и Linux, база корневых сертификатов будет обновляться только один раз в год или чаще. Большинство браузеров используют корневое хранилище сертификатов операционной системы, есть исключения, такие как браузер Firefox, Google Chrome поддерживает собственное хранилище сертификатов ЦС. Новому корневому сертификату очень сложно завоевать доверие за короткое время.

Промежуточные продуктыСертификат

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

Сертификат доменного имени

  • Сертификат доменного имени делится на открытый ключ и закрытый ключ.Когда браузер взаимодействует с веб-сервером, веб-сервер возвращает открытый ключ браузеру.

5. Отзыв сертификата

  • Список отозванных сертификатов (Certificate Revocation List ), называемый CRL, который содержит: время истечения срока действия и время следующего обновления списка отзыва информации центра сертификации.
  • Online Certificate Status Pротокол, сокращенно:OCSP: протокол статуса онлайн-сертификата, альтернатива CRL, поскольку ответ OCSP содержит меньше информации, чем CRL, он снижает нагрузку на сетевые и клиентские ресурсы и требует меньше информации для анализа.

В-четвертых, проблемы эксплуатации и обслуживания, связанные с эпохой HTTP2.0.

1. Лучший СР: HTTP2 + HTTPS

https на самом деле является протоколом http, построенным поверх SSL/TLS, поэтому для сравнения того, сколько ресурсов сервера https использует больше, чем http, это в основном зависит от того, сколько ресурсов ЦП сервера потребляется самим SSL/TLS. Сетевая часть: http использует трехстороннее рукопожатие TCP для установления соединения.Клиент и сервер должны обменяться пакетами 3. В дополнение к трем пакетам TCP, https также необходимо добавить 9 пакетов, необходимых для рукопожатия ssl, поэтому есть Всего 12 пакетов. Часть ЦП потребляет больше ресурсов, потому что HTTPS имеет процесс шифрования и дешифрования. В стандарте HTTP2.0, хотя использование шифрования (HTTPS) не является обязательным, текущие основные браузеры, Chrome, Firefox и т. д. публично объявили, что они поддерживают только зашифрованный HTTP2, поэтому HTTP2, который можно увидеть в Интернете в основном основан на протоколе HTTPS. HTTPS обеспечивает безопасность передачи, но вызывает дополнительные потери производительности, а появление HTTP2 значительно повышает производительность передачи за счет мультиплексирования, сжатия заголовков и других функций. Надо сказать, что HTTP2 + HTTPS — лучшая комбинация для нового поколения веб-сервисов.

2. Проблемы, вызванные неполной цепочкой сертификатов

  • Явление: компания перешла на новое доменное имя, и после того, как Alibaba Cloud напрямую развернула сертификат на SLB, некоторые клиенты сообщили, что мобильный телефон открыл официальный веб-сайт и предложил ненадежный сертификат. Но когда я открываю хром на своем компьютере, все работает нормально.
  • Анализ проблемы: Операционная система обычно содержит доверенный ЦС, но многие сертификаты обычно не выдаются ЦС напрямую. Вместо этого используйте сертификат промежуточного уровня для подписи. Это приведет к тому, что если развертываемый вами сертификат не будет содержать сертификат промежуточного уровня, то он не будет доверенным, поскольку цепочка сертификатов неполна.Конечно, большинство сертификатов промежуточного уровня уже включены в два основных браузеры, хром и фаерфокс, поэтому при доступе нет сертификата промежуточного уровня. Проблема, но браузеры в различных дистрибутивах Android могут не содержать вторичных сертификатов. Если веб-сервер не содержит промежуточных сертификатов и используемый браузер не содержит промежуточных сертификатов , это приведет к проблемам с доверием.

3. Безопасность сертификата

  • Одна проблема, которую легко упустить из виду после развертывания HTTPS, — это безопасность самого сертификата. В случае утечки закрытого ключа HTTPS возникнет много проблем с безопасностью. Из вышеприведенного содержания может быть известно, что если закрытый ключ получен и выполнены определенные условия, взаимодействие между пользователем и сервером в основном находится в состоянии чередования, и секрет учетной записи пользователя и информация о транзакции заказа могут быть перехвачены. Следовательно, необходимо управлять самим SSL-сертификатом, выданным УЦ, и его нельзя копировать или размещать по своему усмотрению.

4. Мониторинг сертификатов

  • Весь процесс рукопожатия HTTPS и сведения о сертификате можно получить с помощью команды curl. Обычно мы отслеживаем срок действия сертификата, получая дату истечения срока действия. Если вывод ошибки команды curl не равен 0, чтобы исключить сетевую проблему, возможно, сертификат не является доверенным. Конечно, вы также можете использовать openssl или сценарии для мониторинга без команды curl.Принцип тот же.
 wangxun@wangxun ~ curl https://zcygov.cn -vv
* Rebuilt URL to: https://zcygov.cn/
*   Trying 101.37.44.108...
* TCP_NODELAY set
* Connected to zcygov.cn (101.37.44.108) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=CN; ST=\U6D59\U6C5F\U7701; L=\U676D\U5DDE\U5E02; O=\U653F\U91C7\U4E91\U6709\U9650\U516C\U53F8; OU=IT; CN=*.zcygov.cn
*  start date: May  7 00:00:00 2019 GMT
*  expire date: May  6 12:00:00 2021 GMT
*  subjectAltName: host "zcygov.cn" matched cert's "zcygov.cn"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=GeoTrust RSA CA 2018
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: zcygov.cn
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Date: Wed, 07 Aug 2019 07:16:47 GMT
< Content-Type: text/html
< Content-Length: 191
< Connection: keep-alive
< Set-Cookie: acw_tc=76b20feb15651622072312298e0526c6496462332328e0842a443f28ecb7be;path=/;HttpOnly;Max-Age=2678401
< Location: https://www.zcygov.cn/
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>openresty/1.13.6.1</center>
</body>
</html>
* Connection #0 to host zcygov.cn left intact

6. Настройка HTTP2 и HTTPS под Nginx

server {
    listen       4433 ssl;
    listen       [::]:4433 ssl;
    server_name  cai-inc.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";  # 启用HSTS
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;  # 服务端支持的TLS版本
    ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
    # 服务端支持的和不支持的加密套件。
        ssl_certificate "/etc/letsencrypt/certs/fullchain.pem";
        ssl_certificate_key "/etc/letsencrypt/certs/privkey.pem";
        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout  10m;
        ssl_prefer_server_ciphers on;
    location / {
      proxy_pass http://127.0.0.1:8899;
      }

  }

Суммировать

  • HTTP2.0 и HTTPS — хорошее сочетание: HTTP2.0 повышает эффективность HTTP1.1, а HTTPS обеспечивает безопасность ссылок. Использование HTTP2.0 может значительно повысить эффективность загрузки страниц при работе с большим количеством загрузок ресурсов страницы.
  • Ядром системы сертификатов HTTPS является доверенный ЦС. Раскрытие закрытого ключа сертификата HTTPS того же доменного имени также приведет к угрозам безопасности. Поскольку он развернут на стороне пользователя, закрытый ключ доменного имени сертификат необходимо правильно хранить.
  • При развертывании сертификата необходимо развернуть полную цепочку сертификатов. Неполная цепочка сертификатов может привести к тому, что некоторые старые устройства не смогут пройти проверку сертификата.
  • Подделка корневого сертификата и доверие операционной системы — это ужасно, а это значит, что все ваши запросы бросаются в глаза владельцу закрытого ключа корневого сертификата.
  • Ненадежные сертификаты могут привести к серьезным проблемам со стабильностью, поэтому необходим мониторинг сертификатов.
Категории