Ocsp apple com это что

Не могу открыть приложения на macOS. Почему подпись кода OCSP оказалась миной замедленного действия

Две недели назад пользователи macOS начали сообщать о странных зависаниях при открытии приложений, не загруженных из Mac App Store. Многие подозревали аппаратные проблемы со своими устройствами, но из социальных сетей они узнали, что это широко распространённая проблема. И не случайно она возникла вскоре после запуска macOS Big Sur.

В конце концов, твит Джеффа Джонсона точно указал основную причину. Оказалось, что эппловская служба “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 по ошибке отозвала его сертификат, риск работы на изолированной платформе заключается в том, что вас самого могут изолировать от неё.

Источник

Ваш компьютер на самом деле не ваш

Перевел статью целиком (дополняя ее по мере расширения оригинальной статьи) только из-за того, что текущий перевод вообще не соответствует уровню статей Хабра.

Мой вариант перевода одобрен Джеффри Полом.

Добавлен перевод обновления от 16 ноября.

Вот он. Наступил. Получите и распишитесь.

Речь, конечно, идет о мире, предсказанном Ричардом Столлманом в 1997 году. О мире, о котором нас предупреждал Кори Доктороу.

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

Оказывается, текущая версия macOS отправляет в Apple хэш (уникальный идентификатор) при запуске каждой программы. Многие люди не были в курсе этого, так как хэш передается незаметно и только при наличии выхода в интернет. А сегодня серверы работали очень медленно и не успевали проверять хэши. Как результат, все приложения не открывались, если имелся выход в интернет.

Поскольку хэши передавались через интернет, серверы, конечно же, видят ваш IP-адрес и знают, в какое время пришел запрос. А IP-адрес в свою очередь позволяет установить ваш город, интернет-провайдера, а также составить таблицу со следующими заголовками

Дата, Время, ПК, Провайдер, Город, Штат, Хэш приложения

Apple (или кто-то еще), безусловно, может вычислить эти хэши для обычных программ: для всех программ из App Store, Creative Cloud, браузера Tor, инструментов для взлома или, например, реверс-инжиниринга – да для чего угодно!

Это означает, что Apple знает, когда вы дома, а когда на работе. Какие приложения вы открываете и как часто. Они знают, когда вы открыли Premiere в гостях у друга, используя его сеть Wi-Fi, или когда вы сидите в браузере Tor в отеле во время поездки в другой город.

Я часто слышу: «Кого это волнует?».

Что ж, волнует не только Apple. Эта информация не задерживается у них:

Эти OCSP-запросы передаются в незашифрованном виде. Их могут перехватывать все, кто в сети, включая вашего интернет-провайдера, а также, кто прослушивает интернет-трафик.

Эти запросы проходят через стороннюю CDN, управляемой другой компанией, Akamai.

С октября 2012 года Apple является партнером Разведывательного сообщества США в рамках государственной программы по шпионажу PRISM, которая предоставляет федеральной полиции и вооруженным силам США беспрепятственный доступ к данным без ордера. В первой половине 2019 года они воспользовались этим правом более 18 000 раз, а во второй половине 2019 года – еще более 17 500.

Эти данные представляют собой огромный массив данных о вашей жизни и привычках, позволяя кому-то, кто владеет ими, идентифицировать вас по вашим передвижениям и модели активности. Для некоторых людей это может даже представлять физическую опасность.

До сегодняшнего дня была возможность заблокировать подобное поведение на вашем Mac с помощью программы Little Snitch (на самом деле это единственное, что заставляет меня использовать macOS на данный момент). По умолчанию программа разрешает передачу между компьютером и серверами Apple, но вы можете вручную разрешать или блокировать то или иное соединение. А ваш компьютер продолжит работать нормально, «не стуча» на вас в Apple.

macOS 11.0 Big Sur получила новые API, которые ломают работу Little Snitch. Они не позволяют программе проверять или блокировать какие-либо процессы на уровне ОС. Кроме того, новые правила в macOS 11 затрудняют работу даже VPN, так что приложения Apple просто обходят их.

Патрик Уордл (Patrick Wardle) сообщил нам, что демон trustd , отвечающий за эти запросы, находится в новом списке исключений ContentFilterExclusionList , что означает, что он не может быть заблокирован никаким пользовательским брандмауэром или VPN. На его скриншоте также показано, что CommCenter (используется для совершения телефонных звонков с вашего Mac) и Карты также будут игнорировать ваши брандмауэр и VPN, ставя потенциально под угрозу ваш голосовой трафик и информацию о будущем или планируемом местоположении.

