2020年11月12日午後3時25分（東部標準時）頃、macOS 10.15.7 Catalinaを搭載した私の27インチiMacがおかしな動きをし始めました。普段は電光石火の速さで動作する操作を実行しようとすると、あの恐ろしい「死の回転ピザ」のような待機カーソルが表示されるようになったのです。仕方なく再起動することにしました。興味深いことに、Josh Centersもちょうど自分のiMacを再起動すると私に話していました。TidBITS Slackで彼が言っていたように、「Mojaveが少し不安定になった」からです。
再起動しても何も改善されず、むしろ事態は悪化しました。MacでApple以外のアプリが一切起動できなくなったのです。メールとSafariは問題なく起動しましたが、他のアプリは起動しませんでした。Dockにあるアプリアイコンをクリックしても、Macから「ディン」という不快な音が鳴るだけで、何も変わりませんでした。
私たち二人が抱えるMacの悩みについてまだ話し合っていなかったのですが、ジョシュはiMacのSSDに何か問題があると確信し、リカバリモードで起動して診断を始めました。その後、MacBook Proに切り替えてみると、やはりアプリが起動しないことに気付きました。
ジョシュの次の Slack メッセージ (iPhone から) は次のとおりです。
すごく変な状況です。どちらのMacでもSlackもFirefoxも起動できません。同じような症状の方は他にいらっしゃいますか？
私は（iPhoneから）こう返信しました。
iMacの調子が少しおかしかったので再起動したら、ログイン項目が全く起動しなくなりました。App Storeアプリは起動でき、アップデートもいくつかダウンロード中です。プレビューは起動しますが、FirefoxもSlackも起動しません。
ジョシュはTwitterをチェックし、StopTheMadness（Webブラウザのエクスペリエンスを向上させる）、Link Unshortener（短縮リンクのリンク先を表示する）、Underpass（エンドツーエンド暗号化によるピアツーピアのファイル転送とチャット）を開発するジェフ・ジョンソンの投稿を見つけました。ジョンソンのツイートは瞬く間に拡散し、何が起こっているのかを説明していました。macOSのtrustdプロセスがocsp.apple.comというサーバーへの接続を試みましたが、失敗していました。
Apple以外のアプリは実際には起動していましたが、ocsp.apple.comへの接続試行がタイムアウトした後にのみ起動していました。アプリの起動にはocsp.apple.comへの接続は必須ではないため、完全にオフラインでもアプリを起動できます。ジョンソン氏は、Little Snitchなどのファイアウォールを使用してocsp.apple.comをブロックするか、アプリを起動したいときはインターネットから切断することを提案しました。
その後すぐに、他の人々がより直接的な解決策を提案しました/etc/hosts。それは、DNS をオーバーライドする形でホスト名を IP アドレスにマッピングする行をファイルに追加するというものです。 で ocsp.apple.com を 127.0.0.1 または 0.0.0.0 に指定すると/etc/hosts、ocsp.apple.com への接続は即座に失敗し、Mac は通常の動作状態に戻りました。ここでその手順を説明しないのは、もはや必要ではないからです。また、一般に、/etc/hostsその仕組みを既に理解していない限り、いじるべきではありません。もしこの方法で編集してしまった場合は/etc/hosts、その行を削除してください。Brian Matthews が TidBITS Talk で、そのためのコマンドラインレシピを提供していました。
約1時間後、Appleは問題を修正し、すべて正常に戻りました。
どうしてこんなことが起きたのでしょうか?
では、一体何が起こっていたのでしょうか？私の理解では、アプリの起動時に、AppleのGateKeeperテクノロジーが、開発者にコード署名用に割り当てる証明書をチェックします。問題のAppleサーバーの名前（ocsp.apple.com）は、AppleがOCSP（オンライン証明書ステータスプロトコル）を使ってアプリの証明書が失効していないか確認していることを示しています。失効している場合、macOSはアプリの起動をブロックします。これは、悪意のあるアプリが発見されたことで被害が拡大するのを防ぐためのAppleの方法です。（HPが意図せず証明書を失効させたことで、自業自得の問題に見舞われたことを覚えている方もいるかもしれません。2020年10月26日の記事「コード署名の失敗でHPプリンターが多数故障」をご覧ください。）
ocsp.apple.com が応答しなかったのはなぜでしょうか？Apple が詳細を明らかにするとは思えませんし、既に責任者が辞任している可能性もありますが、私の理解では、macOS 11 Big Sur のリリースに伴う膨大な負荷が、Apple がこのような状況に対処するために使用している CDN（コンテンツ配信ネットワーク）に障害をもたらしたと考えられます（今回の CDN は Akamai Technologies が運営しているようですが、これは珍しいことではありません）。Big Sur のメモリは 12GB で、Catalina の 8GB と比べて大幅に増加していることを考えると、負荷がはるかに高くなるのも当然と言えるでしょう。さらに、Apple は昨年、Mac を数百万台も販売しました。
この説を裏付けるのは、その日Appleの他のサービスもダウンしていたという事実です。Appleのシステムステータスページには、Apple Card、Apple Pay、iMessage、macOSソフトウェアアップデート（Big Surのダウンロード）、そしてマップに問題があったことが示されていました。
Appleは膨大な時間の無駄を引き起こした
この問題がMac界に与えた影響は計り知れません。ジョシュと私はiMacを比較的早く正常に動作させることができましたが、午後の残りの時間は、何が起こっているのかを解明することに費やされました。MacAdmins Slackでは、IT管理者やコンサルタントたちも同じように、自分のMacの問題だけでなく、ユーザーやクライアントからの電話、メール、トラブルチケットが殺到していたため、同様の対応をしていました。開発者たちはバグ報告を受け、修正を求める声が上がり、この問題は、当時開催されていた多くのオンラインプレゼンテーション、会議、カンファレンスに支障をきたしました。この問題に関するHacker Newsのスレッドには1150件を超えるコメントが寄せられ、その中には、ジョシュのようにMacのハードウェア故障を心配し、トラブルシューティングに多大な時間を費やしたMacユーザーからのコメントも含まれていました。
Appleが世界中のMacを全てオフラインにしたわけではないかもしれないが、このネットワーク障害は、おそらく何百万人ものMacユーザーの時間を数時間も無駄にした。（その間にアプリを起動しようとしていなかった人は、おそらく気づかなかっただろう。）この時間を取り戻すことはできないが、謝罪と謝罪は歓迎されるだろう。
この大失敗は、macOSの弱点とも言える点にも光を当てました。AppleがtrustdをMacがオフラインの時に静かに、そして自然に停止するように設計したのは明らかですが、ネットワーク障害発生時のタイムアウトがなぜこれほど長いのでしょうか？macOSには、日常的な使用において同様のチェックを行い、エラー発生時にユーザーエクスペリエンスを損なう可能性のある他のコンポーネントがあるのでしょうか？
いつものように、セキュリティの問題も浮上しています。ocsp.apple.com がmacOSの正常な動作における弱点となっていることが判明しました。これは誰かの机の下にある、過負荷状態の単一のサーバーではないことは明らかです。Akamai CDN を使用する最大の目的は、膨大なトラフィックを処理できるようにすることです。しかし、悪意のある攻撃者が ocsp.apple.com に対してサービス拒否攻撃を仕掛ける方法を模索しているのではないかと推測します。
非Apple製アプリを起動するたびにocsp.apple.comをチェックすることで、ネットワークにアクセスできる人物にあなたの情報が漏れてしまう可能性があるため、プライバシーへの影響も懸念されます。これは少し大げさに思えます。ネットワークにアクセスできる人物は、OCSPトラフィック以外にも多くの情報を扱うことができます。AppleのOCSPトラフィックは、こうしたプライバシー上の懸念に対処するOCSP Staplingを採用していないようです。
ocsp.apple.com を完全にブロックするために、Pi-hole のようなものの使用を提案する人もいます。(Big Sur より前のバージョンの macOS では Little Snitch を使用してこれを行うことができましたが、セキュリティ研究者の Patrick Wardle が指摘したように、trustd は Little Snitch ではブロックできなくなったトラフィックの Apple アプリの 1 つです。「Apple は Big Sur で自社アプリの一部のトラフィックを非表示にする」、2020 年 10 月 22 日の記事を参照してください。) ocsp.apple.com をブロックするのは、Apple が発見して開発者証明書を取り消すことで対処したマルウェアに対して脆弱になるため、悪い考えのように思えます。Apple は、特定の操作のために特定の時間に最新の Mac が接続できる必要がある多数のホストを運営しています。
結局のところ、Macへの信頼が少し薄れてしまったのは否めません。正直なところ、これはAppleのネットワーク運用担当者による稀なミスであり、二度とこのような事態に見舞われる可能性は極めて低いと考えています。また、AppleがmacOS内で同様の事態の発生を防ぎ、今回の件で生じた懸念に対処するための対策を講じてくれることを期待しています。
実際、私がこの記事を最初に公開してから、Apple は「Mac でアプリを安全に開く」サポートページを次のテキストで更新しました。
プライバシー保護
macOS は、ユーザーのプライバシーを尊重しながら、ユーザーとそのデータを安全に保つように設計されています。
Gatekeeperは、アプリに既知のマルウェアが含まれていないか、また開発者の署名証明書が失効していないかを確認するためにオンラインチェックを実行します。これらのチェックから得られたデータを、Appleユーザーやそのデバイスに関する情報と組み合わせることは一切ありません。また、これらのチェックから得られたデータを使用して、個々のユーザーがデバイス上で何を起動または実行しているかを把握することもありません。
公証では、サーバー障害に耐性のある暗号化された接続を使用して、アプリに既知のマルウェアが含まれているかどうかを確認します。
これらのセキュリティチェックでは、ユーザーのApple IDやデバイスのIDは含まれません。プライバシー保護を強化するため、Developer ID証明書のチェックに関連するIPアドレスのログ記録を停止し、収集したIPアドレスはログから削除します。
さらに、今後 1 年間でセキュリティ チェックにいくつかの変更を導入する予定です。
- 開発者ID証明書失効チェック用の新しい暗号化プロトコル
- サーバー障害に対する強力な保護
- ユーザーがこれらのセキュリティ保護をオプトアウトするための新しい設定
これらの変更はすべて前向きなものであり、Appleがこのような事態になる前に積極的に導入しなかったのは残念ですが、これはセキュリティがいかに難しいかを示すものだと私は考えています。Apple側に陰謀があるわけではないことは確かです。Appleが損害を被るのは、その行動がプライバシー重視の姿勢を損なう場合のみです。
いずれにせよ、AppleのミスがMac全般をほぼ使い物にならなくしてしまうという事実は、現代社会がAppleのような企業といかに密接に結びついているかを如実に物語っています。そんな事態が起こるとは限らないし、現実的な代替案があるわけでもありませんが、もしAppleが消滅したら、私たちのデバイスはほぼ確実に、本来の能力を最大限に発揮し続けることはできなくなるでしょう。