Браузер даже не дает права проигнорировать ошибку. По привычке первым делом взгляд упал на дату и время. Убедившись, что временные параметры на компьютере установлены верно, перешел на другой ресурс «yandex.ru»:
Тут дела обстояли чуть лучше, Firefox уже предлагает добавить сертификат в хранилище доверенных. Тут пришлось уже включать мозги, т.к. активно пользуюсь сервисом Яндекс.Деньги и любые утечки для меня существенны. Первым делом решил проверить, что именно браузеру не нравится в сертификате:
Нет доверия стороне выдавшей сертификат. И такая картина на всех ресурсах, где используется безопасное соединение HTTPS.
Для использования шифрованного канала связи, ваш браузер использует протокол SSL (или TLS) (HTTPS пользуется им), который, в свою очередь, использует сертификат проверки подлинности. Этот сертификат хранит в себе информацию как для шифрования данных, так и для идентификации WEB-сервера, к которому вы обращаетесь. Помимо всей прочей информации, хранимой в сертификате (тип шифрования, альтернативные имена и т.д.), нас интересуют открытый ключ, который решает проблему №1 — шифрование в открытых сетях и информация о центре, выдавшем этот сертификат, которая решает проблему №2 — доверие к открытому ключу.
Опишу на примерах.
Сценарий 1:
1. Сервис Яндекс хочет организовать безопасный канал связи со своими пользователями и генерирует для этого пару ключей (открытый и закрытый).
2. Я, как клиент сервиса Яндекс, получаю от него открытый ключ и шифрую им все свои данные. При этом я уверен, что прочитать данные сможет только владелец закрытого ключа, в нашем случае владелец — сервис Яндекс.
Этим самым сервис Яндекс решает проблему шифрования в открытых сетях.
А что если некий троянский вирус встанет между вами и сервисом Яндекс (к примеру, в роли сквозного прокси-сервера)…???
Сценарий 2:
1. Троян получает от сервиса Яндекс открытый ключ.
2. Троян генерирует пару своих ключей и передает открытую часть вам от имени сервиса Яндекс.
3. Все сообщения, адресованные от вас сервису Яндекс, перехватываются и дешифруются трояном, а троян в свою очередь шифрует эти данные ключом от Яндекс и передает их ему же. Вот тут и возникает проблема №2, а именно, проблема доверия к открытому ключу.
Данная проблема решается третьим лицом, которому доверяет, как сервис Яндекс, так и клиент. В данном случае запись указывала на AtomPark Software Inc, которая выдала тот самый сертификат подлинности сервису Яндекс.
Вернемся к моему сертификату и удостоверимся, что мы доверяем третьему лицу. В поле Общее имя (CN) группы «кем выдано» стоит запись «AtomPark Software Inc». Первый признак доверия этому центру сертификации – наличие его корневого сертификата в хранилище доверительных центров. В Mozille этот список можно открыть так: Настройка-> Дополнительно-> Сертификаты-> Просмотреть сертификаты-> Центры сертификации. По имени нашел сертификат:
На первый взгляд все в порядке. Решил сверить отпечатки SHA1 сертификатов. Полез в иерархию и увидел следующее:
В иерархии сертификатов корневым сертификатом является сам сертификат (самоподписанный).
Чтобы окончательно убедиться, что это недействительный сертификат, с браузера Chrome выполнил Online проверку актуального сертификата sslshopper.com и сверил серийные номера:
Теперь было необходимо найти этот троян. В настройках прокси было все чисто, а антивирус не дал никаких результатов. Полез в мониторинг сети и заметил некое приложение, которое проявляло активность всякий раз, когда я обращался к веб сервисам:
Первая же ссылка в интернете раскрыла все карты. Оказалось, что недавно наше руководство внесло некоторые поправки в политику защиты конфиденциальной информации. Было решено установить всему персоналу программу StaffCop, которая осуществляет мониторинг деятельности сотрудников. После отключения данной службы, решились не только проблемы с сертификатами, но и с моим основным браузером Chrome. Несмотря на большое описание, фактически задача была решена очень быстро, и я надеюсь, что последовательность моих действий поможет кому-либо.
А напоследок, то, как должны выглядеть «правильные» сертификаты:
Комментарии (33)
bougakov
12.10.2015 18:48+5Было решено установить всему персоналу программу StaffCop
После отключения данной службы
Ваша организация централизованно ставит сотрудникам софт и доверенные сертификаты, но не отбирает админские права (без которых не получится остановить службу)? Оригинальненько.
GebekovAS
12.10.2015 18:50+3Права на самом деле отобраны (у большей части), просто я отношусь к пользователям с особыми правами.
ploop
12.10.2015 20:31+1Было решено установить всему персоналу программу StaffCop, которая осуществляет мониторинг деятельности сотрудников
Я правильно понимаю, что о таких действиях сотрудники должны быть информированы под подпись?
Delphinum
13.10.2015 01:08+1Там где работает автор, начальство мало интересуется своими обязанностями.
mayorovp
12.10.2015 20:39+1в иерархии сертификатов корневым сертификатом является сам сертификат (самоподписанный).
Нет, это был не самоподписанный сертификат. Наверху иерархии он оказался по той причине, что сертификат его издателя не был найден.GebekovAS
12.10.2015 20:47Согласен, запись кем выдан уже говорит нам, что это не самоподписанный. Меня иерархия запутала, обычно системное окно отображает корневой сертификат даже если ему нет доверия=) Когда в хроме увидел, что сертификат имеет свой ЦС, то удостоверился что он не самоподписанный, но забыл прописать в статье.
mayorovp
12.10.2015 21:57+1«Сертификат известен, но нет доверия» и «сертификат не найден» — это разные ситуации, и обрабатываются они по разному.
Обычно сервер отдает не только свой сертификат — но и всю цепочку. Однако, так делать не обязательно. Ваш прокси-сервер решил послать только свой сертификат — вот и получилось что получилось.GebekovAS
12.10.2015 23:40Спасибо за разъяснение, но разве информация в поле «иерархия сертификата» не идентична информации во вкладке «путь сертификации» в системном окне просмотра свойств сертификата? Мне всегда казалось, что если сертификат выдан каким либо центром сертификации, то он должен отображаться в пути сертификации (даже если сертификата физически нет, но описание все равно должно быть указано).
mayorovp
13.10.2015 06:09Да, идентична. Нет, при ненайденном издателе сертификат в обоих окнах остается единственной строчкой насколько я помню.
ipswitch
12.10.2015 22:27Догадался кто виновник сразу после упоминания AtomPark Software.
Означенный StaffCop — не новая программа, но так и не отлаженная. Жуткое глюкалово! После её установки многое начинает глючить и тормозить.vma
13.10.2015 15:00Уже много более качественных, стабильных и функциональных аналогов есть, вот например SecureTower:
falcongaze.ru
J_o_k_e_R
13.10.2015 00:03+3Почему chrome, а не Google, но mozilla, а не Firefox? Может стоит называть правильно то, про что Вы пишете? Если что, ПО с названием mozilla (suite) тоже было, но Вы явно не про него.
GebekovAS
13.10.2015 08:07+1Это моя давняя привычка от которой пора избавиться=) Заголовок и метки не стал трогать, а в основном подправил. Спасибо за резонное замечание.
SkidanovAlex
13.10.2015 03:07+1> Браузер даже не дает права проигнорировать ошибку.
Если я правильно помню, если развернуть «Технические Детали» внизу, там будет опция проигнорировать ошибку.
ComodoHacker
13.10.2015 09:49Вы не совсем верно интерпретировали свои наблюдения.
StaffCop установил свой корневой сертификат также и в хранилище сертификатов Firefox, его видно на вашем скриншоте окна «Управление сертификатами». Обратите внимание на надпись «Модуль защиты» рядом с ним, она говорит о том, что сертификат не встроенный, а установлен извне.
Но это не сработало из-за пиннинга, который в Firefox работает жестко. В то время как Chrome только отправляет информацию в Гугл о подозрительных сертификатах.
И еще, если пользуетесь Firefox, обязательно установите расширение Cretificate Patrol. Оно поможет заметить подозрительный сертификат по косвенным признакам, даже если он подписан как положено (например украденным ключом корневого CA).GebekovAS
13.10.2015 15:24Спасибо за подробное разъяснение. Я заметил, что корневой сертификат присутствует в хранилище (про «модуль защиты» не знал) и стал грешить на то, что сертификат самоподписанный, что и сподвигло меня на онлайн проверку. Комментарием выше мне уже объяснили, что отсутствие корневого сертификата в иерархии не признак самоподписанного сертификата. Получается, мне просто повезло, что у FireFox более жесткий процесс пиннинга чем у Chrome.
Теперь возник вопрос: Будет ли правильным все эти поправки перенести в конец статьи или наличие их в комментариях будет достаточным?mayorovp
13.10.2015 16:01Кстати, интересный вопрос — а пинниг ли это, или корневому сертификату просто нет доверия?
Что, если снова найти корневой сертификат в хранилище и нажать на кнопку «Изменить доверия»?ComodoHacker
13.10.2015 16:44Кстати, интересный вопрос — а пинниг ли это, или корневому сертификату просто нет доверия?
В данном случае это одно и то же. :)mayorovp
13.10.2015 18:18Нет, это не одно и то же.
Certificate pinning — это привязка к конкретному сертификату без проверки иерархии, или проверка всего одного уровня иерархии.
В данном же случае иерархия проверяется полностью, просто корневого сертификата нет в списке доверенных.
DanXai
13.10.2015 11:02На днях была аналогичная проблема в Хроме. Выяснилось, что Хрм не доверяет сертификату от Comodo.
GebekovAS
14.10.2015 09:33В свое время использовал сертификат от Comodo только потому, что на моем телефоне (Android) ему было доверие (поднимал Lync для демонстрации клиенту). Если не ошибаюсь, они еще тогда в архиве помимо моих сертификатов отправляли сертификат центра и вроде тоже приходилось вручную помещал его в хранилище доверительных центров на машинах с Windows 7. Думаю в поздних версиях (Windows 8 и 10) они уже включены.
ComodoHacker
13.10.2015 17:06Еще один сайт для проверки наличия подмененных корневых сертификатов: https://superfish.tlsfun.de/
Valdei
Получается, хром на такую подмену не реагировал, левый сертификат обнаружился только при переходе на FFox?
Тормоза — это, конечно, заметно, но как-то недостаточно информативно.
Кстати, а в трудовом договоре у вас есть пункт про возможность сбора информации о деятельности сотрудника?
RazorBlade
Chrome, скорее всего не среагировал, т.к. в организации внедрили в ОС свой сертификат на рабочие компьютеры, например групповыми политиками. А FF не смотрит на сертификаты ОС, а использует свою базу.
GebekovAS
Вот, что видит хром если включить службу:
… а вот, что видит если отключить:
Нет, в трудовом такой пометки нет=)
blind_oracle
Хром использует системное хранилище сертификатов, лиса — своё.
Свой сертификат Staffcop Agent добавляет в систему в доверенные при установке.
farcaller
Но в хроме же по идее SSL Pinning на сертификаты сайтов Google и он все равно не должен дать зайти на google.com с чужим сертификатом:
blind_oracle
В идеале, конечно, именно так. Они много где об этом пишут.
Но на деле, по крайней мере в enterprise версии Хрома (которая из MSI ставится), картина такая:
То есть, Хром без проблем жуёт сертификат для google.com, который сгенерировал прокси-сервер.
lexore
blind_oracle
Почитав Security FAQ наткнулся на такое:
То есть, если корневой сертификат в цепочке доверия — частный (то бишь не поставлялся с ОС, а был добавлен вручную), то Certificate Pinning отключается.