Помните только что анонсированные красивые Mac на новом процессоре Apple? В три раза быстрее и на 50 % больше времени автономной работы. Они не будут поддерживать ни одну ОС, кроме Big Sur!

Это первые компьютеры общего назначения, когда вам придется сделать выбор: или у вас быстрый и мощный компьютер, или личный. Мобильные устройства Apple работают таким образом уже как пару лет. За исключением использования устройств для фильтрация внешнего сетевого трафика (например, VPN-маршрутизатора), которые контролируете именно вы, на Mac с новым процессором не будет больше возможности загрузиться с какой-либо ОС, чтобы она не «звонила» в Apple. Иначе ОС может вообще не загрузиться из-за аппаратной криптозащиты.

Обновление. 13.11.2020 07:20 UTC

Мне стало известно, что у Mac на процессорах Apple с помощью утилиты bputil можно отключить защиту при загрузке и изменить Signed System Volume (SSV). Один я уже заказал и, как только со всем разберусь, напишу у себя об этом в блоге. Насколько я понимаю, даже после внесения таких изменений по-прежнему можно будет загружать только версии macOS, подписанные Apple. Хотя, возможно, и с некоторыми удаленными или отключенными нежелательными системными процессами. Дополнительные данные появятся, когда система будет у меня в руках.

Теперь ваш компьютер служит удаленному хозяину, который решил, что имеет право шпионить за вами. Даже имея самый производительный ноутбук с самым высоким разрешением в мире, вы не можете этому помешать.

Лягушка в кипятке

На этой неделе настал день, о котором нас предупреждали Столлман и Доктороу. Это был постепенный и последовательный процесс, но вот мы наконец-то и приплыли. Вы больше не будете получать оповещений о передаче данных на серверы Apple.

Смотрите также

21 января 2020 г. Apple отказалась от плана по шифрованию резервных копий после жалобы ФБР.

Возможно, не в тему

К другим новостям: Apple незаметно отказалась от сквозной криптографии в iMessage. В настоящее время актуальная iOS будет запрашивать ваш Apple ID во время установки и автоматически включать iCloud и iCloud Backup.

В iCloud Backup не используется сквозное шифрование: резервная копия вашего устройства шифруется с помощью ключей Apple. Каждое устройство с включенным резервным копированием iCloud (а оно включено по умолчанию) загружает резервную копию всей истории iMessage на серверы Apple вместе с секретными ключами iMessage каждую ночь при подключении к сети. Apple может расшифровать и прочитать все данные, даже не притрагиваясь к устройству. Даже если вы отключили резервное копирование в iCloud, вполне вероятно, что тот, с кем вы переписываетесь с помощью iMessage, этого не сделал. Как следствие, ваша переписка загружается на серверы Apple. Еще и через PRISM со свободным доступом для Разведывательного сообщества США, ФБР и др. без ордера или веской на то причины.

Обновления

Обновление, 16.11.2020 16:06 UTC

«Где факты? Снова, снова и снова — а где факты? Не выдавайте желаемое за действительное, игнорируйте божественное откровение, забудьте о том, что «предсказывают звезды», избегайте мнений, не обращайте внимания на то, что думают соседи, не говоря уже о непостижимом «приговоре истории» — каковы же доказательства и с какой точностью после запятой? Вы всегда летите в неизвестное будущее; факты — ваша единственная подсказка. Факты — вот ваша единственная подсказка».

Тот парень Якопо (Jacopo), который якобы опроверг мое основное утверждение, на самом деле лжет. Об этом свидетельствует его собственная страничка. Сами поглядите:

Он также утверждает, что «macOS действительно отправляет некоторую неясную информацию о сертификате разработчика этих приложений». На самом деле она вовсе и не неясная: это общеизвестный уникальный идентификатор разработчика приложения (который почти для всех приложений является общедоступным, поскольку большинство разработчиков публикуют только одно приложение).

Это наглядно иллюстрирует опасность доверять любому эксперту, у которого за кликбейтными заголовками Беттериджа скрывается технический бред. Убедитесь, что вы всегда все перепроверяете, и всегда, всегда, задавайтесь вопросом: «Каковы факты?«.

То, что отправлено, действительно является хешем, действительно является уникальны идентификатором для большинства приложений и действительно отправляется в Apple в реальном времени в незашифрованном виде с вашим IP-адресом. Я упростил приведенное выше объяснение, чтобы не вдаваться в подробности о OCSP, x509 и PKI. Я умышленно не утверждал, что это был хэш содержимого двоичного файла приложения.

