В этой статье речь пойдет о принципе шифрования и дешифрования HTTPS.Многие знают RSA, думают, что HTTPS = RSA, и используют RSA для шифрования и дешифрования данных.На самом деле это неправильно. HTTPS использует RSA для аутентификации и обмена ключами, а затем использует обменный ключ для шифрования и расшифровки данных. Аутентификация — это асимметричное шифрование с использованием RSA, а передача данных — это симметричное шифрование с использованием одного и того же ключа для обеих сторон. Итак, что такое симметричное шифрование и асимметричное шифрование?
1. Симметричное и асимметричное шифрование
Предположим, Сяо Ван хочет пригласить Сяохуна на свидание, но не хочет, чтобы об этом узнал Сяохун, поэтому он хочет использовать симметричное шифрование, чтобы передать небольшую записку Сяохун, как показано на следующем рисунке:
Данные, которые он хочет отправить, — «Встреча в 17:00» (встреча в 5 часов, если это китайский язык, вы можете использовать кодировку UTF-8), а метод шифрования — прямой сдвиг влево или вправо в Таблица ASCII. Ключ равен 3, что означает, что он сдвинут на 3 бита назад в таблице ASCII, и он станет "Phhw#dw#8=33#SP", поэтому обычные люди не знают, что это значит, если они перехватить его. Но мы можем подумать об этом, если он может захватить ваши данные, он также может перехватить ваш ключ и расшифровать его, как показано на следующем рисунке:
Поэтому Сяо Ван намеревается использовать асимметричное шифрование.Характеристикой асимметричного шифрования является то, что обе стороны имеют свои собственные пары открытого и закрытого ключей, в которых открытый ключ отправляется другой стороне, а ключ не обменивается и хранится без утечки, как показано на следующем рисунке:
Среди них открытый ключ Xiaohong:
public_key = (N, e) = (3233, 17)
Она отправила открытый ключ Сяо Мину, а ее собственный закрытый ключ:
private_key = (N, e) = (3233, 2753)
Обратите внимание, что и открытый ключ, и закрытый ключ представляют собой два числа, N обычно представляет собой большое целое число, а e представляет показатель степени. Теперь Сяо Ван хочет отправить сообщение Сяохуну, поэтому он шифрует его с помощью открытого ключа Сяохуна.Как его зашифровать? Первая буква, которую он хочет отправить, это t = «M», код ASCII «M» — 77, а процесс шифрования 77 рассчитывается следующим образом:
T = 77 ^ e % N = 77 ^ 17 % 3233 = 3123
Возведите 77 в степень e, а затем по модулю N, чтобы получить T = 3123, затем отправьте это число Сяохуну (другие буквы обрабатываются таким же образом). Получив T, Сяохун расшифровывает его своим закрытым ключом.Расчет выглядит следующим образом:
t = T ^ e % N = 3123 ^ 2753 % 3233 = 77
Метод расчета тот же, поэтому T уменьшается до t. Пока открытый и закрытый ключи являются парными, расчет выше сертификата может быть установлен с помощью некоторых математических формул. Это принцип шифрования и дешифрования RSA.Если закрытый ключ неизвестен, правильная дешифрация невозможна. И наоборот, шифрование закрытым ключом и дешифрование открытым ключом также возможно.
Итак, как HTTPS использует RSA для шифрования и дешифрования?Начнем с процесса установления соединения HTTPS.
2. Процесс установления HTTPS-соединения
HTTPS в основном выполняет следующие функции:
- 1. Подтвердите личность поставщика услуг. Например, когда я посещаю google.com, это действительно сервер Google.
- 2. Предотвратите захват данных, например, некоторые операторы будут вставлять рекламу в http-страницы.
- 3. Предотвращение кражи и подделки конфиденциальных данных и т. д.
Как говорится в комментарии openssl, это единственный способ предотвратить атаки «человек посередине»:
В качестве примера возьмем веб-сайт MDN (https://developer.mozilla.org), а затем используем wireshark для захвата пакетов, чтобы наблюдать за процессом установления соединения HTTPS, как показано на следующем рисунке:
Первый - это трехстороннее рукопожатие TCP, а затем клиент (браузер) инициирует запрос на установление соединения HTTPS.Клиент сначала отправляет пакет приветствия клиента, затем сервер отвечает приветствием сервера, а затем отправляет свой сертификат клиенту. , а затем обе стороны После обмена ключами, наконец, используйте обменный ключ для шифрования и расшифровки данных.
В Client Hello клиент сообщает серверу свою текущую информацию, как показано на следующем рисунке:
Включая версию TLS, которую будет использовать клиент, поддерживаемый набор шифрования, доменное имя, к которому будет осуществляться доступ, случайное число (Nonce), сгенерированное для сервера, и т. д. Необходимо заранее сообщить серверу доменное имя, к которому он хочет получить доступ, чтобы сервер мог отправить сертификат соответствующего доменного имени, поскольку в это время HTTP-запроса не поступало.
Сервер выдаст несколько ответов в Server Hello:
Набор шифрования, выбранный сервером, называется TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, что означает:
(1) Обмен ключами использует ECDHE
(2) Алгоритм подписи сертификата RSA
(3) Шифрование данных с использованием AES 128 GCM
(4) SHA256 используется для проверки подписи.
Затем сервис отправляет клиенту 4 сертификата:
Общее имя первого сертификата — доменное имя developer.mozilla.org, которое мы сейчас посещаем.Если общее имя *.mozilla.org, то этот сертификат можно использовать для всех поддоменов второго уровня mozilla.org. Второй сертификат — это сертификат органа, выдавшего (CA) первого сертификата, которым является Amazon, что означает, что Amazon будет использовать свой закрытый ключ для подписи developer.mozilla.org. И так далее, третий сертификат подпишет второй сертификат, четвертый сертификат подпишет третий сертификат, и мы видим, что четвертый сертификат является корневым сертификатом.
Что будет в сертификате, мы можем развернуть первый сертификат, чтобы увидеть, как показано ниже:
Сертификат состоит из трех частей: tbsCertificate (сертификат для подписания), содержимое сертификата, который необходимо подписать, алгоритм подписи сертификата и подпись, предоставленная ЦС. Другими словами, ЦС будет использовать свой закрытый ключ для подписи tbsCertificate и поместить его в часть подписи. Почему сертификат должен быть подписан? Подпись нужна для подтверждения личности.
3. Аутентификация
Давайте сначала посмотрим, что находится в tbsCertificate, как показано на следующем рисунке:
Он включает открытый ключ сертификата, применимое общее имя сертификата, срок действия сертификата и его эмитента. Сертификат Amazon также имеет вышеуказанную структуру.Мы можем скопировать открытый ключ сертификата Amazon, как показано на следующем рисунке:
В середине есть несколько дополненных чисел, представленных серыми словами. Вы можете видеть, что N обычно представляет собой большое целое число (2048 бит в двоичном формате), тогда как e обычно равно 65537.
Затем мы используем открытый ключ этого ЦС для расшифровки подписи сертификата mozilla.org, метод аналогичен приведенному выше:
Возьмите последние 64 бита шестнадцатеричного шестнадцатеричного числа расшифрованного числа, которое представляет собой хеш-подпись SHA из 256 битов в двоичном виде. Затем мы вручную вычисляем хеш-значение SHA256 для tbsCertificate, экспортируя tbsCertificate в необработанный двоичный файл в wireshark:
Затем используйте openssl для вычисления его хеша следующим образом:
liyinchengs-MBP:https liyincheng$ openssl dgst -sha256 ~/tbsCertificate.bin
SHA256(/Users/liyincheng/tbsCertificate.bin)= 5e300091593a10b944051512d39114d56909dc9a504e55cfa2e2984a883a827d
мы обнаруживаемЗначение хеш-функции, рассчитанное вручную, совпадает со значением хеш-функции в зашифрованном сертификате.! Это означает, что только тот, кто знает закрытый ключ Amazon, может правильно подписать сертификат mozilla.org, потому что открытый и закрытый ключи являются единственным совпадением. Итак, мы проверили, что первый сертификат, mozilla.org, действительно был выдан вторым сертификатом, Amazon, и таким же образом мы смогли убедиться, что Amazon был выдан третьим сертификатом, который был выдан четвертым корневым сертификатом. И четвертый сертификат — это корневой сертификат, встроенный в операционную систему (его можно просмотреть с помощью инструмента связки ключей Mac):
Если хакер указывает доменное имя, которое вы посещаете, на свою машину с помощью спуфинга DNS или тому подобного, он подделывает сертификат. Однако, поскольку корневой сертификат встроен в операционную систему, он не может изменить открытый ключ подписи, и у него нет правильного закрытого ключа, поэтому он может использовать только свой собственный закрытый ключ Информация непротиворечива. Или напрямую переместить сертификат, полученный браузером, на его собственный сервер? Таким образом, сертификат, выданный браузеру, точно такой же, но поскольку он не знает приватного ключа сертификата, он не может выполнять последующие операции, так что это бессмысленно.
Вот как HTTPS может подтвердить личность.
Другой пример - SSH. Необходимо вручную проверить правильность подписи. Например, позвонив или отправив электронное письмо, чтобы сообщить серверу, соответствует ли подпись подписи сертификата, рассчитанной самостоятельно. Ключ не был изменен. к открытому ключу Хакера):
Значение, показанное выше, вычислено вручную. Сравните это значение с предыдущим значением, чтобы убедиться, что отправленный сертификат не был изменен.
Так почему бы просто не использовать пару ключей RSA для шифрования данных? Поскольку значение пары ключей RSA слишком велико, оно не подходит для частого шифрования и дешифрования данных, поэтому требуется ключ меньшего размера.Другая причина заключается в том, что сервер не имеет ключа браузера или клиента и не может отправлять зашифрованные данные. данные в браузер (Вы не можете зашифровать с помощью собственного закрытого ключа, потому что открытый ключ является открытым). Поэтому требуется обмен ключами.
4. Обмен ключами
Существует два метода обмена ключами: RSA и ECDHE.Метод RSA относительно прост.Браузер генерирует ключ, а затем использует открытый ключ сертификата RSA для его шифрования и отправки на сервер, а сервис использует свой ключ чтобы расшифровать его.Ключ, так что ключ может быть передан, его недостаток заключается в том, что, хотя злоумышленник не может взломать его в процессе отправки, если он сохраняет все зашифрованные данные, закрытый ключ не сохраняется до истечения срока действия сертификата.Если он происходит утечка, то он может использовать этот закрытый ключ для расшифровки всех данных, которые были переданы ранее. Использование ECDHE является более безопасным алгоритмом обмена ключами. Как показано на рисунке ниже, две стороны обмениваются ключами через ECDHE:
Полное название ECDHE — Обмен ключами Диффи-Хеллмана на эллиптических кривых. Это улучшение алгоритма обмена ключами Диффи-Хеллмана. Идея этого алгоритма показана на следующем рисунке:
Сложность ЭК заключается в заданных исходной точке G и точке K:
K = kG
Получить k очень сложно (k достаточно велико). Это k — закрытый ключ, а K = kG — открытый ключ. Как ECC шифрует и расшифровывает данные?
Предполагая, что данные, которые нужно зашифровать, равны m, возьмите эту точку в качестве координаты x, чтобы получить точку M на кривой, выберите случайное число r и вычислите точки C1 = rG, C2 = M + rK, и эти две точки Зашифрованные данные отправляются другой стороне, а другая сторона использует закрытый ключ k для их расшифровки после получения.Процесс выглядит следующим образом:
M = C2 - rK = C2 - rkG = C2 - rkG = C2 - kC1
С помощью приведенного выше расчета можно восстановить и получить M. Люди, не знающие закрытый ключ k, не могут его расшифровать. Более подробную информацию можно найти в этой статье "средний"ECC elliptic curve encryption".
Таким образом, мы понимаем принцип ECC, так как же использовать ECC для обмена ключами?
6. Обмен ключами ЕСС
Принцип очень прост, как показано на следующем рисунке:
То, что раньше меняло числа в степени двойки, теперь меняет местами точки на двух кривых.
Задается уравнение кривой. Например, уравнение кривой, используемое Curve X25519, имеет вид: y^2 = x^3 + 486662x^2 + x. Используемое уравнение кривой будет указано при обмене ключами, как показано на следующем рисунке. :
Уравнение кривой, используемое mozilla.org, — secp256r1, которое также является более популярным, и его параметры намного больше, чем у кривой X25519. Обмен ключами также использует закрытый ключ сертификата для подписи, чтобы гарантировать, что обмениваемый ключ не будет подделан, но закрытый ключ здесь — это собственный закрытый ключ Mozilla.
То есть с момента установления соединения до настоящего времени оно передается открытым текстом. Затем обе стороны отправляют пакет Change Cipher Spec, чтобы уведомить, что следующие пакеты будут зашифрованы в соответствии с ранее согласованным методом. На этом этапе все безопасное соединение установлено.
7. Применение сертификата HTTPS
Итак, кто занимается шифрованием HTTPS? Сервер обычно выполняется обратными прокси-серверами, такими как Nginx и Apache, и конкретный бизнес-сервер не нуждается в обработке.Клиент обычно шифруется и расшифровывается браузером и т. д. Chrome использует скучную библиотеку SSL, которая является ответвлением от опенсл.
Мы можем подать заявку на бесплатный сертификат TLS через let's encrypt, который необходимо обновлять вручную каждые месяцы 3. Существует три типа сертификатов: DV, OV, EV, DV подходит для физических лиц, OV и EV требуют проверки личности, а EV является самым высококлассным. Сертификат EV будет отображать корпоративное имя сертификата в адресной строке браузера:
Но новая версия Chrome, похоже, удалила это, поэтому мы можем увидеть подсказку, когда открываем среднюю консоль:
As part of an experiment, Chrome temporarily shows only the lock icon in the address bar. Your SSL certificate with Extended Validation is still valid.
Кроме того, мы можем сгенерировать самоподписанный сертификат с помощью openssl, выполнив следующую команду:
openssl req -x509 -nodes -sha256 -days 365 -newkey rsa:2048 -keyout test.com.key -out test.com.crt
Вы получите два файла, test.com.crt — это сертификат, test.com.key — закрытый ключ сертификата, как показано на следующем рисунке:
Затем используйте эти два файла для nginx, чтобы использовать доступ https, как показано в следующем коде:
server {
listen 443;
server_name test.com;
ssl on;
ssl_certificate test.com.crt;
ssl_certificate_key test.com.key;
}Вы можете добавить этот сертификат в системный сертификат, чтобы браузеры могли доверять ему, или вы можете напрямую использовать инструмент mkcert за один шаг.
8. Сертификат клиента
Существует также сертификат, называемый клиентским сертификатом.Также необходимо подать заявку на получение клиентского сертификата в агентстве CA.Отличие от серверного TLS-сертификата заключается в том, что серверный сертификат обычно привязан к доменному имени, а клиентский сертификат может быть данный локальный Подписать любой исполняемый файл. Алгоритм проверки подписи такой же, как и для TLS-сертификата, рассмотренного выше. Почему исполняемый файл должен быть подписан, потому что, если он не подписан, система перехватит установку или операцию, например, запрос Mac на двойной щелчок по неподписанному пакету dmg:
Это не позволит вам запустить напрямую, и в Windows тоже есть подобные подсказки:
И окна выдадут предупреждение:
И когда мы запускаем подписанный exe-файл, это будет обычное приглашение, такое как приглашение Chrome:
Таким образом, в этой статье в основном обсуждаются принципы симметричного и асимметричного шифрования, а также рассказывается, как использовать RSA для проверки подписи сертификата для проверки подлинности подключающегося сервера, как использовать ECC для шифрования данных и обмена ключами, а также как генерировать и использовать сертификаты HTTPS и вводить клиентские сертификаты в разделе. Я считаю, что после прочтения этой статьи у вас будет более полное представление о шифровании и дешифровании HTTPS.Я также написал введение в HTTPS ранее, и эта статья добавляет больше деталей.