Атака "человек посередине" в сценарии SSL

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

User ****** Hacker **** Your website

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

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

Существует два вопроса для рассмотрения при проверке сертификата:

• проверка его была испущена объектом, которому Вы доверяете, и
• проверка его соответствует идентификационным данным сервера, с которым Вы пытаетесь связаться.

Выпущенные CA сертификаты

Инфраструктура открытых ключей с помощью спецификации сертификата X.509 определяет структуру для помещения на месте для этого. Это - иерархическая модель, где Вы получаете дерево, корнем которого Центры сертификации (CA) и его листы, сертификаты объекта конца (в особенности сертификаты сервера).

Корневые сертификаты CA имеют тенденцию быть самоподписанными. Набор их включен по умолчанию в Вашей ОС или браузере. Это - "прыжок веры" часть, где Вы доверяете своему поставщику ОС/браузера для проверки АВАРИИ, чтобы сделать их задание правильно. Частью большой коммерческой АВАРИИ является Verisign, Thawte...

CA может затем подписать другие сертификаты. Можно проверить сертификат, который Вы никогда не видели прежде путем проверки, был ли он подписан CA, которому Вы доверяете. Может также быть промежуточная АВАРИЯ. Например, сертификат для https://www.google.com/ был подписан "Thawte SGC CA", который был самостоятельно подписан "VeriSign, Общественностью Inc./Class 3 Основной Центр сертификации" (я закорачиваю имена здесь для упрощения). Задание CA состоит в том, чтобы проверить (средствами, внешними к PKI), что человек/учреждение, которому это выпускает сертификат, является законным владельцем того имени хоста (например. www.google.com здесь). Путем эта внеполосная проверка варьируется для сертификатов non-EV, это часто делается просто путем посылания электронного письма адресу, который зарегистрировал доменное имя (доступный в whois каталоге).

После того как это сделано, предположите, что Вы не знаете, доверять ли https://www.google.com/, клиент проверяет этот сертификат против доверительных привязок, которые он имеет (АВАРИЯ, часто предварительно импортируемая поставщиками ОС/браузера). Если Вы соединяетесь с www.google.com, браузер получает сертификат и затем может разработать цепочку до главного выпускающего (существует запись выпускающего в каждом сертификате), пока это не находит тот, которому это доверяет (в этом случае то от Verisign). Пока неплохо сертификату доверяют. Второй шаг состоит из проверки, что этот сертификат действительно для этой машины. Для HTTPS это сделано путем проверки, что имя хоста находится в подчиненном расширении имени альтернативы сертификата, или как нейтрализация, что это находится в "Общем названии" (CN) запись в подчиненном отличительном имени. Это объяснено в RFC 2818 (идентификационные данные сервера).

Здесь возможные попытки напасть следующие:

• Взломщики подделывают сертификат (для того имени хоста или не) с их собственным Приблизительно. Так как их CA не распознан Вашим браузером, сертификат не будет проверен. Даже если бы они фальсифицировали имя выпускающего, то они не смогли бы фальсифицировать подпись (потому что Вы проверяете, что использование открытого ключа с помощью CA сертифицирует Вас, уже доверяют). Одна из самых больших проблем здесь была в силе подписи: нападения коллизии были продемонстрированы с помощью алгоритма выборки сообщений MD5, таким образом, АВАРИЯ теперь использует SHA-1 вместо этого, который считают более устойчивым. Если Вы полагаете, что RSAwithSHA1 или DSAwithSHA1 достаточно устойчивы, у Вас не должно быть проблемы там.
• Взломщики получают законный сертификат от известного CA, но для другого имени хоста (поскольку CA не должен испускать кому-то еще). Скажем, они добираются www.example.com. Вы пытаетесь соединиться с www.google.com, они перенаправляют трафик к своему полю, которое покажет сертификат, который будет поддаваться проверке CA, для которого Вы доверяете, но www.example.com. Это - то, где проверка имени хоста важна. Ваш браузер предупредит Вас, что Вы не подключены к хосту, который Вы предназначили.

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

Самоподписанные сертификаты

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

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

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