Две недели назад пользователи macOS начали сообщать о странных зависаниях при открытии приложений, не загруженных из Mac App Store. Многие подозревали аппаратные проблемы со своими устройствами, но из социальных сетей они узнали, что это широко распространённая проблема. И не случайно она возникла вскоре после запуска macOS Big Sur.
В конце концов, твит Джеффа Джонсона точно указал основную причину. Оказалось, что эппловская служба “OCSP Responder” слишком перегружена, поэтому macOS не могла проверить криптографические сертификаты разработчиков приложений.
Но почему служба OCSP Responder оказалась на критическом пути запуска приложений? В этой статье мы кратко обсудим подпись кода, как работает онлайн-протокол статуса сертификата (OCSP), почему он абсолютно неправильный и некоторые лучшие альтернативы. В отличие от других заметок о данном инциденте, я хочу обсудить именно практические криптографические аспекты (на высоком уровне) и предложить сбалансированную перспективу.
На портале разработчиков Apple объясняет цель подписи кода:
Другими словами, чтобы приложению доверяли в macOS, его нужно подписать собственным сертификатом на основе пары ключей. Связка ключей используется для создания уникального сертификата «идентификатор разработчика», который включает в себя закрытый ключ для использования разработчиком и открытый ключ для распространения. Когда Apple подписала сертификат Developer ID, разработчик может использовать закрытый ключ для создания криптографических подписей на своих приложениях при каждом релизе.
При запуске приложения его подпись проверяется по открытому ключу сертификата разработчика. Затем проверяется сам сертификат, что срок его действия не истёк (сертификаты обычно действительны в течение одного года), и что в конечном итоге он подписан корневым сертификатом Apple. Также могут быть промежуточные сертификаты как часть цепочки вплоть до корневого сертификата. Это «цепочка доверия», поскольку сертификат Developer ID подписал приложение, промежуточный сертификат подписал сертификат Developer ID, а корневой сертификат Apple подписал промежуточный сертификат. Любое устройство Apple может проверить эту цепочку доверия и, следовательно, одобрить запуск приложения.
Это похоже на инфраструктуру открытых ключей TLS в интернете. Но также и принципиально отличается, поскольку у Apple полный контроль над собственной цепочкой доверия. Другим центрам сертификации не разрешается выдавать действительные сертификаты для подписи кода, поскольку все сертификаты должны быть привязаны к Apple.
Если верификация не прошла, то пользователь увидит страшное окно:
Что происходит, если разработчик нарушает правила Apple или теряет свой закрытый ключ? Центр сертификации должен мгновенно аннулировать выданные сертификаты. Если сертификат используется злонамеренно, недопустимо ждать дни или месяцы, пока он не истечёт естественным образом, иначе утечка секретного ключа сделает всю систему бесполезной.
Именно в такой ситуации происходит отзыв сертификата. Это дополнительный шаг в процессе проверки подписи, который включает в себя выяснение у центра сертификации, что сертификат всё ещё действителен.
В интернете это делается самым простым способом. Центр сертификации выдаёт вам список отозванных сертификатов (Certificate Revocation List, CRL) с серийными номерами всех отозванных сертификатов, и вы проверяете, что сертификат отсутствует в этом списке. Однако браузеры перестали использовать такой подход, так как список становился всё длиннее и длиннее. Особенно после того, как ужасающие эксплоиты вроде Heartbleed потребовали массового отзыва сертификатов.
Online Certificate Status Protocol (OCSP) — это альтернатива, позволяющая проверять сертификаты в режиме реального времени. Каждый сертификат содержит встроенный «ответчик OCSP» (OCSP Responder) — это URL-адрес, который вы запрашиваете, а он сообщает, был ли сертификат отозван. В случае с Apple это
Огромная проблема OCSP в том, что внешняя служба становится единой точкой отказа. Что произойдёт, если ответчик OCSP не работает или недоступен? Мы просто отказываемся проверять сертификат (hard-fail)? Или мы делаем вид, что проверка прошла успешно (soft-fail)?
Apple вынуждена использовать поведение soft-fail, иначе приложения не будут работать в офлайне. Все основные браузеры также реализуют поведение soft-fail, поскольку ответчики OCSP традиционно ненадёжны, а браузер хочет загрузить сайт, даже если ответчик центра сертификации временно не работает.
Но soft-fail (мягкий отказ) — не очень хороший вариант, потому что при наличии контроля над сетью злоумышленник может блокировать запросы к ответчику, и проверка будет пропущена. На самом деле такое «исправление» ошибки широко разошлось в твиттере во время этого инцидента: трафик к
Если проверка OCSP у Apple построена на мягком отказе, то почему приложения зависали при отключении ответчика OCSP? Вероятно, потому что на самом деле это был другой сбой: ответчик OCSP на самом деле не был полностью отключён. Он просто плохо работал.
Из-за нагрузки от миллионов пользователей со всего мира, которые обновлялись на macOS Big Sur, серверы Apple замедлились и не отвечали должным образом на запросы OCSP. Но при этом работали достаточно хорошо, чтобы не сработал soft-fail.
В дополнение к проблеме доступности OCSP, протокол изначально не рассчитан на защиту приватности. Базовый запрос OCSP включает в себя незашифрованный HTTP-запрос к ответчику OCSP с серийным номером сертификата. Таким образом, не только ответчик может определить, какой сертификат вас интересует, но и ваш провайдер и любой другой человек, перехватывающий пакеты. Apple может составить список по порядку, приложения каких разработчиков вы открываете, и то же самое могут сделать посторонние лица.
Можно было бы добавить шифрование, и есть лучшая, более приватная версия под названием OCSP stapling, но Apple не сделала ни того, ни другого. На самом деле OCSP stapling не имеет смысла в этом сценарии, но эта технология иллюстрирует, что OCSP не должна допускать утечки данных по умолчанию.
Этот инцидент вызвал оживлённую дискуссию в сообществе, причём одна сторона заявила: «Ваш компьютер на самом деле не ваш», а другая утверждает, что «Установить доверие к приложениям трудно, но Apple делает это хорошо». Я пытаюсь показать, что OCSP — это в любом случае ужасный способ управления отзывами сертификатов, а в будущем он приведёт к новым инцидентам, связанным с доступностью ответчиков и приватностью. На мой взгляд, это плохое инженерное решение — устанавливать зависимость запуска приложений от OCSP. По крайней мере, в краткосрочной перспективе они уменьшили ущерб, увеличив время кэширования ответов.
К счастью, практически созрел лучший метод отзыва сертификатов — CRLite. Он позволяет сократить до разумного размера списки всех отозванных сертификатов. В блоге Скотта Хельме даётся хорошее резюме, как CRLite использует фильтры Блума, чтобы вернуть прежний подход со списком отозванных сертификатов, который действовал до OCSP.
Устройства macOS могут периодически получать обновления этого списка CRL и выполнять проверку локально на устройстве, что решает проблемы доступности и конфиденциальности OCSP. С другой стороны, поскольку список отозванных сертификатов Developer ID намного меньше, чем список всех отозванных сертификатов PKI, стоит спросить, почему Apple не использует CRL. Возможно, они не хотят раскрывать информацию о том, какие сертификаты отозваны.
В целом, этот инцидент стал хорошим поводом поразмышлять о модели доверия, которую продвигают такие организации, как Apple и Microsoft. Вредоносное ПО стало более изощренным, и большинство людей не в состоянии определить, безопасно ли запускать определённые бинарные файлы. Подпись кода кажется отличным криптографическим способом установить доверие для приложений и хотя бы связать приложения с известными разработчиками. И отзыв сертификатов является необходимой частью этого доверия.
Но всего несколько сбоев в процессе проверки OCSP портит всю криптографическую элегантность процесса подписи и проверки кода. OCSP также широко используется для сертификатов TLS в интернете, но там сбои менее катастрофичны из-за большого количества центров сертификации и повсеместного игнорирования сбоев со стороны браузеров. Более того, люди привыкли видеть веб-сайты время от времени недоступными, но они не ожидают того же от приложений на собственных компьютерах. Пользователей macOS обеспокоило то, что их собственные приложения пострадали из-за проблем инфраструктуры Apple. Однако это неизбежный результат, вытекающий из того факта, что проверка сертификатов зависит от внешней инфраструктуры, а никакая инфраструктура не является надёжной на 100%.
Скотт Хельме также выражает опасения по поводу власти, которую получают центры сертификации, если аннулирование сертификатов работает действительно эффективно. Даже если вас не беспокоит потенциальная возможность цензуры, иногда будут возникать ошибки, и их следует взвешивать относительно преимуществ безопасности. Как обнаружил один разработчик, когда Apple по ошибке отозвала его сертификат, риск работы на изолированной платформе заключается в том, что вас самого могут изолировать от неё.
В конце концов, твит Джеффа Джонсона точно указал основную причину. Оказалось, что эппловская служба “OCSP Responder” слишком перегружена, поэтому macOS не могла проверить криптографические сертификаты разработчиков приложений.
Но почему служба OCSP Responder оказалась на критическом пути запуска приложений? В этой статье мы кратко обсудим подпись кода, как работает онлайн-протокол статуса сертификата (OCSP), почему он абсолютно неправильный и некоторые лучшие альтернативы. В отличие от других заметок о данном инциденте, я хочу обсудить именно практические криптографические аспекты (на высоком уровне) и предложить сбалансированную перспективу.
Подпись кода
На портале разработчиков Apple объясняет цель подписи кода:
Подпись кода вашего приложения гарантирует пользователям, что оно взято из известного источника и не изменено с момента последней подписи. Прежде чем интегрировать службы (app services), установиться на устройство или попасть в каталог приложений, приложение должно быть подписано сертификатом, выданным Apple.
Другими словами, чтобы приложению доверяли в macOS, его нужно подписать собственным сертификатом на основе пары ключей. Связка ключей используется для создания уникального сертификата «идентификатор разработчика», который включает в себя закрытый ключ для использования разработчиком и открытый ключ для распространения. Когда Apple подписала сертификат Developer ID, разработчик может использовать закрытый ключ для создания криптографических подписей на своих приложениях при каждом релизе.
При запуске приложения его подпись проверяется по открытому ключу сертификата разработчика. Затем проверяется сам сертификат, что срок его действия не истёк (сертификаты обычно действительны в течение одного года), и что в конечном итоге он подписан корневым сертификатом Apple. Также могут быть промежуточные сертификаты как часть цепочки вплоть до корневого сертификата. Это «цепочка доверия», поскольку сертификат Developer ID подписал приложение, промежуточный сертификат подписал сертификат Developer ID, а корневой сертификат Apple подписал промежуточный сертификат. Любое устройство Apple может проверить эту цепочку доверия и, следовательно, одобрить запуск приложения.
Это похоже на инфраструктуру открытых ключей TLS в интернете. Но также и принципиально отличается, поскольку у Apple полный контроль над собственной цепочкой доверия. Другим центрам сертификации не разрешается выдавать действительные сертификаты для подписи кода, поскольку все сертификаты должны быть привязаны к Apple.
Если верификация не прошла, то пользователь увидит страшное окно:
Отзыв
Что происходит, если разработчик нарушает правила Apple или теряет свой закрытый ключ? Центр сертификации должен мгновенно аннулировать выданные сертификаты. Если сертификат используется злонамеренно, недопустимо ждать дни или месяцы, пока он не истечёт естественным образом, иначе утечка секретного ключа сделает всю систему бесполезной.
Именно в такой ситуации происходит отзыв сертификата. Это дополнительный шаг в процессе проверки подписи, который включает в себя выяснение у центра сертификации, что сертификат всё ещё действителен.
В интернете это делается самым простым способом. Центр сертификации выдаёт вам список отозванных сертификатов (Certificate Revocation List, CRL) с серийными номерами всех отозванных сертификатов, и вы проверяете, что сертификат отсутствует в этом списке. Однако браузеры перестали использовать такой подход, так как список становился всё длиннее и длиннее. Особенно после того, как ужасающие эксплоиты вроде Heartbleed потребовали массового отзыва сертификатов.
Online Certificate Status Protocol (OCSP) — это альтернатива, позволяющая проверять сертификаты в режиме реального времени. Каждый сертификат содержит встроенный «ответчик OCSP» (OCSP Responder) — это URL-адрес, который вы запрашиваете, а он сообщает, был ли сертификат отозван. В случае с Apple это
ocsp.apple.com. Так что теперь, в дополнение к проверке криптографической достоверности подписи, каждый раз при запуске приложения вы выполняете проверку в реальном времени на сайте Apple (с некоторым кэшированием), что они всё ещё считают сертификат разработчика легитимным.Проблема доступности OCSP
Огромная проблема OCSP в том, что внешняя служба становится единой точкой отказа. Что произойдёт, если ответчик OCSP не работает или недоступен? Мы просто отказываемся проверять сертификат (hard-fail)? Или мы делаем вид, что проверка прошла успешно (soft-fail)?
Apple вынуждена использовать поведение soft-fail, иначе приложения не будут работать в офлайне. Все основные браузеры также реализуют поведение soft-fail, поскольку ответчики OCSP традиционно ненадёжны, а браузер хочет загрузить сайт, даже если ответчик центра сертификации временно не работает.
Но soft-fail (мягкий отказ) — не очень хороший вариант, потому что при наличии контроля над сетью злоумышленник может блокировать запросы к ответчику, и проверка будет пропущена. На самом деле такое «исправление» ошибки широко разошлось в твиттере во время этого инцидента: трафик к
ocsp.apple.com блокировался строчкой в файл /etc/hosts. Многие оставят эту строчку в ближайшее время, поскольку отключение OCSP не вызывает никаких заметных проблем.Инцидент
Если проверка OCSP у Apple построена на мягком отказе, то почему приложения зависали при отключении ответчика OCSP? Вероятно, потому что на самом деле это был другой сбой: ответчик OCSP на самом деле не был полностью отключён. Он просто плохо работал.
Из-за нагрузки от миллионов пользователей со всего мира, которые обновлялись на macOS Big Sur, серверы Apple замедлились и не отвечали должным образом на запросы OCSP. Но при этом работали достаточно хорошо, чтобы не сработал soft-fail.
Проблема приватности OCSP
В дополнение к проблеме доступности OCSP, протокол изначально не рассчитан на защиту приватности. Базовый запрос OCSP включает в себя незашифрованный HTTP-запрос к ответчику OCSP с серийным номером сертификата. Таким образом, не только ответчик может определить, какой сертификат вас интересует, но и ваш провайдер и любой другой человек, перехватывающий пакеты. Apple может составить список по порядку, приложения каких разработчиков вы открываете, и то же самое могут сделать посторонние лица.
Можно было бы добавить шифрование, и есть лучшая, более приватная версия под названием OCSP stapling, но Apple не сделала ни того, ни другого. На самом деле OCSP stapling не имеет смысла в этом сценарии, но эта технология иллюстрирует, что OCSP не должна допускать утечки данных по умолчанию.
Лучшее будущее
Этот инцидент вызвал оживлённую дискуссию в сообществе, причём одна сторона заявила: «Ваш компьютер на самом деле не ваш», а другая утверждает, что «Установить доверие к приложениям трудно, но Apple делает это хорошо». Я пытаюсь показать, что OCSP — это в любом случае ужасный способ управления отзывами сертификатов, а в будущем он приведёт к новым инцидентам, связанным с доступностью ответчиков и приватностью. На мой взгляд, это плохое инженерное решение — устанавливать зависимость запуска приложений от OCSP. По крайней мере, в краткосрочной перспективе они уменьшили ущерб, увеличив время кэширования ответов.
К счастью, практически созрел лучший метод отзыва сертификатов — CRLite. Он позволяет сократить до разумного размера списки всех отозванных сертификатов. В блоге Скотта Хельме даётся хорошее резюме, как CRLite использует фильтры Блума, чтобы вернуть прежний подход со списком отозванных сертификатов, который действовал до OCSP.
Устройства macOS могут периодически получать обновления этого списка CRL и выполнять проверку локально на устройстве, что решает проблемы доступности и конфиденциальности OCSP. С другой стороны, поскольку список отозванных сертификатов Developer ID намного меньше, чем список всех отозванных сертификатов PKI, стоит спросить, почему Apple не использует CRL. Возможно, они не хотят раскрывать информацию о том, какие сертификаты отозваны.
Заключение
В целом, этот инцидент стал хорошим поводом поразмышлять о модели доверия, которую продвигают такие организации, как Apple и Microsoft. Вредоносное ПО стало более изощренным, и большинство людей не в состоянии определить, безопасно ли запускать определённые бинарные файлы. Подпись кода кажется отличным криптографическим способом установить доверие для приложений и хотя бы связать приложения с известными разработчиками. И отзыв сертификатов является необходимой частью этого доверия.
Но всего несколько сбоев в процессе проверки OCSP портит всю криптографическую элегантность процесса подписи и проверки кода. OCSP также широко используется для сертификатов TLS в интернете, но там сбои менее катастрофичны из-за большого количества центров сертификации и повсеместного игнорирования сбоев со стороны браузеров. Более того, люди привыкли видеть веб-сайты время от времени недоступными, но они не ожидают того же от приложений на собственных компьютерах. Пользователей macOS обеспокоило то, что их собственные приложения пострадали из-за проблем инфраструктуры Apple. Однако это неизбежный результат, вытекающий из того факта, что проверка сертификатов зависит от внешней инфраструктуры, а никакая инфраструктура не является надёжной на 100%.
Скотт Хельме также выражает опасения по поводу власти, которую получают центры сертификации, если аннулирование сертификатов работает действительно эффективно. Даже если вас не беспокоит потенциальная возможность цензуры, иногда будут возникать ошибки, и их следует взвешивать относительно преимуществ безопасности. Как обнаружил один разработчик, когда Apple по ошибке отозвала его сертификат, риск работы на изолированной платформе заключается в том, что вас самого могут изолировать от неё.
