Последствия безопасности при отключении проверки общего имени для HTTPS

Question

Я перехожу к некоторому клиентскому коду, который я унаследовал для обеспечения безопасной связи через HTTPS, и кажется, что он не проверяет общее имя в сертификате сервера (например, CN = «example.com» «против фактического URL-адреса, который запрашивается. Это, вероятно, преднамеренно, так как наше клиентское приложение должно разговаривать с различными средами, поэтому после контакта с исходным порталом (например, example.com/main) и пользователь, выбирающий среду, приложение перенаправляется на определенный IP-адрес, поэтому все будущие запросы выглядят примерно так: «http://127.0.0.1/page».

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

Благодаря

Answer 1

Чтобы сделать то же самое с «пользовательскими настройками DNS» атакующим должен использовать DNS-сервер (ваш или клиента), чтобы указать example.com на IP он контролирует, а не просто копирование сертификат. Если возможно, я бы создал все конкретные приложения в качестве поддоменов example.com и использовал сертификат подстановки (* .example.com), чтобы иметь возможность проверить CN.

Answer 2

Кто-то еще не может просто скопировать ваш сертификат и использовать его, потому что у них нет личного ключа.

Если вы не проверяете, что CN сертификата не соответствует доменному имени, тогда они могут просто создать свой собственный сертификат (и подписывать его доверенным ЦС, чтобы он выглядел действительным), используйте его вместо своих , и выполнить человека в средней атаке.

Кроме того, вам необходимо проверить, что сертификат поступает от доверенного ЦС. Это задача ЦС, чтобы убедиться, что вы можете получить сертификат только с CN =, если вы фактически контролируете этот домен.

Если вы пропустите ни одну из этих проверок, вы рискуете атакой MITM.

См. Также this answer для другого подхода, который будет работать, если у вас есть достаточный контроль над клиентом.

Answer 3

Если вы управляете кодом клиента, вы можете ограничить доверенные ЦС только своим собственным. Тогда проверка домена менее важна - любой из ваших серверов может притворяться другим.

Если вы не контролируете код клиента, сертификат, подписанный доверенным ЦС, может быть заменен вашим.

Answer 4

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

Если вы не подтвердите часть имени хоста, кто-то (кто-то сидит на любом из маршрутизаторов или прокси-серверов, прохождение которых проходит) может сделать человека в средней атаке. Или кто-то может использовать некоторые атаки DNS.

Answer 5

$ 0.02: использование CN для имен хостов устарело, X.509 Вместо этого следует использовать альтернативные имена.

Answer 6

• Проверка самого сертификата и его привязка к сертификату CA, которому вы уже доверяете, позволяет проверить подлинность и достоверность сертификата.
• Проверка имени хоста в сертификате позволяет проверить, что вы разговариваете с сервером, на котором вы хотели поговорить, при условии, что вы действительно подтвердили, что сертификат действительно действителен. (. Проверка того, что удаленная сторона действительно один держит закрытый ключ для этого сертификата осуществляется в SSL/TLS рукопожатия)

Если вы хотите провести аналогию с проверкой паспорта/ID для людей:

• Проверка сертификата - это проверка подлинности паспорта или формы удостоверения личности. Вы можете решить, какие формы идентификатора вы хотите принять от человека (например, паспорт, водительские права, кадровая карточка, ...) и какие страны-эмитенты вы доверяете, чтобы иметь возможность проверить их подлинность.
• Проверка того, что удаленная сторона принадлежит закрытому ключу, аналогична проверке того, что изображение на паспорте/ID соответствует лицу лица перед вами.
• Проверка имени хоста, как проверка паспорта принадлежит лицу, имя которого вы ищете.

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

В очень ограниченном наборе обстоятельств, где вы доверяете только конкретному ЦС или самоподписанному сертификату, где вы позволяете любому потенциальному сертификату выдавать себя за другого из всего набора доверенных сертификатов, может быть приемлемым игнорировать эту проверку , но это очень редко, а не хорошая практика.

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

Правила проверки имени хоста HTTPS определены в RFC 2818 Section 3.1 (также совсем недавно в спецификации «лучшие практики», RFC 6125, пока не реализовано много).

Короче говоря, имя хоста должно быть в записи DNS-имени субъекта альтернативного имени (хотя вы можете вернуться к CN DN объекта, в котором нет сертификата SAN). Когда вы используете IP-адрес, IP-адрес должен быть в записи IP-адреса SAN (хотя некоторые браузеры позволят вам уйти с IP-адресом в CN DN объекта).