TL;DR: Этот пост был, есть и будет максимально достоверным. А кликбейты пусть и дальше остаются кликбейтами.

Хорошая новость заключается в том, что Apple (предположительно в ответ на эту страницу) только сегодня публично обязалась:

1. Удалять логи IP-адресов;

2. Шифровать обмен данными между macOS и Apple, чтобы предотвратить утечку конфиденциальности;

3. Предоставить пользователям возможность отключить онлайн-проверки, которые позволяют узнать, какие приложения вы открываете и когда.

Это обновление находится в самом низу этой страницы, под заголовком с заглавной буквы «Защита конфиденциальности».

Цитата из обновления Apple от 16 ноября:

Gatekeeper выполняет онлайн-проверки, содержит ли приложение известное вредоносное ПО и не отозван ли сертификат подписи разработчика. Мы никогда не связывали данные этих проверок с информацией о пользователях Apple или их устройствах. Мы не используем данные этих проверок, чтобы узнать, что отдельные пользователи запускают или что уже запущено на их устройствах.

Нотаризация проверяет, содержит ли приложение известное вредоносное ПО, используя зашифрованное соединение, устойчивое к сбоям сервера.

Здесь намеренно используется стиль, сбивающий с толку, чтобы заставить вас отожествлять Gatekeeper с Нотаризацией, чтобы вы поверили, что соединения в настоящее время зашифрованы, при этом даже не солгав. OCSP-проверки у Gatekeeper, описанные в этом посте («Gatekeeper выполняет онлайн-проверки»), не зашифрованы. А Нотаризации, которые здесь не уместны, шифруются.

Политтехнологи Apple — одни из лучших в мире, и я снимаю перед ними шляпу.

Кроме того, в следующем году мы внесем несколько изменений в наши проверки безопасности:

Новый зашифрованный протокол для проверки отзыва сертификата Developer ID.

Все те шибко умные, неразбирающиеся в циклических зависимостях доверия TLS и в том, как OCSP должен быть не зашифрован, могут прямо сейчас умолкнуть.

Отстой же в том, что они позволяли АНБ, ЦРУ, вашему интернет-провайдеру и др. вытаскивать эти незашифрованные данные об образе жизни в течение последних 2 и более лет. И они по-прежнему по умолчанию собираются передавать данные (в зашифрованном виде) в Apple в реальном времени на каждом Mac. Но по крайней мере 0,01 % пользователей Mac, кто в теме, могут все это отключить, поэтому Apple будет получать в реальном времени данные только о том, какие приложения вы открываете, когда и где для остальных 99,99 % пользователей Mac. Круто же!

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

К сожалению, речь идет о том, как мы максимально близко подобрались к заявлению PR-отдела Apple «мы в дерьме»: удаляют логи с IP-адресами, шифруют свою хрень и позволяют ее еще и выключить. Здорово, конечно, вот только они умалчивают, что их приложения на Big Sur по-прежнему будут обходить ваш брандмауэр и сливать ваши IP-адрес и местоположение через VPN и что они все еще не исправляют бэкдор условного депонирования ключей в шифровании iMessage, поэтому системные администраторы Apple и ФБР могут и дальше любоваться вашими интимными фотографии и читать переписку в iMessage.

Думаю, нам нужно радоваться маленьким победам.

dhh выразился лучше всего:

Весь процесс Apple по слиянию всех этих «средств защиты от вредоносных программ» в систему, которая одновременно является «защитой нашей бизнес-модели», чреват серьезными последствиями.

Нам нужно сохранять бдительность и противостоять этим захватам власти, маскирующимся исключительно под очередные меры безопасности. Да, имеются преимущества безопасности. Но нет, мы не дадим Apple решать, какое программное обеспечение запускать на наших компьютерах. Мы итак лишены этого на iOS.

В любом случае, имеются предпосылки успеха. Прямо сейчас Apple по-прежнему привязывает ваш IP-адрес к открытию приложений, передавая в незашифрованном виде через интернет. И в Big Sur препятствуют таким утилитам как Little Snitch блокировать такие передачи. Так что, пока исправления не появятся, может, и не обновляться?

Эти изменения в журналировании действий и обещание будущих улучшений помножили на ноль всех апологетов Apple, которые так поспешили отвергнуть эти разоблачения как пустяковые. Ой, спускать лодку за день до того, как Apple сама потопит ее своим признанием.

