В данном конкретном случае навязывается отнюдь не безопасность.
CN - одна-единственная запись одного типа.
SAN - может быть и много записей и разных типов.
"Внимание вопрос!" - задлянафига мне SAN если у меня единственный сервис для каждого хоста?
Тем более, что в RFC2818 внятно прописано - "нет SAN, смотрим CN". Там ни разу нет "... и ругаемся, если не нашли SAN".
Это во-первых.

Во-вторых, "deprecation" из информационного RFC - частное мнение какого-то сотрудника "ЧАВО Инк."

В-третьих - пример с Netflix-ом, опять-таки, мимо кассы, поскольку среда, в которой они развёртывают TLS, требует SAN.

Ну и в качестве десерта.
Насколько я понимаю, площадные бомбардировки РКН были вызваны тем, что Telegram эксплуатировал багу на стороне CDN.
Если бы те, кто "типа заботятся" о клиентах больше думали о брёвнах в собственных глазах - мир был бы лучше.

P.S.
Истерия вокруг TLS нужна, в основном, для защиты пищевого ресурса корпорации добра.
Всё остальное - полностью вторично.

Я вот тоже совершенно не понимаю, как использование CN снижает безопасность, доверие не может быть наполовину: если УЦ доверенный, то должен проверять, чего он пишет в CN сертификатов и тогда ему доверяем целиком. А если он не проверяет, то просто выкинуть такой УЦ из доверенных и сказке конец. Разработчики браузеров уже немного "достали" своими странными понятиями о безопасности (надеюсь, не принимите на свой счет), которые не плохи сами по себе, но заходят слишком далеко. Я даже не говорю про плагины, подход к которым кардинально меняется каждые 15-20 версий браузера.

Вспомним историю. Сначала они вводили защиту от cross-site-scripting после эпидемии в социальных сетях (лично мне абсолютно все равно на социальные сети США), но почему-то ввели так, что и из локальной сети тоже нельзя скрипты подгрузить. Замечательно, у нас в локалке парочка социальных сетей и самые злобные хакеры сидят, ага. А уж на локалхост вообще зверюги - палец в рот не клади. Потом еще изображения до кучи заблокировали. Объяснили дескать, чтобы нельзя было чего нибудь удалить на сайте локальной сети при открытии сайта интернет. Вот только отправку POST запросов в локальную сеть не заблокировали и если бы кто-то хотел что-то удалить - никаких проблем, зато серьезно нарушили синхронизацию зеркала моего сайта в локальной сети с моим же сайтом в интернете. Пришлось сопоставлять в hosts IP локальной сети на DNS поддомена того же домена, что сайт в интернете.

Сейчас разработчики браузеров втюхивают TLS везде - ну серьезно, какой вред от того, что кто-то узнает в каком городе я смотрел прогноз погоды или какую новость прочитал. В тоже время на большинстве сайтов зарубежное 128-битное шифрование. Серьезно, оно от любого суперкомпьютера не защитит. В продолжение сумасшествия сейчас еще и на всех сайтах внутри локальной сети выводится предупреждение об незащищенных данных. Да, в локальной сети так и продолжают сидеть злостные хакеры по их понятиям. На 127.0.0.1 - окончание криптотуннеля, но браузер об этом не знает и выводит предупреждение! Как ни посмотри - разработчики браузеров зашли слишком далеко, считая пользователей несмышленными птенчиками.

Сейчас новая волна с обязательностью SAN - для теста выпустил на внутреннем УЦ сертификат с 8 записями SAN для сайта локальной сети (четыре DNS адреса, три внутренних IP, один внешний IP), добавил УЦ в браузеры и половина новейших браузеров не может переварить сертификат с SAN: "имя в сертификате не соответствует имени сайта". Кому от такой "безопасности" стало лучше? Согласен, самое безопасное вообще от интернета отключиться, но тогда и браузеры не нужны.

Хорошо, не берете на себя ответственность - достаточно списка сайтов-исключений, чтобы пользователь смог взять ответственность на себя.По этому поводу я переписывался с лабораторией Касперского, они пояснили, что дело не в ГОСТ. Перехват соединений на государственные сайты все равно работать не будет, так как они запрашивают аутентификацию по сертификату. Получается (это уже мой вывод) антивирус должен сертификат для предъявления сайту запросить у пользователя, но производители антивирусов не берут на себя ответственность за использование сертификата и связанного с ним закрытого ключа и потому принципиально не делают MiTM на сайтах, которые запрашивают аутентификацию по сертификату. Среди сайтов с ГОСТ как раз большинство сайтов с аутентификацией по сертификату.

Отредактировано пользователем 7 августа 2018 г. 7:34:53(UTC)  | Причина: Не указана

Суть в том, что браузер кэширует выбор сертификата для текущего пользователя.

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

