Полное понимание TLS/SSL

В настоящее время TLS/SLL является важной частью сетевой безопасности.Посредством обмена ключами и генерации ключей весь процесс шифрования канала окончательно установлен. Как мы все знаем, TLS/SSL требует значительного количества времени.По сравнению с 3 RTT TCP, если добавить TLS/SSL, общее время RTT увеличится как минимум в 4 раза. Хотя это выглядит много, по сравнению с текущей сетевой средой это составляет около 20–30 мс каждый раз, поэтому, по оценкам, это около 100 мс. Такая разница во времени еще терпима, однако DNS-разрешение здесь не учтено, и это пока не рассматривается. Более того, если сеансовый ключ, сгенерированный TLS/SSL, находится в пределах срока действия, это время можно полностью игнорировать. Без дальнейших церемоний, давайте сразу перейдем к основам TLS/SSL.

Статья взята с:please call me HR

TLS-алгоритм

TLS/SSL на самом деле представляет собой процесс создания симметричного зашифрованного сеансового ключа посредством асимметричного шифрования. Алгоритм симметричного шифрования — это не что иное, как AES или модуль шифрования/дешифрования. RSA обычно используется в асимметричном шифровании, но также используется алгоритм Диффи-Хеллмана. Однако с точки зрения безопасности DH выше. Потому что, когда RSA генерирует сеансовый ключ, он в конечном итоге генерируется браузером, а затем шифруется открытым ключом и передается на сервер, возникает определенная проблема: если хакер получает закрытый ключ, то он может отслеживать трафик на всем протяжении. весь процесс, а затем используйте закрытый ключ.Ключ расшифрован, тогда возможно, что сеансовый ключ также будет раскрыт. Но для DH отличие его механизма в том, что sessionkey не передается по сети, а генерируется независимо на обоих концах. ok~ Это включает согласованность двух ключей. У DH также есть механизм, а именно совершенная секретность пересылки — PFS: закрытый ключ на стороне сервера не может быть использован для замены какого-либо предыдущего сеансового ключа, поэтому он не может взломать содержимое предыдущего сеанса. Для каждого подключения DH повторно генерирует ключ и отбрасывает его после завершения сеанса. Однако это не является большой проблемой, поскольку DH может очень быстро генерировать ключи. Потому что он проводит в сети половину времени по сравнению с RSA. Это легко понять из следующего рисункаDHАлгоритм шифрования:

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

использование сеансового ключа

TLS/SSL на самом деле представляет собой процесс генерации симметричного зашифрованного сеансового ключа посредством асимметричного шифрования.

Какова основная цель сеансового ключа? Прежде всего, мы должны четко указать, что сеансовый ключ используется для симметричного шифрования, и этот метод шифрования в основном использует алгоритм шифрования AES. Это отличается от алгоритма асимметричного шифрования с эллиптической кривой Диффи-Хеллмана (ECDH). Оба действительно могут использоваться для шифрования информации, но из-за различных внутренних механизмов реализации алгоритмов время, которое они используют, также отличается. По сути, ECDH занимает в 3 раза больше времени, чем AES.

Вы можете проверить это самостоятельно:

openssl speed ecdh
openssl speed aes

Хорошо, алгоритм, используемый TLS/SSL, кратко описан выше. Далее давайте рассмотрим конкретный процесс обмена ключами TLS/SSL.

TLS/SLL-процесс

Прежде чем детализировать процесс, нам нужно понять, что будет происходить в процессе.