Три «Ура!» за голос разума. Спасибо, dhh!

Обновление, 14.11.2020 05:10 UTC: Добавлен FAQ.

В.: Это часть собираемой аналитической информации macOS? Будут ли собираться данные, если у меня отключена отправка аналитической информации?

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

В.: Когда это началось?

О.: Это происходит по крайней мере с момента выхода macOS Catalina (10.15.x, выпущена 7 октября 2019 г.). То есть это началось не со вчерашнего выпуска Big Sur, а происходило незаметно как минимум год. По словам Джеффа Джонсона (Jeff Johnson) из Lap Cat Software, все началось с macOS Mojave, выпущенной 24 сентября 2018 года.

Каждую новую версию macOS я устанавливаю начисто, выключаю сбор аналитической информации, не вхожу ни в какие сервисы (как iCloud, App Store, FaceTime или iMessage) и включаю внешнее устройство для мониторинга всего исходящего сетевого трафика. У последних версий macOS наблюдался довольно активный сетевой трафик, даже если вы не используете никакие сервисы Apple. В Mojave (10.14.x) были некоторые проблемы с конфиденциальностью и отслеживанием, но я не помню, существовала ли тогда конкретная проблема с OCSP или нет. Я еще не тестировал Big Sur (следите за обновлениями), но, согласно отчетам тех, кто тестировал, возникают опасения по поводу пользовательских брандмауэров вроде Little Snitch, приложений Apple, которые обходят эти брандмауэры, и VPN-соединений. Догадываюсь, что у меня будет большой список вопросов, когда я установлю Big Sur на тестовую машину на этой неделе.

В.: Как мне защитить свою конфиденциальность?

О.: По-разному. Ваш Mac отправляет тонну трафика на серверы Apple. Если вы беспокоитесь о своей конфиденциальности, можете начать с отключения функций, у которых имеются кнопки: отключите и выйдите из iCloud, отключите и выйдите из iMessage, отключите и выйдите из FaceTime. Убедитесь, что службы геолокации отключены на ваших компьютере, iPhone и iPad. То были значительные слабые места, по которым вас могли отследить и на которые вы уже согласились, но есть простой выход: выключите все.

Что до проблемы с OCSP, я считаю (но еще не тестировал!), что сработает эта команда

echo 127.0.0.1 ocsp.apple.com | sudo tee -a /etc/hosts

Такой трафик я блокирую программой Little Snitch, которая еще работает на версии 10.15.x (Catalina) и ниже. Отключите в Little Snitch все разрешающие правила для служб macOS и службы iCloud, чтобы получать предупреждения, когда ОС пытается связаться с Apple.

Если у вас Mac на Intel (а такой почти у всех сейчас), не беспокойтесь о грядущих изменениях. Если вы хотите изменить пару настроек в ОС, то скорее всего всегда настраивали все предыдущие macOS под себя. Это особенно актуально для немного более старых Mac на Intel, в которых нет чипа безопасности T2. Но вполне вероятно, что даже на таких компьютерах можно будет отключать безопасную загрузку (тем самым позволяя настраивать ОС), как это можно делать сейчас.

Новые Mac на ARM64 («Apple Silicon»), которые были выпущены на этой неделе, стали причиной моего беспокойства: еще неизвестно, дадут ли пользователям возможность вообще модифицировать ОС на этих чипах. На других ARM-системах от Apple (iPad, iPhone, Apple TV, Watch) криптографически запрещено отключать такой функционал ОС. Для новых Mac на ARM по умолчанию скорее всего тоже будет запрещено, хотя, надеюсь, продвинутые пользователи смогут отключить некоторые средства защиты и настраивать систему. Я надеюсь, что утилита bputil(1) даст возможность отключить проверку целостности системного тома на новых Mac, что позволит нам удалить определенные системные службы из автозагрузки, не отключая все функции безопасности платформы. Больше информации узнаем в ближайшее время, когда ко мне приедет новый Mac на M1 в этом месяце.

В.: Если тебе не нравится Apple и ты не доверяешь их ОС, то почему ей пользуешься? Почему сказал, что покупаешь новый Mac на ARM?

