Прозрачность сертификатов (CT) — отличный проект компании Google, который сейчас фактически стал стандартом де-факто в интернете. Серверы CT показывают все выпущенные EV-сертификаты в открытых и общедоступных источниках.

Всё работает отлично до тех пор, пока не сломается.

В частности, в последнее время браузер Chrome создал ряд проблем под Android, фактически заблокировав работу сторонних приложений, таких как снифферы, MitM-прокси и средства разработки. Эти программы устанавливают в систему собственные доверенные сертификаты для перехвата и разбора трафика.

Первые признаки проблемы появились в мае 2022 года. Примерно в этом время в документации Chrome Enterprise v99 под Android возникло следующее примечание о прозрачности сертификатов:



Написано, что CT уже действует на десктопах, а сейчас распространится на всех пользователей Android Chrome.

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



После внедрения CT все эти инструменты при попытки проанализировать HTTPS-трафик или совершить другое действие от имени своего корневого сертификата получат одинаковую ошибку: «Требуется прозрачность сертификата» (на скриншоте).

ERR_CERTIFICATE_TRANSPARENCY_REQUIRED

Что такое Certificate Transparency (CT)

Certificate Transparency (RFC 6962, а недавно принята вторая версия RFC 9162) — стандарт безопасности для мониторинга цифровых сертификатов в интернете. Он работает через систему публичных журналов, куда в конечном итоге попадают все сертификаты, выданные центрами сертификации.



Однако в публичный лог не попадёт ваш личный самоподписанный сертификат, который вы сделали для использования на своём собственном смартфоне. В этом и проблема.

Модель угрозы

Понятно, от какой угрозы CT защищает пользователей.

Различные злоумышленники пытаются установить в систему доверенные сертификаты своих собственных центров сертификации. Так пытаются сделать некоторые VPN-сервисы, китайские зловреды, национальные провайдеры и др. В этом случае система глобального доверия может оказаться подорвана, потому что MiTM-актор с корневым сертификатом сможет читать и подменять любую информацию в канале HTTPS, то есть к любому защищённому сайту, включая Google, Gmail и др.

Жертва такой атаки будет нормально подключаться к настоящим сайтам. В то же время трафик можно прослушать третьему лицу. Браузер не заметит подделки и будет сигнализировать «замочком» HTTPS, что всё нормально. Это очень опасно. Отдельные люди годами сидят на такой «прослушке» и ничего не замечают.

Поэтому прозрачность сертификатов введена неспроста. Общий прозрачный лог сертификатов в виде глобального дерева Меркла хранит все документы от каждого глобального центра сертификации, с метками времени (SCT), а браузеры проверяют эти SCT. Данные метки служат определённым доказательством, что сертификат предъявлен общественности и внесён в открытую базу. Ну и любой желающий всегда может посмотреть эту базу и проверить SCT.

Но бывают исключительные ситуации, когда установка MiTM-прокси реально необходима. Например, для дебаггинга трафика при разработке мобильных и веб-приложений, для реверс-инжиниринга, пентестинга. Есть целый класс инструментов, таких как mitmproxy и HTTP Toolkit специально для подобных целей. Они в процессе работы выдают поддельные сертификаты для серверов, к которым подключается клиент (с разрешения клиента, то есть браузера). Работа таких инструментов теперь затруднена, потому что браузер больше не даёт разрешения.

От «принудительной защиты» со стороны Chrome пострадают в первую очередь профессиональные разработчики, тестеры, специалисты по безопасности, исследователи.

Хранилища сертификатов

На устройстве Android в реальности установлено несколько разных хранилищ сертификатов (CA):

• /system/etc/security/cacerts/
  
• /data/misc/user/0/cacerts-added/
  
• CA отдельного приложения

Раньше можно было просто поместить свой MitM-сертификат в системное хранилище (такое возможно после рутования) — и система ему доверяла. Ваша «троянская» программа нормально работала и сканировала трафик к любым доменам для дебаггинга и веб-разработки.

Но с версии Android Chrome 99 браузер начинает проверять метки SCT для всех сертификатов, которые выдаёт ваш MitM-прокси, на каждой страничке выбрасывая ошибки NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED.

Как исправить

В Chromium это не признали багом (статус WontFix), поэтому решать проблему придётся самостоятельно.



Разработчики HTTP Toolkit поясняют, что нам просто нужно запустить Chrome с флагом --ignore-certificate-errors-spki-list=$YOUR_SPKI_FINGERPRINT. Они предлагают такой обходной путь (на рутованном смартфоне):

1. Сделайте отпечаток SPKI своего сертификата:
   
   openssl x509 -in $YOUR_CA_CERTIFICATE -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
   
   
2. Создайте файл с одной строкой:
   
   chrome --ignore-certificate-errors-spki-list=$YOUR_SPKI_FINGERPRINT
   
   
3. Командой adb push скопируйте файл на устройство Android по следующим адресам:
   
   
   • /data/local/chrome-command-line
     
   • /data/local/android-webview-command-line
     
   • /data/local/webview-command-line
     
   • /data/local/content-shell-command-line
     
   • /data/local/tmp/chrome-command-line
     
   • /data/local/tmp/android-webview-command-line
     
   • /data/local/tmp/webview-command-line
     
   • /data/local/tmp/content-shell-command-line
   
   Это гарантирует его применение для всех версий Chromium как в нормальном, так и в отладочном окружении.
   
   
4. Установите разрешения для всех файлов: chmod 555 <filename>, чтобы они были доступны для чтения Chromium при запуске.
   
5. Принудительно остановите Chrome (am force-stop com.android.chrome), а затем запустите снова.
   
6. Проверьте в chrome://version, что наш параметр командной строки сработал.

В принципе, эту последовательность действий можно прописать в автоматическом скрипте по AKB, если требуется изменить настройки браузера Chrome на большом количестве устройств.

На этом проблема решена.

---