ключ сеанса: это окончательный результат согласования TLS/SSL, используемый для симметричного шифрования.
client random: это значение последовательности 32B, которое будет динамически генерироваться каждый раз, когда приходит соединение, то есть значение, генерируемое каждым соединением, не будет одинаковым. Потому что он содержит 4 миллиарда временных меток и 28 миллиардов случайных чисел.
server random: То же, что и client random, но генерируется сервером.
предварительный секрет: это 48 байт данных большого двоичного объекта. Это может пройти со случайным клиентом и серверомpseudorandom(PRF) вместе для создания сеансового ключа.
набор шифров: используется для определения алгоритмов, используемых соединениями TLS. Обычно выделяют 4 части:
- Асимметричное шифрование (ECDH или RSA)
- Проверка сертификата (тип сертификата)
- Конфиденциальность (алгоритм симметричного шифрования)
- Целостность данных (функция для генерации HASH) НапримерAES128-SHAпредставляет собой:
  - Алгоритм RSA для асимметричного шифрования
  - RSA для проверки сертификата
  - 128-битное симметричное шифрование AES
  - 160-битный алгоритм шифрования данных SHA
- НапримерECDHE-ECDSA-AES256-GCM-SHA384представляет собой
  - Алгоритм ECDHE для асимметричного шифрования
  - ECDSA для проверки сертификата
  - 265-битное симметричное шифрование AES
  - 384-битный алгоритм шифрования данных SHA

Думаю, вы уже знакомы с этой картинкой:

Однако разве вышеизложенное не говорило о том, что существуют два разных метода асимметричного шифрования? РСА и ДХ? Тогда почему на картинке только файл? ок, на самом деле эта картина правильная, он не расписал содержание передачи, что очень важно. Два алгоритма также различаются по содержимому передачи, и основной процесс точно такой же. согласно сwikiОбъяснение, мы, вероятно, можем знать содержание, необходимое для всего процесса передачи.

Клиент отправляет сообщение clientHello, которое содержит самую высокую версию протокола TLS, поддерживаемую клиентом, случайное число (упомянутое выше) и набор шифров. Если клиент использует возобновленное рукопожатие, то здесь отправляется идентификатор сеанса. Если клиент также поддерживает ALPN, ему также необходимо отправить другие поддерживаемые им протоколы, такие как HTTP/2.
На этапе serverhello на стороне сервера сервер принимает различные стратегии в соответствии с соответствующей информацией, отправленной клиентом, а также отправляет информацию о самой высокой версии TLS, соответствующую клиентской стороне, набору шифров и случайному числу, сгенерированному им самим. , это будет сгенерировано здесь, раз соединение уникальноsessionID.
На этапе сертификата к информационному потоку добавляется сертификация открытого ключа. ServerKeyExchange Этот этап в основном нацелен на метод шифрования ECDH, который не будет здесь повторяться и будет объяснен позже.
serverHelloDone отмечает окончание обработки фазы сервера и отправляет информацию, сгенерированную на этой фазе, клиенту.
На этапе clientKeyExchange клиент случайным образом сгенерирует последовательность предварительных секретов, которые будут зашифрованы открытым ключом, а затем отправлены на сервер. На этапе ChangeCipherSpec, в основном, клиент сам генерирует sessionKey через pre-master secret + server random-num + client random-num. Это означает конец процесса TLS/SSL на стороне клиента.
Последующая команда ChangeCipherSpec, выполняемая на стороне сервера, аналогична операции, выполняемой клиентом.С помощью закрытого ключа для расшифровки предварительного мастер-секрета, отправленного клиентом, генерируется сеансовый ключ. После повторного прохождения проверки используйте сеансовый ключ для шифрованияserver finshed, отправьте его клиенту и убедитесь, что его можно успешно расшифровать, что указывает на окончательное завершение TLS/SSL.

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

Далее мы в основном объясняем другой метод шифрования, DH. Основное различие между ним и RSA заключается в том, передается ли секрет pre-master или нет. RSA пройден, а DH нет.

согласно сcloudflareОбъяснение может четко понять разницу между ними:

Это метод передачи RSA, и основной процесс описан выше.

Конкретная разница между DH заключается в следующем:

Здесь сначала добавьте знания алгоритма DH. Потому что премительский секрет генерируется на основе этого. Основной процесс DH не слишком сложен. Для получения подробной информации, пожалуйста, обратитесь кwiki. Основная формула, которую он использует:

