dxdt.blog: занимательный интернет-журнал

Немного пояснений к предыдущей записке, о том, что в стандартную библиотеку Go crypto/x509 “гвоздями прибили” некоторые отпечатки открытых ключей, которым библиотека теперь не доверяет напрямую, минуя все прочие проверки. Причина, как бы, в том, что у некоторого УЦ утекли ключи от доверенных промежуточных сертификатов (по ссылке от Beldmit есть важные подробности). Что тут можно сказать? Основное: это максимально странная история – типичный костыль, неожиданность постановки которого только укрепляется тем, что это сделано в Go. Далее – чуть подробнее.

Во-первых, таким способом можно заблокировать на уровне библиотеки любые ключи из TLS-сертификатов, вне зависимости не только от системных настроек, но и от программного кода, который эту библиотеку вызывает. Например, можно заблокировать ключи какого-нибудь корпоративного УЦ. Из-за того, что в библиотеку встроены отпечатки (значения хеш-функций), даже понять, что это за ключ, не зная соответствующего сертификата, очень сложно. Представьте, что обычный разработчик использует данную библиотеку в своём приложении. Теперь этот разработчик обновил среду сборки на новую версию Go, пересобрал код приложения без изменений – бах! сертификаты не валидируются. Никаких политик, ничего подобного – не менялось.

А ведь данная библиотека даже не проверяет статус сертификата (не отозван ли), о чём там прямо написано в документации и комментариях. Конечно, если бы статус проверялся, то и вопрос бы, возможно, решился. Но не проверять статус сертификата автоматически – это совершенно нормально для такой, достаточно низкоуровневой, библиотеки. Прибивать внутри конкретные ключи – не нормально совсем. Ключи, заметьте, это даже не алгоритмы – алгоритмы в библиотеках Go для TLS блокировались и раньше, ключи в таком виде – пока не прибивали, это первый случай.

Во-вторых, что касается отзыва сертификатов, статуса, который, якобы, невозможно проверить. Да, в современных браузерах есть механизмы распространения отпечатков недоверенных ключей с обновлениями. Есть CRLSet (Chrome), который равно так и работает: без штатного механизма отзыва, по отпечаткам ключей напрямую. Но в данном случае речь про среду разработки. Неужели кто-то считает, что можно моментально пересобрать все те сотни приложений, которые используют данную библиотеку? Нет, это невозможно. В конкретном браузере – единый канал распространения обновлений и отлаженный процесс. При этом иногда приложения вообще не имеют автоматического механизма обновлений. Некоторые приложения не обновляются месяцами и годами, и там нет не то что механизма “пересборки”, но даже и процесса, который позволил бы штатно и быстро что-то пересобрать и доставить новые бинарные исполняемые файлы. То есть, “костыльная” схема с прибиванием ключей заведомо не является оперативной: многие и многие скомпилированные ранее приложения как работали, так и продолжат работать.

В-третьих, если такие экстраординарные меры, – специальный релиз Go, – приняты, то считаются ли теперь все вышеупомянутые приложения, собранные на старой версии, скомпрометированными? Непонятно. Да, механизмы управления списком доверенных сертификатов есть в ОС. Но, получается, эти механизмы тут сразу признаны неработающими. Надо заметить, что работают они, действительно, очень плохо, но это не означает, что нужно теперь в неплохую библиотеку “прибивать ключи гвоздями”. Более того, очевидно, что если приложение не имеет механизма управления списком доверия, то это приложение, вполне вероятно, не имеет и возможности нормального обновления через пересборку.

Нехорошая тенденция, в общем.

Адрес записки: https://dxdt.blog/2026/10/20/19447/