私の最近のAppleセキュリティ更新プログラムをダウンロードするとどうなりますか？
問題のアップデートは、とりわけ最近のSSLの脆弱性/大きな穴を修正すると主張するマーベリックスの複合アップデートです。
この問題は本当に私を苛立たせたので、私はAppleのPGP鍵を入手し、それをできる限り検証することにしました。そして、ダウンロード中にWiresharkでトラフィックを調べました。これが私の発見です：
- AppleのPGPキーを取得して検証するのは時間の無駄でした。なぜなら、私が知る限り、ソフトウェアの更新に署名を発行しないからです。
- 更新ダウンローダーはHTTPS経由でソフトウェアダウンロードロケータードメインに接続し、CDN（私の場合はApple.vo.llnwd.net）上の実際の更新にリダイレクトします。
- 更新パッケージのすべての単一ビットがCDNからプレーンな古いHTTPに渡されます
- 更新のすべてのパケットの後に、重複するACKが続きます（これは更新でのみ発生します。他のすべてのダウンロードは問題ないので、私はしません私のインフラだと思う）
- ここ からdmgアーカイブを手動でダウンロードすると、デフォルトでHTTPになります。 HTTPSを適用すると、実際の（HTTP）ファイルURIにリダイレクトされます。このURIではHTTPSが有効になっていません。
Appleは（おそらく、往年の批判に対応している）、「複雑なプロキシ設定」によってこれが不可能になる場合を除いて、アップデートはHTTPS経由で配信されると具体的に述べている。私はバニラ接続と2つのオフショアVPNを介してダウンロードを試みましたが、お金もお金もかからずに、そのファイルへのHTTPSリンクを取得できます（ソフトウェアの更新またはWebサイト経由）。
私の質問は：
- あなたの意見では、彼ら-またはその間の誰か-面白いバガーをプレイしていますか？
- これらのすべての重複ACKから引き出される疑いはありますか？ （私はこれについて推測さえするのに十分なことを知りません）
私がNSA/GCHQで、予測可能なHTTPエンドポイントでバイナリのblobをインターセプトして置き換える警告が数週間あった場合、コードサインオンミリオン対象のマシンが完全に壊れているので、おそらくクリスマスが2回来たと思います。彼らがそれが可能であった場合、彼らがそのような機会を逃すことができる状況は見当たらず、私が読んだすべてから、彼らはそのようなことを可能にする以上のものです。
（以下はすべて推測であり、Appleのアップデーターが内部でどのように機能するかはわかりません。）
HTTP経由で安全な更新を実行できるアーキテクチャは間違いなくあります。ほとんどすべてのLinuxディストリビューションは、パッケージをプレーンテキストで配布し、リポジトリメタデータからのハッシュ（SHA-1、SHA-256など）を検証することでパッケージを検証します。リポジトリメタデータは、ホストが確認するGPGキーで署名され、元のインストールメディアでインストールされました。 （元のインストールメディアがバックドアされていた場合、すべてのベットが永久にオフになります。）
Apple update？Appleは同様のスキームを使用している可能性があります-HTTPS経由でハッシュを送信し、HTTP経由でダウンロードしてから、ハッシュを検証します。このようなソフトウェアの更新は、完全性が本当に必要な場合です（機密性を必要とする人もいますが、攻撃者がApple.comからHTTPS経由でXバイトをダウンロードし、最新のApple更新はXバイトであり、すでに機密性を失っています）、HTTPS経由でファイル自体を送信せずに整合性を実現できます。
実際、この手法は多分望ましい-Apple少数のサーバーが直接制御下で更新メタデータ（つまり、URLと更新のハッシュ）を提供し、サードパーティのCDNを使用する可能性がある）更新を配布し、帯域幅のコスト、レイテンシなどを削減します。更新が検証ステップなしでHTTPS経由でCDNによって直接提供された場合（つまり、すべての整合性はHTTPSからのものです）、CDN（またはCDNを侵害する誰か）は更新を変更されたバージョンに置き換えます。
重複するACKが気になるかどうかは、主に別の問題です。私の懸念のレベルは多くの事柄に依存します。それらはアウトバウンドまたはインバウンドACKですか？ TTLとは何ですか？シーケンス番号は何ですか？言うのは本当に難しいですが、ACKの重複は、ネットワークの設定ミスどこか（ネットワークでなくても）が攻撃者によるものよりもはるかに可能性が高いと思います。