Чтобы данные не были слишком большими при обмене параметрами DH, DH использует метод по модулю, так что передаваемое значение всегда может быть ограничено [1,p-1]. Здесь сначала объясните основные условия алгоритма DH:

Общее условие: p и g известны и общедоступны. То есть третье лицо также может получить его по своему желанию.
Частные условия: a и b генерируются самими обоими концами и не могут быть получены третьими лицами.

Основной процесс:

Нам просто нужно заменить параметр DH на рисунке выше на соответствующий X/Y. И последняя буква Z — это секрет Premaster, который нам нужен. После этого он согласуется с алгоритмом шифрования RSA, а также случайным числом с обеих сторон для генерации sessionKey. Pass, мы часто называем DH, также известный какEphemeral Diffie-Hellman handshake. Потому что его sessionKey каждый раз разный.

Конкретное различие между RSA и DH заключается в следующем: RSA будет передавать отображаемый предварительный секрет, что может вызвать проблемы с безопасностью, вызванные утечкой закрытого ключа. И DH не будет передавать раскрытый предварительный секрет.

Основные понятия TLS/SSL

Приведенный выше контент примерно объясняет основной процесс шифрования TLS/SSL. Однако среди них есть множество других мелких деталей, таких как SNI, ALPN, Forward Secrey. Далее мы в основном сосредоточимся на этих деталях, потому что они на самом деле очень важны.

Forward Secrey

FS (Forward Secrey) в основном описывается для закрытого ключа. Если ваш закрытый ключ можно использовать для расшифровки содержимого сеанса предыдущего сообщения, например, путем расшифровки вашего предварительного секрета с помощью закрытого ключа и получения sessionKey, вы можете расшифровать содержимое передачи. Эта ситуация не является прямой секретной. Итак, как сделать ФС? Это очень просто, как упоминалось выше, просто используйте шифрование DH. Поскольку последний сгенерированный sessionKey не имеет прямого отношения к закрытому ключу, предварительный секрет передается черезg(ab) mod Pпринадлежит.

Проще говоря, если вы хотите включить FS, вам следует использовать шифрование DH вместо RSA. Однако по историческим причинам (проблемы с версией TLS) RSA по-прежнему остается основным методом шифрования. Тем не менее, DH также полагается на него5Sбезопасность, доля также увеличивается.

ALPN

Полное название ALPN — согласование протокола прикладного уровня (механизм согласования протокола прикладного уровня). Видя прикладной уровень, программисты должны уметь отражать сетевой протокол 7-го уровня OSI. На прикладном уровне в центре внимания должен быть протокол HTTP. Однако из-за проблем с версией HTTP, а теперь и популярности HTTP2, появился ALPN, позволяющий клиент-серверу использовать один и тот же протокол. ALPN фактически является производным от протокола NPN в SPDY. Однако их механизмы прямо противоположны.

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

В общем, НПН ушла со сцены истории. . . ALPN теперь является стандартным протоколом, определенным IETF. Конкретный процесс ALPN в TLS:

На этапе clientHello клиент добавит в сообщение поле ProtocolNameList. Используется для указания списка протоколов, которые он поддерживает.
На этапе serverHello сервер обрабатывает список ProtocolNameList, предоставленный клиентом. И выбираем самую старшую версию протокола, выполняем. Добавьте информацию о выборе в serverhello.

SNI

Полное имя SNI: Индикация имени сервера. Значение этого механизма заключается в том, что есть сервер, который одновременно обслуживает множество хостов. Это эквивалентно тому, что один IP-адрес отображает несколько доменных имен, но поскольку сертификат может быть действителен только для одного доменного имени третьего уровня, для нескольких хостов сервер может учитывать эти доменные имена одновременно. Простой способ - редирект на указанное доменное имя.Если вы хотите его поддерживать, вы также можете купить еще несколько сертификатов самостоятельно (настоящие местные тираны). Если вы очень богаты, сейчас такая ситуация, один IP-сервер оснащен сервером, который поддерживает несколько доменных имен, и каждое доменное имя имеет юридический сертификат CA. Итак, как сервер определяет, какой сертификат используется для какого доменного имени? В это время вам нужно использовать SNI. Это эквивалентно отправке узла вместе на этапе TLS, а затем сервер знает, какой сертификат вернуть на этапе serverhello. А теперь вопрос, зачем вам SNI? Напомним, что здесь мы просто устанавливаем соединение TCP+TLS, и некоторый контент клиента, например имя хоста, мы не можем получить по TCP. Однако, если вы хотите его получить, вам нужно дождаться этапа HTTP, чтобы получить данные от клиента.hostилиoriginполе. Поэтому, чтобы решить эту неловкую проблему, был предложен SNI.

Session Resumption

Я чувствую, что люди, которые могут видеть это здесь, должны быть праздными людьми. . . Если бы мне пришлось читать эту статью, я бы, наверное, просто закрыл сайт, увидев несколько картинок. Потому что это действительно сложно. Более того, вышесказанное — это просто сложность протокола, компьютеру нужно только каждый раз прописывать, что отправлять, а вот что действительно мучает компьютер, так это вычисление ключа. В частности, случайный ключ и предварительный секрет всегда представляют собой 32–48 Б данных. Поэтому для того, чтобы действительно снизить нагрузку на компьютер (фактически сервер), предлагается использовать идентификатор сеанса и билеты сеанса для кэширования содержимого сеанса успешного соединения.

Session ID

Идентификатор сеанса — это содержимое сеанса, которое сервер сохраняет на своем жестком диске при последнем успешном соединении. Здесь не используется вторичное шифрование данных сеанса. Основной процесс:

На этапе clientHello клиент отправляет на сервер случайное число, протокол TLS и последний идентификатор сеанса, соответствующий имени хоста. (То есть клиент также должен хранить данные сеанса)
После того, как сервер получает идентификатор сеанса, он ищет его в кеше и, если он найден, переходит непосредственно к этапу ChangeCipher и начинает генерировать sessionKey. Затем просто верните тот же идентификатор сеанса.

Таким образом, полное соединение TLS / SSL относительно, используется только однажды RTT. Тогда процесс становится соглашением:

Session Ticket

Поскольку Session ID предназначен для решения проблем с задержками в сети и производительностью компьютера, что делает Session Ticket? Билет сеанса и идентификатор сеанса делают то же самое: сервер дважды шифрует последние данные сеанса и передает их в конце предыдущего рукопожатия, после чего клиент сохраняет переданную информацию. Таким образом, клиент сам решает, использовать кэшированные данные сеанса или нет. Если срок действия данных сеанса не истек на этот раз, клиент отправит данные на этапе clientHello.После того, как сервер их получит, он начнет расшифровку.Затем обе стороны сгенерируют sessionKey и рукопожатие завершится. Итак, что такое Session Ticket и Session ID? Предполагается, что это зависит от вашей деловой ситуации. Идентификатор сеанса направлен на экономию производительности и использование некоторого пространства. Session Ticket фокусируется на экономии места при некоторой потере производительности. Оба они могут сэкономить время RTT, какой из них использовать, зависит от специфики вашего сервера.

Сведения о сертификате ЦС

В предыдущем разделе кратко объяснялось, как работает TLS/SSL и какие методы подключения доступны. Это равносильно тому, чтобы научиться рисовать линию: теперь мы знаем только, какой длины должна быть проведена линия, но еще не знаем, где ее провести. Итак, далее нам нужно изучить, что произошло на обоих концах. На самом деле не сложно, в основном по поводу хранения и проверки сертификата ЦС. Серверная часть очень проста, просто отправьте свой собственный сертификат CA, и все будет в порядке. Однако клиенту немного сложно проверить, является ли сертификат доверенным. Во-первых, существует ограниченное количество центров сертификации, другими словами, каждый центр сертификации представляет собой сертификат ЦС. Однако сегодня на рынке так много HTTPS-сайтов, все ли они используют один и тот же сертификат? Все ли они имеют один и тот же ключ pu/pr?Так что безопасность HTTPS по-прежнему полезна? Поэтому, согласно приведенным выше рассуждениям, HTTPS-сертификаты на нашем сайте должны быть другими. Вообще говоря, существует 3 типа сертификатов: DV (проверка домена), OV (проверка организации), EV (расширенная проверка). Средняя цена растет на порядок, поэтому самым дешевым является ДВ, который должен быть по карману нашим трудолюбивым беднякам. Конкретная разница между ними заключается в поддержке доменных имен:

