Зеленый замок демистифицирует: как работает рукопожатие SSL?

Каждый день, просматривая Интернет с заботой о безопасности, вы думаете о знаменитом зеленом замке рядом с URL-адресом веб-сайта в вашем браузере и версии протокола передачи данных HTTPS. В этой статье мы узнаем, почему HTTPS действительно безопасен и как связь защищена от прослушивания третьей стороной.

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

Криптография с открытым ключом 101: пара ключей

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

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

Криптография с симметричным ключом

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

Каковы основные преимущества и недостатки криптографии с симметричным ключом?

Криптография с асимметричным ключом

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

Каковы плюсы и минусы криптографии с асимметричным ключом?

Поскольку асимметричная криптографическая установка более безопасна, Алиса и Боб решили использовать ее! Теперь они могут использовать это и начать думать об обеспечении безопасности и целостности связи.

Криптография с открытым ключом 101: Шифрование

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

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

Примечание:

• Шифрование сообщения — отправитель шифрует сообщение открытым ключом получателя.
• Расшифровка сообщения — получатель расшифровывает сообщение своим закрытым ключом.

Криптография с открытым ключом 101: Подпись

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

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

Затем, когда Боб получает сообщение и подпись, он может сначала расшифровать подпись с помощью открытого ключа Алисы. Когда это удается, он знает, что подпись действительно была сгенерирована Алисой (иначе расшифровка с помощью ее открытого ключа не удалась).

Во-вторых, Боб может взять сообщение и хешировать его, используя тот же алгоритм, что и у Алисы, и подтвердить, что его хэш сообщения такой же, как тот, который был сгенерирован Алисой. Когда хэши совпадают, он знает, что сообщение не было подделано.

Примечание:

• Генерация подписи — отправитель шифрует (подписывает) хэш сообщения своим закрытым ключом и создает подпись
• Проверка подписи - получатель сначала расшифровывает хеш сообщения из подписи и проверяет, совпадает ли вычисленный им хэш с хэшем из подписи.
• Шифрование и подпись можно использовать по отдельности , но для максимальной безопасности их обычно комбинируют. Поэтому большинство криптографических функций, которые вы можете встретить, называются encryptSignMessage() , decryptVerifyMessage() и т. д.

Надеюсь, у вас не возникнет проблем с изучением истории Алисы и Боба. Позвольте мне еще раз проиллюстрировать весь процесс, чтобы убедиться, что все ясно, и подвести итог.

1. Алиса хочет отправить сообщение Бобу
2. Алиса берет свой закрытый ключ и генерирует подпись
3. Алиса берет открытый ключ Боба и шифрует сообщение.
4. Алиса отправляет сообщение Бобу
5. Боб берет открытый ключ Алисы и проверяет подпись
6. Боб использует свой закрытый ключ для расшифровки сообщения.

Ладно, хватит теории. Теперь посмотрим, как все это используется в HTTPS!

SSL-рукопожатие

Привет, пожалуйста

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

Самое главное, сообщение содержит криптоалгоритмы, которые понимает клиент, и некоторые дополнительные материалы, такие как поддерживаемые алгоритмы сжатия, версии протокола, идентификатор сеанса и т. д. Поскольку сервер любит быть вежливым, он также отвечает сообщением приветствия сервера, которое особенно заметно содержит сертификат сервера с открытым ключом сервера (да, процесс основан на криптографии с открытым ключом — тот же метод, который выбрали Алиса и Боб).

Центр сертификации

Теперь пришло время поприветствовать нашего следующего гостя на сцене: центр сертификации (ЦС). Название звучит серьезно, но это просто сторонняя организация с большим количеством уличных кредитов, которая в основном считается заслуживающей доверия во всем мире. Такой объект может подтвердить подлинность сервера и поместить свою цифровую подпись вместе с сертификатом сервера (аналогично Алисе при обмене сообщениями с Бобом).

Проверка сертификата

Теперь давайте, наконец, рассмотрим зеленый замок рядом с URL-адресом вашего браузера.

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

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

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

Следовательно, даже если кто-то предъявит украденный сертификат открытого ключа , это шаг, который он не пройдёт. Действительный закрытый ключ, привязанный к открытому ключу сертификата сервера, необходим для расшифровки симметричного ключа. Конечно, это не проблема для законного сервера, поскольку на нем надежно сохранен закрытый ключ. Его можно использовать для расшифровки симметричного ключа и шифрования дальнейшего обмена данными.

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

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

Проверка сертификата клиента

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

Это работает так же, но на этот раз клиент отправляет свой сертификат , а сервер просматривает список доверенных центров сертификации и проверяет его. Также стоит отметить, что сервер находится под контролем разработчиков (в отличие от клиента, т.е. веб-браузера или мобильной операционной системы), поэтому разработчики бэкенда могут легко изменять список доверенных сертификатов.

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

Давайте рассмотрим наши серверные решения

Читать далее

Теперь, подытоживая, давайте посмотрим на схему всего потока:

Резюме

Вы дошли до конца статьи! Надеюсь, вы уже понимаете механизм реализации настройки шифрования в HTTPS и прикладные методы процессов подписи и шифрования.

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