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

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

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

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

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

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

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

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

$0,02: использование CN для имен хостов устарело, вместо этого следует использовать X.509 Subject Alternate Names.

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

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

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

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

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

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

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

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

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

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

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