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

Question 1

Как я уже сказал в своем предыдущем ответе наваш вопрос, атаки типа «человек посередине» (в случае успеха) могут завладеть всеми данными, передаваемыми в обоих направлениях по зашифрованному каналу.

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

Теперь вы видите проблемы?

Как только конечный пользователь принимает МОЙ сертификат, с этого момента я становлюсь владельцем соединения, и все данные проходят через мою машину.

Answer

Как я уже сказал в своем предыдущем ответе наваш вопрос, атаки типа «человек посередине» (в случае успеха) могут завладеть всеми данными, передаваемыми в обоих направлениях по зашифрованному каналу.

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

Теперь вы видите проблемы?

Как только конечный пользователь принимает МОЙ сертификат, с этого момента я становлюсь владельцем соединения, и все данные проходят через мою машину.

Question 2

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

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

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

Answer

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

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

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

Question 3

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

Answer

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

Question 4

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

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

Сертификаты, выпущенные CA

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

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

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

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

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

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

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

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

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

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

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

Answer

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

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

Сертификаты, выпущенные CA

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

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

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

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

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

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

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

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

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

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

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

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

решение1

решение2

решение3

решение4

Сертификаты, выпущенные CA

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

Связанный контент