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

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

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

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

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

При проверке сертификата необходимо учитывать два момента:

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

CA выданные сертификаты

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

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

CA может затем подписать другие сертификаты. Вы можете проверить сертификат, который вы никогда раньше не видели, проверив, подписан ли он центром сертификации, которому вы доверяете. Также могут быть промежуточные CA. Например, сертификат для https://www.google.com/ был подписан " Thawte SGC CA ", который сам был подписан " VeriSign, Inc./Class 3 Public Primary Certification Authority " (я сокращаю названия здесь для упрощения). Задача CA состоит в том, чтобы проверить (посредством внешних средств для PKI), что человек / организация, которой он выдает сертификат, является законным владельцем этого имени хоста (например, www.google.com Вот). Способ, которым эта внеполосная проверка варьируется, для сертификатов, не относящихся к EV, часто выполняется путем отправки электронного письма на адрес, на котором зарегистрировано доменное имя (доступно в каталоге whois).

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

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

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

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

Самозаверяющие сертификаты

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

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

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