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

Question

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

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

Спасибо

Answer 1

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

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

Кроме того, вам необходимо проверить, что сертификат исходит от доверенного центра сертификации. Задача CA - убедиться, что вы можете получить сертификат только с CN =, если вы действительно контролируете этот домен.

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

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

Answer 2

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

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

Answer 3

$ 0,02: использование CN для имен хостов не рекомендуется, вместо него следует использовать альтернативные имена субъектов X.509.

Answer 4

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

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

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

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

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

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

Правила проверки имени хоста HTTPS определены в RFC 2818, раздел 3.1 (также совсем недавно в спецификации "передового опыта", RFC 6125 , еще не реализовано).

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

Answer 5

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

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

Answer 6

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