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

Сегодня утром, после горячей чашечки шоколада кофе, в голову пришла идея сменить привычный мне браузер Chrome на Mozilla. Причиной тому было скорее не кофе, а аномальная тормознутость моего браузера в последнее время. После первого запуска предательски ввожу в адресную строку «google.ru» и вижу следующую ошибку:

341bb6e75c3b4fab8b209e73f6838e19.png
Браузер даже не дает права проигнорировать ошибку. По привычке первым делом взгляд упал на дату и время. Убедившись, что временные параметры на компьютере установлены верно, перешел на другой ресурс «yandex.ru»:

36a696b20b02469ab457d34431ee18ba.png

Тут дела обстояли чуть лучше, Mozilla уже предлагает добавить сертификат в хранилище доверенных. Тут пришлось уже включать мозги, т.к. активно пользуюсь сервисом Яндекс.Деньги и любые утечки для меня существенны. Первым делом решил проверить, что именно браузеру не нравится в сертификате:

d3bfd9fff7ac429eb1897ad3dc1862f4.png

Нет доверия стороне выдавшей сертификат. И такая картина на всех ресурсах, где используется безопасное соединение HTTPS.
Много немного теории:
Для использования шифрованного канала связи, ваш браузер использует протокол SSL (или TLS) (HTTPS пользуется им), который, в свою очередь, использует сертификат проверки подлинности. Этот сертификат хранит в себе информацию как для шифрования данных, так и для идентификации WEB-сервера, к которому вы обращаетесь. Помимо всей прочей информации, хранимой в сертификате (тип шифрования, альтернативные имена и т.д.), нас интересуют открытый ключ, который решает проблему №1 — шифрование в открытых сетях и информация о центре, выдавшем этот сертификат, которая решает проблему №2 — доверие к открытому ключу.

Опишу на примерах.
Сценарий 1:
1. Сервис Яндекс хочет организовать безопасный канал связи со своими пользователями и генерирует для этого пару ключей (открытый и закрытый).
2. Я, как клиент сервиса Яндекс, получаю от него открытый ключ и шифрую им все свои данные. При этом я уверен, что прочитать данные сможет только владелец закрытого ключа, в нашем случае владелец — сервис Яндекс.
Этим самым сервис Яндекс решает проблему шифрования в открытых сетях.

А что если некий троянский вирус встанет между вами и сервисом Яндекс (к примеру, в роли сквозного прокси-сервера)…???
Сценарий 2:
1. Троян получает от сервиса Яндекс открытый ключ.
2. Троян генерирует пару своих ключей и передает открытую часть вам от имени сервиса Яндекс.
3. Все сообщения, адресованные от вас сервису Яндекс, перехватываются и дешифруются трояном, а троян в свою очередь шифрует эти данные ключом от Яндекс и передает их ему же. Вот тут и возникает проблема №2, а именно, проблема доверия к открытому ключу.

Данная проблема решается третьим лицом, которому доверяет, как сервис Яндекс, так и клиент. В данном случае запись указывала на AtomPark Software Inc, которая выдала тот самый сертификат подлинности сервису Яндекс.

Вернемся к моему сертификату и удостоверимся, что мы доверяем третьему лицу. В поле Общее имя (CN) группы «кем выдано» стоит запись «AtomPark Software Inc». Первый признак доверия этому центру сертификации – наличие его корневого сертификата в хранилище доверительных центров. В Mozille этот список можно открыть так: Настройка-> Дополнительно-> Сертификаты-> Просмотреть сертификаты-> Центры сертификации. По имени нашел сертификат:

b6d3a8a265064aaeaed20d465eb4083d.png

На первый взгляд все в порядке. Решил сверить отпечатки SHA1 сертификатов. Полез в иерархию и увидел следующее:

d8b70083c4404fa0b3dd7f4bbd33a577.png

В иерархии сертификатов корневым сертификатом является сам сертификат (самоподписанный).
Чтобы окончательно убедиться, что это недействительный сертификат, с браузера Chrome выполнил Online проверку актуального сертификата sslshopper.com и сверил серийные номера:

25c8778c4a844750983f5cac8eeb9480.jpg

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

3f21ebbebaf44d21956ff73e15bb241f.png

Первая же ссылка в интернете раскрыла все карты. Оказалось, что недавно наше руководство внесло некоторые поправки в политику защиты конфиденциальной информации. Было решено установить всему персоналу программу StaffCop, которая осуществляет мониторинг деятельности сотрудников. После отключения данной службы, решились не только проблемы с сертификатами, но и с моим основным браузером Chrome. Несмотря на большое описание, фактически задача была решена очень быстро, и я надеюсь, что последовательность моих действий поможет кому-либо.

А напоследок, то, как должны выглядеть «правильные» сертификаты:

8934e6f7701b4246bb23020e6fd90dc4.png
8146875bc2af482ebdf0d014ea4dae41.png

© Geektimes