Проверка подлинности HTTPS и захват сеанса

Question

Когда я печатаю URL, например, www.google.com в первый раз в моем браузере. Я уверен, что что-то отправлено с URL-адресом. Затем на экране отображается возвращаемая HTML-страница.

Как мой браузер убедитесь, что сервер, который отвечает на мой запрос является сервер реального Google, не кого-то другого сервера (Человек-в-середине)?

Я также вижу, что установлено соединение HTTPS. Я считаю, что это имеет какое-то отношение к вышеуказанному вопросу.

Может кто-нибудь anwser этот вопрос подробно с моим www.google.com например?

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

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

Отредактировано

1. Как только браузер знает, что это сервер реального Google, который отправляет страницу, как браузер может убедиться, что содержание страницы сама не модифицируется кем-то другим? Является ли первая страница отправленной обратно уже зашифрованной?
2. Является ли симметричное шифрование для следующих запросов и ответов?
3. Является ли сам URL-адрес зашифрованным?

Answer 1

Как только браузер знает, что это реальный сервер Google, который отправляет обратно страницу, как браузер может убедиться, что содержание страницы сама не модифицируется кем-то другим?

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

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

Является ли первая страница отправленной назад уже зашифрованной?

Да, как только достигается SSL-соединение, все зашифровано. Сюда входят любые данные в исходном запросе, отправленные из браузера (например, файлы cookie или строка запроса).

Является ли симметричное шифрование для следующих запросов и ответов?

Да, хотя ключи являются функцией случайных чисел, сгенерированных как клиентом, так и сервером, так и «до главного секрета», который отправляется от клиента к серверу, зашифрованному с помощью открытого ключа сертификата (или зашифрован один раз генерируемых ключи в случае Диффи-Хеллмана).

Является ли сам URL зашифрованным?

Доменное имя отправляется в открытом виде для расширения указателя имени сервера, а также IP-адрес DNS и IP-адреса назначения также могут быть известны с помощью evesdropper в соединении.

Путь URL и строка запроса зашифрованы.

Answer 2

https использует подписанные сертификаты для обеспечения идентификации сервера-ответчика.

Запрос отправляется на IP адреса вашего разрешение имен утверждает, что название решает. Это не очень надежно, так как вы сами можете легко изменить это разрешение.

Ответ от сервера, однако содержит сертификат, который был выдан на имя хоста (www.google.com здесь). Это также еще не обеспечивает безопасность, которую вы ищете, но это приближает нас.

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

---

Реальность немного сложнее, как всегда, но приведенное выше должно дать вам представление о том, как все работает.

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

Answer 3

Они используют сертификаты для удостоверения личности и подписей. Когда сервер отвечает на вас, он содержит сертификат, который выдается для этого конкретного хоста. В вашем примере это будет www.google.com. Это обеспечивает некоторое доверие, потому что корневой сертификат содержится в вашем аккаунте в браузере. Говоря о корневом сертификате, вы начинаете создавать цепочку доверия, а один сертификат подписывается другим сертификатом, пока он не достигнет корня этого доверия. Они локально установлены в вашем браузере и поэтому очень трудно обмануть атакующего.