Нужно некоторое понимание Https
Извините, если этот вопрос действительно наивный, но я искал столько, сколько мог, не находя соответствующих ответов.
Я провел последние три дня, пытаясь понять, как работает https. Все, что я знал до этого, - это как работает симметричная и асимметричная криптография. Пришло время понять, как эти два параметра применяются в ssl-https, и выполнить так называемое шифрование данных и проверку подлинности сервера.
Все понятно в отношении шифрования данных и предотвращения атак "человек посередине"
Кажется, что я не совсем понимаю, как работает проверка подлинности сервера, поэтому ваша помощь будет высоко оценена.
Мое понимание до сих пор заключается в следующем:
Когда клиент подключается к серверу через https, сервер отправляет подписанный сертификат CA. Этот сертификат сервера представляет собой текстовый файл, содержащий информацию о сервере (имя, адрес электронной почты владельца, открытый ключ и т. Д.), А также цифровую подпись.
Эта подпись является хешем содержимого серверной информации, зашифрованным личным ключом CA.
Клиент проверяет действительность подписи, снова производя - на свой собственный - хэш информации о сервере и расшифровывая подпись, используя открытый ключ ЦС. Если дешифрованное значение подписи совпадает с созданным хешем, подпись и сертификат впоследствии действительны.
Обратите внимание, что публично-частная схема шифрования имеет двойственную природу. Сообщение может быть зашифровано открытым ключом и расшифровано закрытым ключом. Это же сообщение может быть зашифровано с помощью закрытого ключа и расшифровано также с помощью открытого ключа.
Мы должны помнить, что сертификат является статическим файлом, который нельзя изменить. Любое изменение в файле приведет к несоответствию подписи.
Сейчас я опишу способ обмануть https:
Допустим, есть сайт ebanking с URL = https://wwww.thebank.com/ebanking (публичный IP = 195.134.0.1). Я подключаюсь к этому URL, и мой браузер получает сертификат сервера. (TheBank.cer)
В то же время я владелец интернет-кафе. Мое интернет-кафе имеет свой собственный маршрутизатор, DNS и DCHP-серверы, которые я могу контролировать. У него также есть веб-сервер.
Я настраиваю веб-сервер на собственный IP 195.134.0.1, так же как и банк, я создаю маршрут к маршрутизатору, который отправляет запросы на соединение для 195.134.0.1 на мой веб-сервер. Я настраиваю свой DNS, чтобы указывать вышеуказанный URL-адрес банка на 195.134.0.1(мой веб-сервер) Я размещаю мошеннический сайт банка на своем веб-сервере. Для любых подключений на этом сайте я приказываю веб-серверу отправлять клиенту сертификат, который я скачал ранее. (TheBank.cer)
Пользователь заходит в мое кафе, подключается к моей сети и пытается подключиться к этому банку. Мой сервер отправляет ему сертификат банка. Его браузер подтвердит действительность сертификата, поскольку он действительно действителен, и разрешит подключение к моему поддельному веб-сайту, поскольку его URL, IP и имя хоста совпадают с реальным.
Так что мое мошенничество успешно.
Конечно, эта дыра в безопасности слишком очевидна, чтобы быть правдой. Это значит, что я не понял что-то в этой процедуре проверки подлинности сервера. Может кто-нибудь объяснить мне, что мне здесь не хватает?
3 ответа
Пользователь заходит в мое кафе, подключается к моей сети и пытается подключиться к этому банку. Мой сервер отправляет ему сертификат банка. Его браузер подтвердит действительность сертификата, поскольку он действительно действителен, и разрешит подключение к моему поддельному веб-сайту, поскольку его URL, IP и имя хоста совпадают с реальным.
Как только его браузер подтвердил действительность, он узнает реальный открытый ключ банка, поскольку он есть в сертификате. Поскольку ваш сервер не может ничего подписать с помощью закрытого ключа, соответствующего этому открытому ключу, и вы не можете расшифровать что-либо, зашифрованное этим открытым ключом, вы не можете выдать себя за банк вообще. Все, что вы можете сделать, это убедить пользователя в подлинной идентичности банка, которую вы не можете выдать.
Я думаю, что ключевая вещь, которую вы упускаете, заключается в том, что основная цель сертификата состоит в том, чтобы доверенный орган связывал действительную идентификацию с открытым ключом, так что только владелец этой реальной идентификации знает соответствующий закрытый ключ.
theBank.cer это открытый ключ.
Вы не можете использовать это, чтобы расшифровать или подписать что-либо.
Эта подпись является хешем содержимого серверной информации, зашифрованным личным ключом CA.
Клиент проверяет действительность подписи, снова производя - на свой собственный - хэш информации о сервере и расшифровывая подпись, используя открытый ключ ЦС. Если дешифрованное значение подписи совпадает с созданным хешем, подпись и сертификат впоследствии действительны.
Это более или менее то, что происходит с RSA, но не с DSA, который является только подписью (без шифрования).
В общем, не стоит говорить о "шифровании" с помощью закрытого ключа. Это не имеет никакого смысла, поскольку любой сможет расшифровать с помощью открытого ключа (поскольку он является открытым). Шифрование - это сокрытие информации.
Что вы можете сделать с закрытым ключом - это подписать и расшифровать / расшифровать. Что вы можете сделать с открытым ключом, зашифровать и проверить подпись.
Если вы перепутаете, когда требуется шифрование и когда требуются подписи (несмотря на то, что алгоритм очень похож на RSA), вы можете в конечном итоге разработать системы, которые не обеспечивают никакой безопасности.
В более общем смысле, цель сертификата открытого ключа (сертификата X.509 или даже сертификата PGP) состоит в том, чтобы связать идентичность (например, имя хоста сервера) с открытым ключом. (См. Этот вопрос на Security.SE.)
Данные, которые получит мой веб-сервер, будут зашифрованы открытым ключом банка.
Обратите внимание, что трафик SSL/TLS не шифруется с использованием закрытого ключа сертификата, а совместно используемые ключи согласовываются во время рукопожатия SSL/TLS.
Во время рукопожатия SSL/TLS этот открытый ключ используется либо для шифрования предварительного мастер-секрета, либо для подписи других параметров (в зависимости от набора шифров), которые в конечном итоге доказывают клиенту, что он взаимодействует с сервером, который имеет частный ключ для этого открытого ключа.
Поскольку сертификат также связывает имя сервера с открытым ключом, клиенту тогда известно, что он связывается с нужным сервером.
Вот почему важно убедиться, что (а) сертификат является доверенным и (б) он выдан на имя сервера, к которому клиент хотел подключиться.