О.: Простой ответ заключается в том, что без оборудования и программного обеспечения я не могу с уверенностью говорить о том, что они делают или не делают, или о шагах, которые можно предпринять для нивелирования проблем с конфиденциальностью. Длинный ответ заключается в том, что у меня есть более 20 компьютеров с примерно 6 различными архитектурами процессоров. У меня в коллекции имеются все операционные системы, о которых вы слышали, и некоторые из тех, о которых вы, вероятно, и не знали. Например, в моей лаборатории есть 68k Mac (16-битный, почти 32-битный (привет, мой IIcx) и чисто 32-битный), Mac на PowerPC, 32-битный Mac на Intel, 64-битный Mac на Intel (с чипом безопасности T2 и без). Да я бы прослыл последним бездельником, если немного не поковырялся в Mac на ARM64.

В.: Зачем Apple шпионит за нами?

О.: Я не верю, что это было специально разработано как часть телеметрии, но это прекрасно подходит для этой цели. Простое (без злого умысла) объяснение состоит в том, что это часть кампании Apple по борьбе c вредоносным ПО и обеспечению безопасности платформы в macOS. Кроме того, OCSP-трафик, генерируемый macOS, не зашифрован, что делает его идеальным объектом для использования в военных операциях по наблюдению (которые пассивно контролируют всех основных интернет-провайдеров и сетевые магистрали) с целью сбора диагностических данных. И неважно, намеренно ли Apple закладывала такой функционал или нет.

Еще что интересно: недавно Apple с обновлением iOS представила iCloud Backup, добавив закладку в iMessage, чтобы ФБР могло продолжить чтение всех данных на вашем телефоне.

Как говорил Голдфингер: «Один раз – случай, два – совпадение, три – заговор врага«. Было всего пару раз, когда Apple (которая, кстати, нанимает крутейших специалистов по криптографии) признавала, что допускала передачу открытого текста или ключей шифрования в открытом виде с устройства в сеть/Apple, и извинилась: «Ой, это была случайность». И ей поверили.

Последний раз я сообщал Apple в 2005 году о проблеме, связанной с передачей открытого текста по сети. Тогда они быстро все исправили, но это касалось только поиска слов в словаре. Вскоре после того, как была представлена технология App Transport Security, которая помогает сторонним разработчикам приложений «не забивать» на сетевое шифрование, Apple усложнила отправку незашифрованных запросов в приложениях из App Store. Поэтому для меня непонятно, почему Apple до сих пор отправляет OCSP-запросы в незашифрованном виде, несмотря на то, что это стандартная практика в отрасли.

Если Apple действительно заботится о конфиденциальности пользователей, прежде, чем выпускать новую ОС, им следует тщательнее следить за передачей данных даже на ненастроенном Mac. Мы вот заботимся. Чем дольше они закрывают на это глаза, тем менее убедительными становятся их заявления о соблюдении конфиденциальности пользователей.

В.: Зачем ты поднимаешь ложную тревогу? Разве ты не знаешь, что OCSP предназначен только для предотвращения запуска вредоносных программ и обеспечения безопасности ОС, а не для сбора телеметрии?

О.: Побочный эффект в том, что он функционирует как телеметрия независимо от первоначального замысла. Кроме того, даже, несмотря на то, что OCSP-ответы подписаны, OCSP-запросы не зашифрованы, что позволяет любому пользователю сети (включая Разведывательное сообщество США) видеть, какие приложения вы запускаете и когда. А это можно считать крайней степенью халатности.

Многие вещи функционируют как телеметрия, даже если изначально это и не было задумано. Спецслужбы, которые шпионят за каждым, могут воспользоваться этим независимо от намерений разработчиков.

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

В.: Они поместили закладку в сквозное шифрование iMessage? Охренели вообще?!

О: Ага. Технический разбор в моих комментариях тут и тут.

Сообщения в iCloud также используют сквозное шифрование. Если у вас включено резервное копирование в iCloud, ваша резервная копия содержит копию ключа, защищающего ваши сообщения. Этот подход гарантирует, что вы сможете восстановить свои Сообщения, если потеряете доступ к связке ключей iCloud и своим доверенным устройствам. При отключении резервного копирования iCloud на вашем устройстве создается новый ключ для защиты будущих сообщений, который не хранится у Apple.

Обратите внимание, что само резервное копирование iCloud не имеет сквозного шифрования, что приводит к проблеме условного депонирования ключа iMessage, которая препятствует сквозному шифрованию последнего. На этой веб-странице есть раздел, в котором перечислены материалы, которые используют сквозное шифрование, и вот резервного копирования iCloud там нет.

Как и ваши фотографии в iCloud. Системные администраторы в Apple (а также военные и федералы США) могут спокойно видеть все ваши интимные фотографии в iCloud или iMessage.

Источник