Я пытаюсь понять, как атака «человек посередине» повлияет на мой веб-сервер.
У меня есть самоподписанный сертификат. Этот сертификат можно подделать с помощью атаки «человек посередине», а это значит, что все, что я отправляю из браузера, будет перехвачено и изменено?
Если запрос будет изменен, он не будет расшифрован веб-сервером, поскольку сертификат на сервере отличается. Это верно?
Запрос, отправленный из браузера, может быть перехвачен и может быть перенаправлен, но данные на моем сервере не будут затронуты, это правильно?
Я начинаю понимать теорию, лежащую в основе сертификатов, но было бы здорово, если бы кто-нибудь мог предоставить реальный пример атаки «человек посередине» и посмотреть, какие проблемы она вызывает.
Спасибо
Как я уже говорил в своем предыдущем ответе на ваш вопрос, атаки типа «человек посередине» (в случае успеха) могут владеть всеми данными, передаваемыми туда и обратно по зашифрованному каналу.
Сертификаты, как самозаверяющие, так и выпущенные из доверенного корневого каталога, могут быть подделаны, поэтому не поддавайтесь ложному чувству безопасности, если вы выпускаете сертификат для своих пользователей из доверенного корневого каталога. Единственная проблема, которую я должен решить с одним, выпущенным доверенным корнем, - это заставить вашего пользователя принять мой, когда я отравил его компьютер. Если вы думаете о большинстве конечных пользователей, насколько это будет легко?
Теперь вы видите проблемы?
Как только конечный пользователь принимает МОЙ сертификат, я становлюсь владельцем соединения с этой точки, и все данные проходят через мою машину.
Дело не в том, что он может изменять трафик. Дело в том, что рукопожатие SSL начинается в незашифрованном виде, и сервер отправляет сертификат SSL для использования клиентом с этого момента. Если злоумышленник присутствует с самого начала, он может заменить этот исходный сертификат своим собственным, а затем использовать тот, который сервер отправил, для шифрования / дешифрования трафика на / с сервера, используя свой собственный сертификат, чтобы отправить его вам.
Если сертификат подписан центром сертификации, немного сложнее заменить его поддельным, который также подписан центром сертификации. Однако злоумышленник может легко заменить этот сертификат самоподписанным, отсюда и предупреждение.
В основном происходит следующее: вы сами подписали свой сертификат, поэтому у вас нет возможности доказать, что он действителен. Таким образом, он отлично шифрует трафик, но вы не можете доказать, что он ваш. Если хакер может попасть между вашим сайтом и компьютером пользователя и перехватить трафик, он сможет расшифровать трафик и прочитать, что происходит. (Он также может сделать это, зарегистрировав доменное имя, похожее на ваше, и ожидая опечатки, или отправив электронное письмо, которое направит их на его сайт, а не на ваш)
User ****** Hacker **** Your website
Причина, по которой он может это сделать, заключается в том, что он может также предоставить самоподписанный сертификат. Тогда пользователь действительно общается с хакером, а не с вами. Пользователь не заметит разницы. Фактически, если он хочет, хакер может повторно зашифровать трафик и отправить его обратно на ваш сайт, а также запустить свой собственный поток связи с вашим сайтом, используя учетные данные пользователей. Или просто наблюдайте за движением транспорта вперед и назад.
При проверке сертификата следует учитывать два момента:
В Инфраструктура открытых ключей с использованием сертификата X.509. Технические характеристики определяет структуру, которую нужно создать для этого. Это иерархическая модель, в которой вы получаете дерево, корнем которого являются центры сертификации (ЦС), а его листами являются сертификаты конечных объектов (в частности, сертификаты серверов).
Сертификаты корневого ЦС обычно самозаверяющие. Некоторые из них по умолчанию включены в вашу ОС или браузер. Это часть «прыжка веры», когда вы доверяете поставщику вашей ОС / браузера, что он проверил центры сертификации, чтобы они правильно выполняли свою работу. Некоторые из крупных коммерческих центров сертификации - это Verisign, Thawte, ...
Затем ЦС может подписывать другие сертификаты. Вы можете проверить сертификат, который никогда раньше не видели, проверив, подписан ли он центром сертификации, которому вы доверяете. Также могут быть промежуточные центры сертификации. Например, сертификат на https://www.google.com/ был подписан "Thawte SGC CA", который сам был подписан"VeriSign, Inc./ Общественный первичный центр сертификации класса 3"(Я сокращаю имена здесь для упрощения). Задача ЦС - проверить (внешними по отношению к PKI средствами), что лицо / учреждение, которому он выдает сертификат, является законным владельцем этого имени хоста (например, www.google.com Вот). Эта внеполосная проверка отличается, для сертификатов, не относящихся к EV, это часто выполняется просто путем отправки электронного письма на адрес, на который зарегистрировано доменное имя (доступно в кто каталог).
Как только это будет сделано, предположим, вы не знаете, доверять ли https://www.google.com/, клиент проверяет этот сертификат по имеющимся у него якорям доверия (центры сертификации, часто предварительно импортированные поставщиками ОС / браузеров). Если вы подключитесь к www.google.com, браузер получает сертификат и затем может проработать цепочку до верхнего эмитента (запись об эмитенте есть в каждом сертификате), пока не найдет тот, которому он доверяет (в данном случае от Verisign). Пока все хорошо, сертификату доверяют. Второй шаг состоит в проверке того, действительно ли этот сертификат предназначен для этой машины. Для HTTPS это делается путем проверки того, что имя хоста находится в расширении альтернативного имени субъекта сертификата, или в качестве запасного варианта, что оно находится в записи «Общее имя» (CN) в отличительном имени субъекта. Это объясняется в RFC 2818 (идентификация сервера).
Здесь возможные попытки атаки следующие:
www.example.com. Вы пытаетесь подключиться к www.google.com, они перенаправляют трафик на свой ящик, в котором будет отображаться сертификат, который будет проверяться центром сертификации, которому вы доверяете, но для www.example.com. Здесь важна проверка имени хоста. Ваш браузер предупредит вас, что вы не подключены к нужному хосту.Эта система разработана таким образом, чтобы гарантировать, что если MITM перенаправляет трафик на свою машину, клиент не примет соединение. Это, конечно, действительно только в том случае, если пользователь не игнорирует предупреждения, отображаемые браузером.
Это тот же принцип, за исключением того, что вы являетесь центром сертификации, и этот самозаверяющий сертификат также может быть непосредственно сертификатом сервера. Если вы создадите свой собственный самозаверяющий сертификат и поместите его на свой компьютер, вы также можете импортировать его в свой браузер в качестве доверенного центра, и в этом случае вы выполните ту же процедуру, что и описанная выше.
Некоторые браузеры, например Firefox, позволяют добавлять к этим правилам постоянные исключения. Если вы знаете каким-либо другим способом (например, администратор лично предоставил вам сертификат), какой сертификат для машины, к которой вы хотите подключиться, вы можете явно доверять им, даже если они не были подписаны ЦС, которому вы доверяете, или если имя не совпадает. Конечно, для этого вам нужно заранее знать, каким должен быть этот сертификат.
Если в любом случае пользователь предпочитает игнорировать предупреждения и соглашается на перенаправление на соединение с ненадежным сертификатом, то MITM (с этим ненадежным сертификатом) может видеть / перенаправлять / изменять трафик.