Недопонимание SSL / TLS

Question

У меня есть фундаментальное недопонимание SSL / TLS, которое, я надеюсь, может быть устранено.

Насколько я понимаю, когда я получаю сертификат для своего сайта, он содержит всю мою информацию и подписывается моим центром сертификации (VeriSign или кем бы то ни было). Когда кто-то запрашивает страницу с моего сайта, которая использует SSL / TLS, сертификат переходит к пользователю, и он проверяется с использованием хорошо известного открытого ключа центра сертификации. Затем пользователь может посмотреть сертификат и посмотреть мою информацию. Они уверены, что я тот, кем я себя говорю, и что сообщение не было подделано с тех пор, как проверка работала правильно.

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

Спасибо.

Answer 1

Любые ответы в основном верны в том, как работают SSL / TLS и обмен сертификатами.Но давайте посмотрим на это конкретно, поскольку оно относится к вашему первоначальному вопросу.

Чтобы это работало, прокси-сервер должен иметь возможность:

1. Предоставить сертификат, в котором общийАтрибут name соответствует домену сайта, к которому вы хотите подключиться.Другими словами, если вы хотите перейти на https://www.example.com,, прокси-сервер должен иметь возможность представить сертификат с www.example.com или * .example.com в качестве общего имени.
2. Сертификат, представленный прокси-сервером, должен быть подписан центром сертификации, которому доверяет ваш браузер.Хотя ваш браузер доверяет десяткам центров сертификации, теоретически ни один из них не выдаст сертификат с общим именем www.example.com, если вы не докажете, что являетесь владельцем этого домена.

На практике этоочень трудно заставить прокси-сервер выдавать себя за сеансы SSL / TLS вне корпоративной среды.Внутри корпоративной среды это другая история.Корпорации регулярно регистрируют свои собственные внутренние сертификаты CA в браузере на вашем рабочем столе.Когда вы входите в свой банк с помощью TLS, очень часто корпоративный веб-прокси генерирует сертификат на лету с соответствующим доменным именем для представления вашему браузеру.Ваш браузер видит https://www.mybank.com и соответствующий сертификат от доверенного центра сертификации и счастлив.Между тем корпоративный веб-прокси поддерживает отдельный сеанс TLS для вашего банка.В промежутке прокси-сервер имеет возможность регистрировать все ваши сообщения HTTPS и получать звонки, включая содержимое любых форм, таких как ID и пароль.

За пределами корпоративной среды большинству злоумышленников не нужно заходить наЭто большая проблема, поскольку они могут сидеть в точке доступа Wi-Fi и запускать SSLStrip .Большинство людей не заметят, что сеанс на самом деле не является SSL, особенно когда злоумышленник меняет значок на символ блокировки.

Answer 2

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

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

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

Теперь о MITM-атаке. В общем, это шаг 2, который предотвращает атаку MITM. Если проверка слабая, злоумышленник может попытаться подделать сертификат и неверно представить сайт. Другим возможным слабым местом является ЦС, который выдал сертификат без надлежащей проверки или из-за нарушения безопасности (как это недавно произошло с определенным под-ЦС Comodo).

У нас есть хорошее (я надеюсь :) описание того, как работает SSL, в соответствующей статье , хотя оно не объясняет атаки MITM.

Answer 3

Я думаю, что это проще объяснить без использования сертификатов, а затем добавить сертификаты.

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

Все, что делает сертификат от признанного органа, - это подтверждает, что открытым ключом сайта skaz.com является xyz.Если у нас не было сертификатов, то самозванец мог бы создать пару (открытый, закрытый) ключ (abc, mno) и сообщить миру, что открытый ключ skaz.com - abc.

Чтобы ответить на ваш вопрос Что мешает мне поставить прокси в середине браузера и реального сайта и просто отправить сертификат реального сайта , который является классической атакой "человек посередине", если случайное число -- 1729 в ​​этом случае --- что зашифрованный клиент используется в качестве ключа шифрования (также известного как ключ сеанса) для всего будущего трафика, тогда прокси-сервер ничего не может сделать.Например, если клиент отправляет пароль, зашифрованный с помощью ключа сеанса, самозванец-прокси не может его прочитать.

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

Answer 4

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

.

Во-вторых, теперь SSL называется TLS .

Теперь, чтобы ответить на ваш вопрос: Получив открытый ключ сервера, вы можете отправлять сообщения только сервер может читать, потому что никто другой не имеет своего закрытого ключа.Так что, если вы зашифруете, скажем, ключ AES, и сервер вернет вам сообщение «Hello world!»зашифрованный этим ключом, вы можете быть уверены, что сообщение действительно пришло с сервера, потому что никто другой не мог прочитать ключ.

Фактическое рукопожатие в TLS сложнее, чем это,но это основная идея.

Answer 5

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

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