Если действительно доверяем УЦ, то непонятно зачем потом сертификат под микроскопом разглядывать и создавать себе лишнюю работу. УЦ уже проверил сервер и не выявил несоответствий. Наличие ключа соответствующего сертификату необходимо для установления успешного соединения. Подпись сертификата сервера проверена по сертификату УЦ. То есть проверив цепочку сертификатов мы знаем, что владелец сервера правомерно получил сертификат в доверенном УЦ и имеет ключ, соответствующий сертификату. Чего еще надо? Чтобы влезть в середину и не спалиться на самой цепочке сертификатов мошенники должны либо подкупить доверенный УЦ либо добавить свой УЦ в доверенные либо украсть закрытый ключ сервера либо украсть закрытый ключ доверенного УЦ. Антивирусы с MiTM на этом и палятся.

Но тем не менее браузеры все равно сомневаются в каждом конкретном сертификате и после проверки цепочки, а вдруг назвались кем-то другим. Да пусть сервер мошенников хоть горшком назовется, если у нас DNS/hosts на него не указывает, то "кина не будет". Если соединение есть, то DNS нам уже указал на конкретный IP. И если мошенники украдут ключи или пропишут свой УЦ доверенным, то уж подделать ответ DNS или вирусом прописать адрес в hosts им труда не составит. Поэтому проверки CN и SAN браузером фундаментально просто подстраховка "на всякий случай", нет существенного смысла писать длинные и детальные проверки имени сервера. Проверка политик УЦ и назначения сертификата гораздо важнее чем соответствие имени. Проверки цепочки доверия, подписей сертификатов в цепочке, проверка отзыва сертификатов - это максимум чего браузер может реально проверить и гарантировать. Все остальное - куча условностей и реклама "вот мы такие супер-безопасные, у нас 100500 проверок".

Приведите, пожалуйста, пример ситуации в котором браузер действительно отклонил сертификат мошенников, прошедший проверку цепочки сертификатов? Ошибки конфигурации (когда зашли на сервер по адресу не включенному в CN/SAN) не считаем. Совсем наглые MiTM, палящиеся на проверке цепочки сертификатов тоже. За примерами, в которых браузеры отклонили правомерный сертификат сервера, ходить далеко не надо - сами видите сколько возражений пользователей. Для интереса можно бы составить матрицу и посчитать коэффициент корреляции. Логически приходим к выводу, что можно выкинуть не только "проблемный" код, проверяющий CN, но "безупречный" код, проверяющий SAN. Так будет еще проще для разработчиков браузеров - просто всегда ОК.

Ну хорошо если с проверками CN и SAN "безопаснее" - пусть будут. Мне что-то тоже не понятно про какие именно нестрогие проверки CN идет речь, тем более об их большом объеме. На самом деле, если смотреть в код почти любой программы, то 40% кода тупые базовые функции, написанные в самых первых версиях (не учитывающие нюансы, но охватывающие 80-85% случаев), а 60% кода это уточнения даталей, добавленные в следующих 100500 версиях (для 15-20% экзотических случаев). Если так важно упрощение, то можно выкинуть неиспользуемые большинством детали. Согласитесь, мало серверов реально использует все формы записи IP, маски IP и т.д. Проверки десятичного IP, обработки звездочки в имени сервера и строго соответствия имени сервера достаточно для проверки большинства сертификатов серверов.

Я бы выстроил алгоритм так:
Какие-то интересные требования по обоснованию, с точки зрения разработчиков, будто они одни в мире. Пользователей и владельцев серверов намного больше - меньшинство диктует большинству?
1) Перевыпуск сертификата требует материальных затрат со стороны владельцев серверов. Из-за повального распространения хостингов, сертификат заменить порой не так уж и просто. Поэтому перевыпуск сертификатов серверов идет со скрипом и года явно недостаточно. Легко представить, что причиной отключения CN были не сложности проверки и заботы о безопасности, а просто проплата со стороны группы УЦ в Гугл и ключевым разработчикам мозиллы.
2) Что касается отечественных УЦ, то они все еще ссылаются на неведомые требования, которые им не дают выпустить с SAN. Пересмотрел указ ФСБ и не нашел там запрета указания лишних полей в SAN. Однако пока "свыше" не придет разъяснение УЦ не станут чего либо выпускать по-другому, ведь это требует изменения регламента УЦ и либо переаккредитации либо потенциального риска что УЦ просто прикроют. Бог с остальным миром, но наверно надо учитывать российские реалии при выпуске браузера с ГОСТ.
3) Как бы не были хороши "стандартизированные поля" SAN, браузеры их все еще не могут полноценно обработать при наличии большого количества таких полей в сертификате. Предлагаю эксперимент - создать сертификат с 8-10 SAN и попробовать зайти на сайт по каждому из указанных в SAN адресов/айпи. В моем случае такой сертификат от внутреннего УЦ с использованием адресов локальной сети и доменов .LOCAL - такие элементы SAN недопустимы для общепризнанных доверенных УЦ и потому сертификат наверно не годится для чистого эксперимента. Мозилла 60 не смогла признать все адреса, ХромиумГост еще не тестировал по всему списку.

Отредактировано пользователем 8 августа 2018 г. 12:21:54(UTC)  | Причина: уточнение