ДВ: Это персональный сертификат, в основном он поддерживает одно- и многодоменные имена, но не поддерживает пандоменные имена (*.villainhr.com). Однако, если посмотреть на цену, например, у меня есть бесплатный сертификат DV, предоставленный Tencent Cloud, поэтому он поддерживает доменное имя третьего уровня (https://www.villainhr.com). Если он платный, должны поддерживаться одно/множественные доменные имена.
OV: Он более мощный, ориентирован на предприятия и поддерживает несколько доменных имен/пандоменных имен.
ЭВ: Он принадлежит дворянам, и простые люди не могут его получить, в основном, для этого нужно купить страховку. . .

Итак, какой уровень у нас в сертификате Yunyun? Обычно три. Как это проявляется?

Так много сертификатов, какой из них мы используем? Конечно, нижний. Поскольку каждый сертификат не является доверенным, клиент должен сначала понять, можно ли использовать ваш сертификат для проверки. Если нет, то на этот раз ваше соединение не является доверенным, нет绿色的小锁. Это требует понимания процесса аутентификации клиента.

Проверка цепочки ЦС

Прежде всего, что такое доверенный сертификат? Мы должны сначала понять истину, HTTPS сначала строится на взаимном доверии между людьми, а затем на взаимном доверии между машинами. Предположим, что корневой центр сертификации А злонамеренно передал ранее выданный сертификат другому不要脸Блокировка сайтов (например, за вставку рекламы). Таким образом, после того, как я получу этот сертификат, я смогу сам настроить сервер для перехвата просмотров, наблюдения за вашим сайтом и принудительной вставки рекламы. Это называется недоверенным центром/сертификатом. Возможность проверки обычно тесно связана с авторитетом учреждения. Кратко описан его основной процесс проверки (в соответствии с вышеприведенным уровнем):

www.villainhr.com Спросите TrustAsia DV SSL, можно ли доверять моему сертификату?
Правдоподобно! хорошо, продолжай. TrustAsia DV SSL спросил VeriSign Class 3, можно ли доверять моему сертификату?
Правдоподобно! хорошо, затем запустите соединение TLS/SSL.

Если есть проблема с любым из вышеперечисленных шагов, то на этот раз TLS/SSL не произойдет и будет откатываться. Итак, когда они спрашивают, будут ли они отправлять сетевые запросы? Нет~ Потому что, когда компьютер инициализируется, он поставляется со многими доверенными центрами сертификации (например, Root CA), который является центром сертификации VeriSign класса 3, который мы только что упомянули. И есть (меньше) вторичных учреждений, которые могут выдавать сертификаты. В это время браузер автоматически проверит сертификат на основе цифровой подписи.

Юридическая проверка ЦС

Как объяснялось выше, действительность сертификата ЦС — это восходящий метод проверки. Так каковы их конкретные протоколы проверки? Прежде чем мы поговорим об этом, давайте поговорим о нескольких понятиях:

Цифровая подпись: это значение, созданное путем шифрования открытого ключа подчиненного сертификата с помощью закрытого ключа органа, выдавшего сертификат. digital_sign = CA_pr_key + sub_Cer_ppu_key.
Расшифровка: Расшифруйте цифровую подпись с помощью открытого ключа органа, выдавшего сертификат, и сравните, согласуется ли открытый ключ подчиненного сертификата с расшифрованным значением.

Проверка CA сначала должна рассказать о процессе его выдачи:

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

Затем процесс проверки основан на этом:

Браузер анализирует соответствующую информацию подчиненного сертификата B и находит выдавший его орган и цифровую подпись.
Затем найдите выдавший сертификат A, используйте открытый ключ A для расшифровки цифровой подписи, а затем сравните открытый ключ подчиненного сертификата B. В случае успеха это законно, в противном случае - незаконно.

Приведенный выше трехуровневый уровень сертификата одинаков, и поиск можно выполнять сверху вниз. Конечно, иногда для скорости проверки делается некоторое кеширование, чтобы больше не требовалось никаких проверок. Поэтому, согласно приведенному выше описанию, некоторые детские туфли могут подумать, могут ли они самостоятельно подписать сертификат? Во всяком случае, браузер также находит его локально. конечно может,opensslВы можете создать свой собственный ЦС. Однако следует отметить, что создаваемый вами ЦС используется только на вашем собственном компьютере.Если вы хотите, чтобы ваш ЦС можно было использовать и на других компьютерах (что невозможно), то можно потратить деньги. Конкретный процесс может относиться к:Создайте свой собственный сертификат ЦС. В прошлом, используя Charles и Fiddler, я всегда задавался вопросом, как они будут превращать свои сертификаты в сертификаты выдающих органов.

Позже выяснилось, что именно содержание сертификата и должно быть в соответствующих полях в сертификате. Однако для некоторых расширенных сертификатов все же есть некоторые проблемы, например, wx.qq.com (WeChat)

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

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

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

CRL

CRL (Certificate Revocation List), то есть список отзыва сертификатов. Центр сертификации создаст список, содержащий серийные номера отозванных сертификатов в текущем цикле, и, когда сертификат будет проверен, он также проверит этот элемент. Если сертификат уже отозван, соединение TLS/SSL также не будет выполнено. Мы можем найти CRL URI из информации о сертификате:

Несмотря на простоту протокола, в нем все же есть много недостатков.

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

OCSP

OCSP (онлайн-протокол статуса сертификата), то есть онлайн-протокол статуса сертификата. Проверяется он-лайн запросом, для этого не нужно скачивать весь список, нужно только отправить серийный номер сертификата в ЦС для проверки. Конечно, также будет определенный период кэширования, когда проверка будет пройдена. Однако также будут задержки из-за проверки. Кроме того, развертывание OCSP также предъявляет определенные требования к ЦС: ЦС должен построить сервер для принятия проверки, а производительность сервера лучше (нагрузка большая).

OCSP stapling

Сшивание OCSP часто называют расширением запроса статуса сертификата TLS. Это еще одна реализация OCSP, поскольку первые два (OCSP, CRL) используются клиентом для проверки того, отозван ли сертификат, и оба отправляют запросы. OCSP (сшивание OCSP) проверяют действительность сертификата непосредственно на стороне сервера. Сервер будет периодически отправлять запросы в агентство ЦС для проверки достоверности иcertificateФаза, отправьте соответствующую информацию о подписи. Однако протокол основан на том факте, что мы полностью доверяем сервису, что исключает некоторые вредоносные промежуточные серверы. Для получения подробной информации см.:OCSP stapling.

TLS/SSL-оптимизация

Основная настройка производительности TLS/SSL просто включает в себя: включение False Start, OSCP Stapling, выбор соответствующего набора шифров, возобновление и т. д. Кроме того, если вы преследуетеfashion, то HTTP/2 должен быть хорошим выбором. Если вы хотите выполнить оптимизацию TLS/SSL, вы должны понимать, что представляет собой весь процесс рукопожатия TLS/SSL. Конечно, можно купить сертификат и самому построить сервер с нуля, но это только доказывает你很有钱Кроме того, ничто другое не доказывает этого. Потому что вы можете создать его в своей собственной интрасети ~ Вы можете обратиться к:10s Самостоятельный сертификат, Здесь мы объединяем nginx для специальной оптимизации рукопожатия TLS/SSL и делаем общую экспозицию.

Установить кэш сеанса

Параметр кэша сеанса может увеличить RTT в два раза, что эквивалентно удвоению скорости (исключая расчет ключа и т. д.). Для разных серверов существует множество способов установить сеанс, здесь мы возьмем nginx в качестве примера. В nginx поддерживается форма Session ID, то есть зашифрованный контент предыдущей сессии кэшируется на сервере. Задействовано два поля,ssl_session_cacheа такжеssl_session_timeout.

ssl_session_cache: используется для установки верхнего предела кеша сеанса и того, следует ли делиться им между несколькими рабочими процессами.
ssl_session_timeout: используется для установки времени хранения кэша сеанса

Посмотрите демо:

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 20m;

Смысл таков: кеш сеанса будет совместно использоваться разными воркерами, при условии, что 1 МБ может хранить только информацию о 8000 рукопожатиях. Таким образом, 10 МБ могут хранить в общей сложности 80 000 данных о рукопожатиях. В случае превышения оно не будет сохранено. Кэшированная информация существует в течение 20 минут. Также вы можете включитьsession ticket. ST (билет сеанса) требует параметр знака, который можно создать с помощью openssl.

$ openssl rand 48 > ticket.key
# 在 nginx 中开启
ssl_session_tickets on; 
ssl_session_ticket_key ticket.key;

Выберите правильный набор шифров

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

ssl_prefer_server_ciphers on;
ssl_ciphers xxx;

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

Наиболее благоприятным является использование:

// 让浏览器来决定使用哪一个套件(额。。。最后的手段)
ssl_ciphers  HIGH:!aNULL:!MD5;

В общем, вы сами должны решить, какой набор использовать, поэтому вам решать, безопасен он или нет. Для получения подробной информации см.Конфигурация пакета Mozilla. Вот простой, относительно безопасный, все следующие комплекты должны поддерживать Forwar Secrecy

ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5

Тем не менее, следующие наборы шифров лучше не использовать, потому что они в основном небезопасны:

aNULL: нестандартный пакет обмена ключами Диффи-Хелмана. легко быть中间人атака.
eNULL: без шифрования, обмен открытым текстом
ЭКСПОРТ: слабый метод шифрования, который использовался в первые дни в Соединенных Штатах.
RC4: использовать устаревший алгоритм ARCFOUR
DES: используйте устаревший стандарт шифрования данных.
SSLv2: набор шифров старой версии SSL2.0 (по крайней мере, вы также написали SSLv3)
MD5: напрямую использовать метод шифрования MD5.

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

False Start

Кроме того, как включить False Start в nginx? На самом деле это никак не связано с сервером, главное роль выбранного вами пакета и протокола NPN/ALPN.

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

Затем в nginx нам просто нужно выбрать подходящий набор шифрования. Вот уже готовый

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256::DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5';

Использовать обмен ключами DH

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

// 创建一个 DH param
openssl dhparam 2048 -out dhparam.pem

Затем вызовите файл

ssl_dhparam dhparam.pem;

Таким образом, вы официально открываете режим шифрования DH. Если вы используете инструмент захвата пакетов для наблюдения, DH должен находиться в состоянии приветствия сервера в это время:

Однако по историческим причинам параметр DH использовал длину 1024, например:Oakley group 2Версия. Теперь более популярным методом шифрования DH являетсяECDHE, который аналогичен предыдущему методу шифрования (DHE) будет намного быстрее в блоке генерации ключей. Точно так же, в силу исторических причин, его базовые условия относительно высоки: (на самом деле, это неплохо)

Android > 3.0.0
Java > 7
OpenSSL > 1.0.0

Включить сшивание OCSP

Сшивание OCSP — это средство проверки полномочий сертификата, и есть еще два типа CRL и OCSP. Однако все они должны быть проверены клиентом самостоятельно. OCSP Stapling, с другой стороны, помещает часть проверки на сервер и сокращает потребление сетевого времени за счет регулярной проверки. Чтобы включить OCSP Stapling, первое, что вам нужно, — это файл цепочки вашего сертификата, который используется для указания всех проверок (таких же, как два других метода проверки) от корневого сертификата до вашего сертификата. Итак, как получить файл цепочки? Просто спросите свой центр сертификации, это не секретный документ. Если это сертификат, выпущенный самостоятельно (используемый для вашего собственного тестирования), сгенерируйте его самостоятельно. Выставить все промежуточные сертификаты в соответствии сbottom to upв файл:

cat intermediate/certs/intermediate.cert.pem \
      certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem;

Тогда ca-chain.cert.pem — это файл проверки сшивания OSCP. Затем откройте его в nginx.

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate ca-chain.cert.pem;
resolver 8.8.8.8 8.8.4.4; // 默认使用 Google 的

Что касается разрешения DNS, вам также нужно спросить поставщика сертификата, конечно, это значение можно игнорировать. То же самое относится ниже

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate ca-chain.cert.pem;

После включения вы можете использоватьopenssl s_client -connect www.yourDomainName.com:443Давайте проверим его, чтобы увидеть, успешно ли он включен.

Включить HSTS

HSTS (HTTP Strict Transport Security) на самом деле является заголовком ответа, ничего особенного, конкретное содержание заключается в том, что все ваши внешние запросыhttps, так что есть проблема.Если адрес вашего изображения http, то окончательный результат станетhttps://xxx, это может привести к потере ресурсов, поэтому его нужно использовать с осторожностью.

Strict-Transport-Security: max-age=15768000 # 设定 6 个月的强制期

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

Использование SNI

SNI — это протокольный механизм, используемый, когда IP-адрес содержит много сертификатов, в основном для различения разных хостов и использования разных сертификатов. Детали SNI были упомянуты выше, поэтому я не буду здесь вдаваться в подробности. Основной используемый формат — другое имя_сервера с другим сертификатом.

server{
    server_name www.abc.com;
    ssl_certificate abc.crt;
    ssl_certificate_key abc.crt.key;
}
server{
    server_name www.def.com;
    ssl_certificate def.crt;
    ssl_certificate_key def.crt.key;
}

Как включить? Просто перейдите на более высокую версию nginx. вы можете использоватьnginx -VПроверьте, поставляется ли ваш nginx с

TLS SNI support enabled

Полный пример

Наконец, поставьте полный:

server {
        listen 443 ssl http2; # 默认打开 http2
        listen [::]:443 ssl http2;

        ssl_certificate /etc/nginx/cert/bjornjohansen.no.certchain.crt;
        ssl_certificate_key /etc/nginx/cert/bjornjohansen.no.key;

        ssl_session_cache shared:SSL:10m;
        ssl_session_timeout 20m;

        ssl_prefer_server_ciphers on;

        ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;

        ssl_dhparam /etc/nginx/cert/dhparam.pem;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

        ssl_stapling on;
        ssl_stapling_verify on;
        ssl_trusted_certificate /etc/nginx/cert/trustchain.crt;
        resolver 8.8.8.8 8.8.4.4; # 看情况选择 DNS IP

        #add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        # 我一般不开 HSTS
        # add_header Strict-Transport-Security "max-age=31536000" always;
}

Список литературы

Эта конфигурация также очень проста, вы можете получить более богатый контент от Mozilla. Для получения подробной информации см.:

wiki.Mozilla.org/security/TL…
wiki.Mozilla.org/security/Русский…
Боюсь, что не смогу.co/transport-come…

Кроме того, есть некоторые инструменты для тестирования и сборки, список также приведен здесь:

Touch Straight официальный тестовый инструмент
Получите прямой доступ к официальному инструменту создания конфигурации tls/ssl
Лаборатория SSL Инструмент для тестирования tls/ssl