Моя подруга также занимается программным обеспечением, но поскольку она вот-вот закончит учебу, она недавно изучила программирование во время работы над выпускным проектом. Два дня назад она спросила меня о HTTPS, и она хотела прямо бросить ей онлайн-учебник. Поразмыслив над этим, я обнаружил, что в большинстве этих статей прямо вводились понятия, которые не очень нравились новичкам, поэтому я просто объяснил ей это сам и, между прочим, составил вопросы и ответы.
Q1: Что такое HTTPS?
BS: HTTPS — это безопасный HTTP
Контент в протоколе HTTP передается в виде открытого текста, а цель HTTPS — шифровать этот контент для обеспечения безопасности передачи информации. Последняя буква S относится к протоколу SSL/TLS, который находится между протоколом HTTP и протоколом TCP/IP.
Q2: Что вы подразумеваете под безопасностью передачи информации?
БС: Есть три аспекта передачи информации:
- Прямую связь между клиентом и сервером могут понять только они сами, даже если третья сторона получит данные, они не смогут понять истинное значение информации.
- Хотя третья сторона не может понять данные, они могут быть изменены XJB, поэтому клиент и сервер должны иметь возможность определить, были ли данные изменены.
- Клиент должен избегать атак «человек посередине», т. е. никакая третья сторона не может выдавать себя за сервер, кроме настоящего сервера.
К сожалению, текущий протокол HTTP не соответствует ни одному из трех вышеперечисленных требований.
Q3: Утомительно ли выполнять столько требований одно за другим?
БС: Не устаешь, третье требование можно игнорировать
Да, я не шучу, вы можете пока игнорировать третье требование, так как оно фактически подчинено первому требованию. Все мы знаем, что для шифрования требуется пароль, а пароль не теряется в мире, но также должен быть согласован обеими сторонами посредством общения. Поэтому хорошо продуманный механизм шифрования неизбежно предотвратит вмешательство и подделку третьих лиц. Когда мы понимаем конкретный принцип шифрования, мы, естественно, можем проверить, соответствует ли он требованию, согласно которому «любое третье лицо не может выдавать себя за сервер».
Q4: Как зашифровать информацию?
BS: используйте симметричное шифрование
Симметричное шифрование можно понимать как обратимое преобразование исходных данных. НапримерHelloможет быть преобразован вIfmmp, правило состоит в том, что каждая буква становится следующей буквой в алфавите, и секретный ключ здесь1, другая сторона получаетIfmmpвосстановить исходную информациюHello.
После внедрения симметричного шифрования в процессе рукопожатия HTTPS будет еще два шага, которые используются для передачи секретного ключа симметричного шифрования:
- Клиент: Привет, мне нужно сделать запрос HTTPS
- Сервер: хорошо, ваш ключ
1.
Упоминается, что симметричное шифрование, затем, естественно, есть асимметричное шифрование. Мысль его очень проста, и произведение двух цен очень легко, но разбить на две цены сложно, приходится проделывать чрезвычайно сложные операции. Асимметричное шифрование имеет два ключа, один открытый ключ, другой закрытый ключ. Содержимое шифрования с открытым ключом может быть расшифровано только закрытым ключом, а содержимое, зашифрованное закрытым ключом, может быть расшифровано. Как правило, сервер мы оставляем сами, а ключ то не публикуем.закрытый ключ, который доступен каждому, называетсяоткрытый ключ.
Использование симметричного шифрования, как правило, намного быстрее, чем асимметричное шифрование, и вычислительная нагрузка на сервер намного меньше.
Q5: Как передать симметричный ключ
Небезопасно ли, чтобы сервер напрямую возвращал симметричный ключ шифрования в виде открытого текста? Если слушатель получает этот ключ, разве он не знает содержание последующего взаимодействия между клиентом и сервером?
BS: Использование асимметричного шифрования
Это так, поэтому симметричный ключ не может быть передан в виде открытого текста, и новый алгоритм симметричного шифрования не может быть использован для шифрования исходного симметричного ключа, иначе новый симметричный ключ не может быть передан.
Здесь мы вводим асимметричное шифрование.Характеристики асимметричного шифрования определяют, что содержимое, зашифрованное сервером с помощью закрытого ключа, ненастоящее шифрование, так как открытый ключ есть у всех, зашифрованный текст сервера может быть проанализирован всеми. Но закрытый ключ находится только в руках сервера, что дает два огромных преимущества:
- Контент, отправленный сервером, не может быть подделан, потому что ни у кого больше нет закрытого ключа, поэтому его нельзя зашифровать. Следствием принудительного шифрования является то, что клиент не может расшифровать его с помощью открытого ключа.
- Контент, зашифрованный кем-либо с открытым ключом, абсолютно безопасен, потому что закрытый ключ есть только у сервера, то есть только реальный сервер может видеть зашифрованный исходный текст.
Таким образом решается проблема передачи симметричного ключа: ключ не выдается сервером, а генерируется клиентом и активно сообщается серверу.
Поэтому, когда вводится асимметричное шифрование, процесс рукопожатия HTTPS по-прежнему является двухэтапным, но детали немного изменились:
- Клиент: Здравствуйте, мне нужно сделать HTTPS-запрос, это мой (зашифрованный с помощью открытого ключа) секретный ключ.
- Сервер: Хорошо, я знаю ваш секретный ключ, я использую его для передачи позже.
Q5: Как передать открытый ключ
Вы так и не решили проблему курицы и яйца. Вы сказали, что клиент использует открытый ключ для шифрования симметричного ключа при отправке запроса, как передать открытый ключ?
BS: Зашифруйте открытый ключ. . .
Каждый сервер, использующий HTTPS, должен зарегистрировать сертификат в специальном центре сертификации, а в сертификате хранится открытый ключ, зашифрованный закрытым ключом центра сертификации. Таким образом, клиент может расшифровать его с помощью открытого ключа уполномоченного органа.
Теперь фаза рукопожатия протокола HTTPS стала состоять из четырех шагов:
- Клиент: Здравствуйте, я хочу сделать HTTPS-запрос, дайте мне открытый ключ.
- Сервер: хорошо, это мой сертификат с зашифрованным открытым ключом.
- Клиент: после успешной расшифровки сообщить серверу: это мой симметричный ключ (зашифрованный открытым ключом).
- Сервер: Хорошо, я знаю ваш секретный ключ, я использую его для передачи позже.
Q6: Вы шутите? . . .
Как передать открытый ключ органа?
БС: в компьютере
Этот открытый ключ не нужно передавать, и он будет непосредственно встроен в заводские настройки основных операционных систем (или браузеров). Причина, по которой открытый ключ каждого сервера не встроен в компьютер, заключается в том, что нужно хранить слишком много серверов. С другой стороны, операционная система вам не доверяет, так почему вы говорите, что являетесь сертификатом Baidu/Taobao?
Поэтому каждая компания должна сначала обратиться в орган по сертификации и подать заявку на получение сертификата, а затем операционная система будет хранить только открытый ключ органа. Из-за ограниченного числа полномочий поставщиками операционных систем относительно легко управлять. Если этот орган недостаточно авторитетен, XJB дисквалифицироват его, выдав сертификат, как, например, у бедняги Wotong. . . .
Q7: Как я узнаю, что сертификат был подделан?
Вы сказали, что сервер вернет сертификат в первый раз, то есть открытый ключ после шифрования, так откуда мне знать, что сертификат надежен?
BS: передать хеш-значение сообщения вместе с сообщением
Мы все знаем характеристики алгоритма хеширования.Он может сжимать данные.С функциональной точки зрения, независимо от того, насколько сложны данные (область определения может быть очень большой), значение будет получено с помощью алгоритма хеширования, и это значение находится в определенном диапазоне значений (намного меньше диапазона домена). Результаты хеширования одних и тех же данных должны быть одинаковыми, а результаты хеширования разных данных вообще разные, но есть небольшая вероятность того, что они будут повторяться, что называется коллизией хэшей.
Чтобы гарантировать, что исходный сертификат не был подделан, мы можем передать хэш сертификата вместе с сертификатом. Поскольку третья сторона не может анализировать данные, они могут быть изменены только XJB, поэтому измененные данные не могут передать хэш после расшифровки.
Например, открытый ключ — это предыдущий пример.Hello, мы предполагаем, что алгоритм хеширования должен получить последний символ строки, тогдаHelloХэш-значениеo, поэтому зашифрованная строкаIfmmpp. Хотя открытый ключ известен, каждый может его расшифровать, а также его можно подделать после расшифровки, но из-за отсутствия закрытого ключа его нельзя правильно зашифровать. Следовательно, данные, которые он возвращает клиенту, являются недействительными, и после анализа с помощью открытого ключа будут получены искаженные символы. Даже если злоумышленнику удастся разобрать его после многих попыток, он не пройдет проверку хэша.
Q8: Может ли это помешать третьим лицам выдавать себя за сервер?
БС: возможно
Прежде всего, содержимое, отправленное настоящим сервером, не может быть изменено другими. У них есть открытый ключ авторитета, поэтому они могут его расшифровать, но поскольку закрытого ключа нет, расшифрованная информация не может быть зашифрована. После того, как незашифрованная или неправильно зашифрованная информация расшифрована клиентом с помощью открытого ключа, она должна пройти проверку хэша.
Однако, если вы в первую очередь запрашиваете не настоящий сервер, а злоумышленник, у него есть полная возможность выполнить атаку «человек посередине». Мы знаем, что при первом рукопожатии сервер выдаст сертификат для подтверждения своей личности, и этот сертификат будет расшифрован с помощью предустановленного открытого ключа на устройстве. Таким образом, либо сертифицированный сертификат шифруется с помощью закрытого ключа уполномоченного органа, затем расшифровывается с помощью уполномоченного органа, либо зашифровывается с помощью закрытого ключа не уполномоченного органа, а затем не может быть найден открытый ключ для расшифровки.
Таким образом, если корневой сертификат неавторизованной организации, такой как вредоносный сертификат, предоставленный хакером, случайно установлен, на устройство добавляется открытый ключ по умолчанию, и сертификат, зашифрованный с помощью вредоносного закрытого ключа, может быть проанализирован обычным образом. . Так что не устанавливайте корневой сертификат случайно, это равносильно тому, что вы оставляете дверь для этих вредоносных сертификатов.
Конечно, у всего есть две стороны. Мы знаем, что Charles может отлаживать HTTPS-соединение, принцип заключается в том, что пользователю необходимо установить корневой сертификат Charles, и тогда наш запрос будет проксироваться на сервер Charles, и выданный им сертификат Charles может быть корректно разобран. С другой стороны, Чарльз будет выступать в роли клиента и получать правильный https-сертификат от реального сервера и использовать его для последующей связи. К счастью, Charles не является мошенническим программным обеспечением, и в случае утечки его закрытого ключа это окажет большое влияние на пользователей.
Могу привести пример.Существует много типов сертификатов.Самый дорогой из них EV(Extended Validation),который требует несколько документов,таких как бизнес лицензия компании для подачи заявления на ручную проверку.Преимущества также очевидны.Его можно точно определить. отображается в левой части адресной строки браузера. Отображает название компании, например.официальный сайт битбакета:
Это нормальное явление, когда клиент подключен напрямую. Но если вы используете прокси-сервер Charles, клиент получает сертификат Charles, поэтому он становится:
Вопрос 9. Повлияет ли рукопожатие HTTPS на производительность?
TCP имеет трехстороннее рукопожатие, а также четырехстороннее рукопожатие HTTPS, повлияет ли это на производительность?
БШ: Влияние определенно есть, но оно приемлемо.
Во-первых, HTTPS определенно будет медленнее.Время в основном тратится на время между двумя наборами SSL и проверкой чтения сертификата.Время шифрования и дешифрования симметричного алгоритма практически ничтожно.
И если это не первое рукопожатие, последующие запросы не требуют полного процесса рукопожатия. Клиент может напрямую отправить последнее шифрование на сервер для быстрого восстановления.Графический протокол SSL/TLS.
Кроме того, время рукопожатия SSL используется не только для передачи зашифрованной информации, но также может выполнять задачу обеспечения совместимости HTTP2 между клиентом и сервером. Таким образом, переход с HTTPS на HTTP2.0 не повлияет на производительность, наоборот, благодаря таким технологиям, как мультиплексирование HTTP2.0, в будущем можно сэкономить много времени.
Если в качестве цели используется HTTPS2.0, то потеря производительности HTTPS будет меньше, гораздо меньше, чем улучшение безопасности, которое он дает.
Эпилог
Я считаю, что приведенных выше девяти вопросов достаточно, чтобы помочь новичкам понять HTTPS, но это всего лишь основные понятия, и использование HTTPS (например, некоторые конкретные проблемы на iOS) необходимо постоянно пробовать и исследовать.
В конце статьи есть объявление о работе, которое действует уже давно.Моя девушка закончила в этом году, а вступительный экзамен в аспирантуру 380+.Резюме нажмите здесь, Компьютерная основа все еще прочная, но опыт проекта относительно невелик, и его можно практиковать более 6 месяцев. Если в Пекине есть компания, которая хочет набрать стажеров, милости просим обращаться ко мне, ограничений по направлению нет, обучать можно как фронтенд, так и бэкенд, iOS лучше (обучаю сам).