前の質問で述べたように：apt-getまたはaptにhttps接続のみを使用させるにはどうすればよいですか？
deb https://deb.debian.org/debian bookworm main
deb https://security.debian.org/debian-security bookworm/updates main
deb https://deb.debian.org/debian bookworm-updates main
security.debian.orghttpsプロトコルを使用すると機能しません。
Ubuntuを使用している間、httpsプロトコルを使用してapt-getキャッシュを更新する際に同様の問題が発生しました。
今、主なセキュリティ問題と見なされるオペレーティングシステムのアップデートをダウンロードするために純粋なhttpを使用しませんか？
2023年にも、通常のhttpがまだいくつかのテスト環境で使用するのに適していると考えられる理由を理解しようと頭を傷つけます。中間の重いメインラインとパケットの破壊を所定の位置に入れて作られたパケットが転送され、ユーザーのコンピュータにインストールすることはできないでしょうか？
ベストアンサー1
Debianとその派生製品は、セキュリティパッケージの配送にTLSに依存せず、代わりにシステムにすでに存在するキー（インストール中に設定またはシステム管理者によって追加されたもの）を使用するOpenPGPキー署名に依存しています。これにはメタデータとパッケージの内容が含まれます。Debianソフトウェアパッケージの信頼性をどのように保証しますか？もっと学ぶ。
TLSが提供する別の一般的に要求される機能は機密性です。つまりあなたのトラフィックを監視できる人はあなたが何をしているのかを判断できません。便利なリンクはありませんが、TLSだけではパッケージのダウンロードアクティビティを意味のあるものに隠すのに十分ではないことがわかりました。ほとんどの場合、転送サイズはダウンロードするパッケージを決定するのに十分です。
したがって、TLSはDebianがすでに提供している整合性を追加し、機密性を追加できますが、そうではありません。また、少しオーバーヘッドを追加し、データキャッシュをより複雑にします（これはデプロイパッケージストアに役立ちます）。したがって、Debian はデフォルトでこれを構成しません。
Debian リポジトリですべてのケースでサポートされていない TLS の 1 つの機能は、再生攻撃に対する抵抗です。 TLSを持たない中間者シナリオでは、クライアントは以前のバージョンのストレージメタデータと関連パッケージを提供する可能性があり、これはシステムを脆弱にするために使用できます。頻繁に更新される Debian リポジトリ (特にアップデートとセキュリティファミリ) は、1 週間だけ有効なメタデータを生成し、1 週間後の再生を防ぎますが、安定性ポイントリリースは署名キーが期限切れになるまで有効であるため、ターゲットシステムを人為的に以前のポイントに維持できます。バージョン。 （ただし、デフォルト設定ではこの場合、セキュリティ更新プログラムは引き続き表示されます。）
もちろん、より深い防御がより良く、過去にTLSが軽減する脆弱性があったため、ほとんどのリポジトリでTLSを有効にすることができます。
ベストプラクティスに関して：
- Debian（またはUbuntu）リポジトリの場合、
aptエラーに注意を払うだけでデフォルト設定で十分です（ただし、必要に応じてTLSのアクティブ化を防ぐことはできません）。 - サードパーティのリポジトリの場合は、可能であればTLSを使用する必要があります（包括的なルールでは、各リポジトリが正しく設定されていることを確認するよりも簡単です）。