После выпуска Apple MacOS Big Sur почти сразу же возникли проблемы с сервером, из-за которых пользователи не могли запускать сторонние приложения на своих компьютерах. Вскоре люди в твиттере нашли обходной способ, но другие высказали некоторые опасения по поводу возможных проблем конфиденциальности, связанных с этим механизмом.
Это фатальное происшествие вызвало появление поста про «кошмар на улице Эпол», который сейчас находится в самом топе читаемых на хабре: https://habr.com/ru/post/528104/
В статье говорится что на волне проблем с серверами обновлений в день выхода апдейта macOS 11 Big Sur у Apple возникли проблемы также с серверами проверки сертификатов разработчиков при запуске приложений на Маках. В итоге приложения на старте жутко тормозили или вообще падали (потому что упс, лажа, система была заточена на то, что сервер может быть недоступен, но не заточена на то, что сервер может отвечать медленно). Что и породило текст со ссылкой выше, где в весьма драматических тонах со ссылками на Столлмана и прочим было рассказано, как Apple всё о вас знает, и что ваш компьютер больше вам не принадлежит.
Сама технология проверки приложений на старте далеко не нова, она называется GateKeeper, и предназначена для проверки сертификата каждой запускаемой программы, её подлинности и принадлежности сертифицированному Apple разработчику, чтобы пользователь не мог запустить вирус.
Также я хочу объяснить, почему полный драмы и ссылок на PRISM пост совершенно некорректный и не стоит принимать всю информацию, перечисленную в нём, за чистую монету.
Система проверяет на первом старте (и потом с какой-то вероятностью ещё иногда) валидность сертификата разработчика, и отсутствие приложения в базе известных вредоносных приложений. Тут кроется первая неточность статьи — то, что на сервера Apple уходит информация о каждом приложении, которое запускает пользователь. На самом деле на сервере проверяется некий кусок девелоперского сертификата, и если у разработчика несколько приложений, то это один и тот же кусок.
Второй момент — что эти данные пересылаются в открытом виде по HTTP, без какого-либо шифрования. Проверка проводится по OCSP — Online Certificate Status Protocol, открытом проколе, работающем по HTTP. Там есть некая лажа в том, что, используя шифрованный OCSP, можно попасть в бесконечный цикл валидации самого протокола и HTTPS соединения, но вообще да, Apple могла бы как раз напрячься и зашифровать эти данные, чтобы они не попадали неизвестно каким третьим сторонам.
Третье — информация о запусках приложений и верификации сертификатов не привязана к Apple ID пользователя. Соответственно, месседж статьи о том, как «Apple знает о том, что вы делали у себя дома и какие приложения запускали», на 99% процентов не соответствует действительности. Apple всячески рандомизирует данные пользователя о геолокации, меняя идентификаторы у себя в бэкенде каждые несколько часов, и, скорее всего, проверка сертификатов по OCSP происходит с фокусом на именно сертификатах, а не на Apple ID, который эти приложения запускает. Но все равно тот факт, что третьи стороны типа провайдера (или СОРМ) могут видеть куски информации о сертификате разработчика, привязанные, например, к IP адресу — лажа Apple, и мы возвращаемся к теме работы этой проверки по HTTP.
Что такое OCSP?
OCSP расшифровывается как Online Certificate Status Protocol. Как следует из названия, он используется для проверки действительности сертификата без необходимости загружать и сканировать большие списки отозванных по тем или иным причинам сертификатов. macOS использует OCSP, чтобы убедиться, что сертификат разработчика не был отозван перед запуском приложения.
Как объясняет Джефф Джонсон в своём твите выше, если macOS не может связаться с респондентом Apple OCSP, он все равно пропускает проверку и запускает приложение. Проблема в том, что сервер Apple не вышел из строя; он был доступен, но стал чрезвычайно долго обрабатывать запросы, и это не давало сработать механизму soft failure и отказаться от проверки.
Понятно, что этот механизм требует, чтобы macOS связалась с Apple перед запуском приложения. Внезапное осознание этого факта общественностью, вызванное проблемами Apple, вызвало некоторые опасения относительно конфиденциальности, и сообщение исследователя безопасности Джеффри Пола стало очень популярным в Twitter. Он утверждает, что
Что ещё хуже, для OCSP обычным явлением является использование HTTP — я говорю о самом обычном HTTP-протоколе на 80-м порту, а не об HTTPS. Для этого есть веская причина — служба OCSP используется для веб-браузеров и использование HTTPS привело бы к бесконечной рекурсии проверок. Если вы используете HTTPS для проверки сертификата с помощью OCSP, вам также необходимо будет проверить сертификат самого HTTPS-соединения с помощью OCSP. Это означает открытие ещё одного HTTPS-соединения и так далее. Конечно, хотя OCSP не требует шифрования, он требует, чтобы ответы были подписаны сервером. Это по-прежнему не решает первоначальную обеспокоенность тем, что любой, у кого есть анализатор трафика в вашей сети, может подслушивать каждое открытое вами приложение и когда вы его открываете.
Ну и самая главная и непонятная во всём этом история, на которой первоначальная статья фокусируется меньше всего — это ContentFilterExclusionList (/System/Library/Frameworks/NetworkExtension.framework/Versions/A/Resources/Info.plist), некий список приложений и системных сервисов в macOS, которые Apple решила роутить в системе самостоятельно. То есть если даже вы пользуетесь VPN, macOS решает, что уж эти приложения могут идти в интернет мимо VPN. Что вообще подрывает концепцию восприятия безопасности пользователем на корню, так как он, сидя на открытом вайфае, думает, что все его данные проходят через зашифрованный тоннель, а на самом деле хyй там. Более того, как было продемонстрировано экспертами, эта реализация чревата тем, что вредоносное ПО тоже может воспользоваться такими правилами обхода:
Что в итоге.
Apple выпустила новую статью с разъяснениями, в которой подтвердила, что проверки сертификатов никак не привязаны к Apple ID пользователя.
https://support.apple.com/en-us/HT202491
Кроме этого, компания пообещала в следующем году выпустить обновление, где проверки будут идти по зашифрованному каналу связи. Будет добавлена поддержка на случай проблем с сервером, и появится опция отключения такой функциональности.
Пиздец с ContentFilterExclusionList Apple скорее всего даже не станет исправлять и отделается ещё одной статьёй.
Это фатальное происшествие вызвало появление поста про «кошмар на улице Эпол», который сейчас находится в самом топе читаемых на хабре: https://habr.com/ru/post/528104/
В статье говорится что на волне проблем с серверами обновлений в день выхода апдейта macOS 11 Big Sur у Apple возникли проблемы также с серверами проверки сертификатов разработчиков при запуске приложений на Маках. В итоге приложения на старте жутко тормозили или вообще падали (потому что упс, лажа, система была заточена на то, что сервер может быть недоступен, но не заточена на то, что сервер может отвечать медленно). Что и породило текст со ссылкой выше, где в весьма драматических тонах со ссылками на Столлмана и прочим было рассказано, как Apple всё о вас знает, и что ваш компьютер больше вам не принадлежит.
Сама технология проверки приложений на старте далеко не нова, она называется GateKeeper, и предназначена для проверки сертификата каждой запускаемой программы, её подлинности и принадлежности сертифицированному Apple разработчику, чтобы пользователь не мог запустить вирус.
Также я хочу объяснить, почему полный драмы и ссылок на PRISM пост совершенно некорректный и не стоит принимать всю информацию, перечисленную в нём, за чистую монету.
Система проверяет на первом старте (и потом с какой-то вероятностью ещё иногда) валидность сертификата разработчика, и отсутствие приложения в базе известных вредоносных приложений. Тут кроется первая неточность статьи — то, что на сервера Apple уходит информация о каждом приложении, которое запускает пользователь. На самом деле на сервере проверяется некий кусок девелоперского сертификата, и если у разработчика несколько приложений, то это один и тот же кусок.
Второй момент — что эти данные пересылаются в открытом виде по HTTP, без какого-либо шифрования. Проверка проводится по OCSP — Online Certificate Status Protocol, открытом проколе, работающем по HTTP. Там есть некая лажа в том, что, используя шифрованный OCSP, можно попасть в бесконечный цикл валидации самого протокола и HTTPS соединения, но вообще да, Apple могла бы как раз напрячься и зашифровать эти данные, чтобы они не попадали неизвестно каким третьим сторонам.
Третье — информация о запусках приложений и верификации сертификатов не привязана к Apple ID пользователя. Соответственно, месседж статьи о том, как «Apple знает о том, что вы делали у себя дома и какие приложения запускали», на 99% процентов не соответствует действительности. Apple всячески рандомизирует данные пользователя о геолокации, меняя идентификаторы у себя в бэкенде каждые несколько часов, и, скорее всего, проверка сертификатов по OCSP происходит с фокусом на именно сертификатах, а не на Apple ID, который эти приложения запускает. Но все равно тот факт, что третьи стороны типа провайдера (или СОРМ) могут видеть куски информации о сертификате разработчика, привязанные, например, к IP адресу — лажа Apple, и мы возвращаемся к теме работы этой проверки по HTTP.
Что такое OCSP?
OCSP расшифровывается как Online Certificate Status Protocol. Как следует из названия, он используется для проверки действительности сертификата без необходимости загружать и сканировать большие списки отозванных по тем или иным причинам сертификатов. macOS использует OCSP, чтобы убедиться, что сертификат разработчика не был отозван перед запуском приложения.
Как объясняет Джефф Джонсон в своём твите выше, если macOS не может связаться с респондентом Apple OCSP, он все равно пропускает проверку и запускает приложение. Проблема в том, что сервер Apple не вышел из строя; он был доступен, но стал чрезвычайно долго обрабатывать запросы, и это не давало сработать механизму soft failure и отказаться от проверки.
Понятно, что этот механизм требует, чтобы macOS связалась с Apple перед запуском приложения. Внезапное осознание этого факта общественностью, вызванное проблемами Apple, вызвало некоторые опасения относительно конфиденциальности, и сообщение исследователя безопасности Джеффри Пола стало очень популярным в Twitter. Он утверждает, что
Это действительно жутко.
Что ещё хуже, для OCSP обычным явлением является использование HTTP — я говорю о самом обычном HTTP-протоколе на 80-м порту, а не об HTTPS. Для этого есть веская причина — служба OCSP используется для веб-браузеров и использование HTTPS привело бы к бесконечной рекурсии проверок. Если вы используете HTTPS для проверки сертификата с помощью OCSP, вам также необходимо будет проверить сертификат самого HTTPS-соединения с помощью OCSP. Это означает открытие ещё одного HTTPS-соединения и так далее. Конечно, хотя OCSP не требует шифрования, он требует, чтобы ответы были подписаны сервером. Это по-прежнему не решает первоначальную обеспокоенность тем, что любой, у кого есть анализатор трафика в вашей сети, может подслушивать каждое открытое вами приложение и когда вы его открываете.
Ну и самая главная и непонятная во всём этом история, на которой первоначальная статья фокусируется меньше всего — это ContentFilterExclusionList (/System/Library/Frameworks/NetworkExtension.framework/Versions/A/Resources/Info.plist), некий список приложений и системных сервисов в macOS, которые Apple решила роутить в системе самостоятельно. То есть если даже вы пользуетесь VPN, macOS решает, что уж эти приложения могут идти в интернет мимо VPN. Что вообще подрывает концепцию восприятия безопасности пользователем на корню, так как он, сидя на открытом вайфае, думает, что все его данные проходят через зашифрованный тоннель, а на самом деле хyй там. Более того, как было продемонстрировано экспертами, эта реализация чревата тем, что вредоносное ПО тоже может воспользоваться такими правилами обхода:
Что в итоге.
Apple выпустила новую статью с разъяснениями, в которой подтвердила, что проверки сертификатов никак не привязаны к Apple ID пользователя.
https://support.apple.com/en-us/HT202491
Кроме этого, компания пообещала в следующем году выпустить обновление, где проверки будут идти по зашифрованному каналу связи. Будет добавлена поддержка на случай проблем с сервером, и появится опция отключения такой функциональности.
Пиздец с ContentFilterExclusionList Apple скорее всего даже не станет исправлять и отделается ещё одной статьёй.
Последнее редактирование:
