Mozilla: Ошибка sec_error_unknown_issuer (мысли вслух)

[@Valdei]

Получается, хром на такую подмену не реагировал, левый сертификат обнаружился только при переходе на FFox?
Тормоза — это, конечно, заметно, но как-то недостаточно информативно.

Кстати, а в трудовом договоре у вас есть пункт про возможность сбора информации о деятельности сотрудника?

[@RazorBlade]

Chrome, скорее всего не среагировал, т.к. в организации внедрили в ОС свой сертификат на рабочие компьютеры, например групповыми политиками. А FF не смотрит на сертификаты ОС, а использует свою базу.

[@GebekovAS]

Вот, что видит хром если включить службу:

… а вот, что видит если отключить:


Нет, в трудовом такой пометки нет=)

[@blind_oracle]

Хром использует системное хранилище сертификатов, лиса — своё.
Свой сертификат Staffcop Agent добавляет в систему в доверенные при установке.

[@farcaller]

Но в хроме же по идее SSL Pinning на сертификаты сайтов Google и он все равно не должен дать зайти на google.com с чужим сертификатом:

Chrome has HTTPS «pins» for most Google properties — i.e. certificate chains for Google properties must have a whitelisted public key, or it will result in a fatal error

[@blind_oracle]

В идеале, конечно, именно так. Они много где об этом пишут.
Но на деле, по крайней мере в enterprise версии Хрома (которая из MSI ставится), картина такая:



То есть, Хром без проблем жуёт сертификат для google.com, который сгенерировал прокси-сервер.

[@lexore]

в enterprise версии Хрома (которая из MSI ставится)

Может быть, дело в том, что в вашей enterprise версии это «поправили»?

[@blind_oracle]

Почитав Security FAQ наткнулся на такое:

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor. A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites. “Data loss prevention” appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

То есть, если корневой сертификат в цепочке доверия — частный (то бишь не поставлялся с ОС, а был добавлен вручную), то Certificate Pinning отключается.

[@bougakov]

Было решено установить всему персоналу программу StaffCop

После отключения данной службы

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

[@GebekovAS]

Права на самом деле отобраны (у большей части), просто я отношусь к пользователям с особыми правами.

[@ploop]

Было решено установить всему персоналу программу StaffCop, которая осуществляет мониторинг деятельности сотрудников

Я правильно понимаю, что о таких действиях сотрудники должны быть информированы под подпись?

[@Delphinum]

Там где работает автор, начальство мало интересуется своими обязанностями.

[@mayorovp]

в иерархии сертификатов корневым сертификатом является сам сертификат (самоподписанный).

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

[@GebekovAS]

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

[@mayorovp]

«Сертификат известен, но нет доверия» и «сертификат не найден» — это разные ситуации, и обрабатываются они по разному.

Обычно сервер отдает не только свой сертификат — но и всю цепочку. Однако, так делать не обязательно. Ваш прокси-сервер решил послать только свой сертификат — вот и получилось что получилось.

[@GebekovAS]

Спасибо за разъяснение, но разве информация в поле «иерархия сертификата» не идентична информации во вкладке «путь сертификации» в системном окне просмотра свойств сертификата? Мне всегда казалось, что если сертификат выдан каким либо центром сертификации, то он должен отображаться в пути сертификации (даже если сертификата физически нет, но описание все равно должно быть указано).

[@mayorovp]

Да, идентична. Нет, при ненайденном издателе сертификат в обоих окнах остается единственной строчкой насколько я помню.

[@ipswitch]

Догадался кто виновник сразу после упоминания AtomPark Software.
Означенный StaffCop — не новая программа, но так и не отлаженная. Жуткое глюкалово! После её установки многое начинает глючить и тормозить.

[@vma]

Уже много более качественных, стабильных и функциональных аналогов есть, вот например SecureTower:
falcongaze.ru

[@J_o_k_e_R]

Почему chrome, а не Google, но mozilla, а не Firefox? Может стоит называть правильно то, про что Вы пишете? Если что, ПО с названием mozilla (suite) тоже было, но Вы явно не про него.

[@GebekovAS]

Это моя давняя привычка от которой пора избавиться=) Заголовок и метки не стал трогать, а в основном подправил. Спасибо за резонное замечание.

[@SkidanovAlex]

> Браузер даже не дает права проигнорировать ошибку.

Если я правильно помню, если развернуть «Технические Детали» внизу, там будет опция проигнорировать ошибку.

[@GebekovAS]

Такой возможности там нет:

Было бы интересно узнать почему.

[@SunX]

Там же написано «Этот сайт использует HSTS… бла бла бла… В результате, добавление исключения для этого сертификата невозможно».

[@ComodoHacker]

Вы не совсем верно интерпретировали свои наблюдения.

StaffCop установил свой корневой сертификат также и в хранилище сертификатов Firefox, его видно на вашем скриншоте окна «Управление сертификатами». Обратите внимание на надпись «Модуль защиты» рядом с ним, она говорит о том, что сертификат не встроенный, а установлен извне.
Но это не сработало из-за пиннинга, который в Firefox работает жестко. В то время как Chrome только отправляет информацию в Гугл о подозрительных сертификатах.

И еще, если пользуетесь Firefox, обязательно установите расширение Cretificate Patrol. Оно поможет заметить подозрительный сертификат по косвенным признакам, даже если он подписан как положено (например украденным ключом корневого CA).

[@GebekovAS]

Спасибо за подробное разъяснение. Я заметил, что корневой сертификат присутствует в хранилище (про «модуль защиты» не знал) и стал грешить на то, что сертификат самоподписанный, что и сподвигло меня на онлайн проверку. Комментарием выше мне уже объяснили, что отсутствие корневого сертификата в иерархии не признак самоподписанного сертификата. Получается, мне просто повезло, что у FireFox более жесткий процесс пиннинга чем у Chrome.
Теперь возник вопрос: Будет ли правильным все эти поправки перенести в конец статьи или наличие их в комментариях будет достаточным?

[@mayorovp]

Кстати, интересный вопрос — а пинниг ли это, или корневому сертификату просто нет доверия?

Что, если снова найти корневой сертификат в хранилище и нажать на кнопку «Изменить доверия»?

[@ComodoHacker]

Кстати, интересный вопрос — а пинниг ли это, или корневому сертификату просто нет доверия?

В данном случае это одно и то же. :)

[@mayorovp]

Нет, это не одно и то же.

Certificate pinning — это привязка к конкретному сертификату без проверки иерархии, или проверка всего одного уровня иерархии.

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

[@GebekovAS]

Теперь вроде все понятно

[@DanXai]

На днях была аналогичная проблема в Хроме. Выяснилось, что Хрм не доверяет сертификату от Comodo.

[@GebekovAS]

В свое время использовал сертификат от Comodo только потому, что на моем телефоне (Android) ему было доверие (поднимал Lync для демонстрации клиенту). Если не ошибаюсь, они еще тогда в архиве помимо моих сертификатов отправляли сертификат центра и вроде тоже приходилось вручную помещал его в хранилище доверительных центров на машинах с Windows 7. Думаю в поздних версиях (Windows 8 и 10) они уже включены.

[@ComodoHacker]

Еще один сайт для проверки наличия подмененных корневых сертификатов: https://superfish.tlsfun.de/