debian aptツールのhttpsトランスポートがないのはなぜですか？

あります。パッケージ apt-transport-https をインストールする必要があります。次に、sources.listファイルで

 deb https://some.server.com/debian stable main 

のような行を使用できます。ただし、コンテンツ全体が公開されており、暗号化のオーバーヘッドと遅延が増えるため、通常は必要ありません。攻撃者の公開鍵を信頼しないため、httpトラフィックでさえMitM攻撃から安全です。 aptは、攻撃者が操作されたパッケージを挿入すると、警告を表示し、パッケージのインストールに失敗します。

編集：コメントに記載されているように、 TLS リポジトリ。 調査によると、暗号化されていないリポジトリでaptを使用すると、HTTPトランスポートがリプレイ攻撃に対して脆弱であるため、実際にセキュリティリスクが発生する可能性があります。

コメント

• いいえ、ほとんどのミラーはhttpsをサポートしていません。 ‘この種のトラフィックを暗号化することはあまり意味がないという理由だけで。パッケージはとにかく検証されており、情報は公開されています。
• TLS経由でダウンロードすることを好む理由がいくつか考えられます。1）パッケージをインストールするときにプライバシーを気にする可能性があります。2）そこでパッケージ署名チェックコードのバグである可能性があり、MITMが悪用する可能性があります。
• @JackO ‘コナー、プライバシーに関する最初の異議は理解できますが、2番目の異議は理解できます。 TLSコードにバグがある可能性があるため、WebサイトがPGPキーを使用してコンテンツに署名するのが好きだと言っているようなものです。 PGPとTLSの両方が信頼を確立します。 ‘そのために両方は必要ありません。
• @Marcoあなたの答えは正しくありません。多くの研究論文は、リポジトリがHTTP経由でアクセスされると、GPG署名があっても、APTリポジトリとYUMリポジトリの両方がリプレイ攻撃に対して脆弱であることを示しています。リポジトリには、100％の確率でTLS経由でのみアクセスする必要があります。
• ここに @JoeDamatoが言及している論文があります。回答ここ

あなたの仮定は間違っています：HTTPSダウンロードを使用できます。それをサポートするミラーを見つけて、そのURLをソースのリストに入れるだけです。 apt-transport-https パッケージをインストールする必要があります。

DebianはHTTPSを作成しませんメリットがほとんどないため、ダウンロードは簡単です。 Debianパッケージ配布には、パッケージを検証するメカニズムがすでに含まれています。すべてのパッケージは Gpg で署名されています。アクティブなman-in-the-middleがトラフィックを破損したパッケージのあるサーバーにリダイレクトすると、GPGシグネチャが無効になるため、破損が検出されます。HTTPSではなくGPGを使用すると、より多くの脅威から保護できるという利点があります。エンドユーザー接続のアクティブなman-in-the-middleに対してだけでなく、不正なミラーや感染したミラー、またはパッケージ配布チェーン内のその他の問題に対しても。

HTTPSはわずかなプライバシー上の利点を提供します。ダウンロードするパッケージが不明瞭になるという点で。ただし、パッシブオブザーバーは、コンピューターとパッケージサーバー間のトラフィックを検出できるため、Debianパッケージをダウンロードしていることがわかります。また、「ファイルサイズからダウンロードするパッケージを把握することもできます。

HTTPSが役立つのは、信頼をブートストラップして、既知の有効なインストールイメージを取得することです。Debianはそうしません。」 インストールメディアのチェックサムがありますが、HTTP経由のみです。

コメント

• インストールメディアにはHTTPSバージョンがあります： cdimage.debian.org/debian -cd
• メリットはほとんどありませんか？ justi.cz/security/2019/01/22/apt-rce.html はどうですか？
• @AaronFranke特定のバグの1つはHTTPSよりもHTTPの方が悪用しやすいというメリットはほとんどありません。 ‘ HTTPの攻撃対象領域がHTTPSよりも大きいわけではありません。実際、HTTPS自体は、より多くのコードを含むため、攻撃対象領域が大きくなります。したがって、’正味のメリットすらありません。’ 2つの限界リスク間のトレードオフです。

つい最近、会社のaptリポジトリで問題が発生しました。問題は、標準のhttpを使用する場合に発生することでした。トランスポート他の人は簡単にパッケージを入手できます。会社は独自のソフトウェアをパッケージ化しており、それをすべての人と共有したくないため、httpトランスポートが問題になります。悲劇ではなく問題です。パッケージへのアクセスを制限する方法はいくつかあります。 -ファイアウォール、Webサーバーレベルでのアクセスの制限、トランスポートとしてのsshの使用。このトピックに関する非常に簡単な説明は、プライベートDebianリポジトリへのアクセスの制限

この場合、httpsトランスポート+クライアント証明書認証を使用することにしました。簡単に言うと、必要なのは次のとおりです。

1. 自己署名証明書、クライアント、およびサーバー（easy-rsaを使用）;

2. httpsのみを受け入れるようにリポジトリの前面にあるWebサーバーを構成します。 nginxの場合、次のようになります。

   server { listen 443; root /path/to/public; server_name secure_repo; ssl on; ssl_certificate /etc/nginx/ssl/server.crt; ssl_certificate_key /etc/nginx/ssl/server.key; ssl_session_timeout 5m; ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:; ssl_prefer_server_ciphers on; ssl_client_certificate /etc/nginx/ssl/ca.crt; ssl_verify_client on; location / { autoindex on; } } 

3. クライアント証明書、クライアントキー、およびCA証明書を/ etc / apt /に配置しますsslを使用し、Ubuntuの場合は、00httpsファイルを/etc/apt/apt.conf.dに追加します。

   Debug::Acquire::https "true"; Acquire::https::example.com { Verify-Peer "true"; Verify-Host "false"; CaInfo "/etc/apt/ssl/ca.crt"; SslCert "/etc/apt/ssl/client.crt"; SslKey "/etc/apt/ssl/client.key"; };

自己署名証明書を使用している場合は、ホスト検証をオフにすることが重要であることに注意してください。Verify-Host "false";これを行わない場合は、 「エラーが発生します：SSL: certificate subject name (blah-blah-blah) does not match target host name "example.com"

これで、リポジトリへの不正アクセスはなくなりました。したがって、これは非常に便利で強力なものです。

コメント

• すばらしい回答をありがとうございます。しかし、主な問題はまだそこにあると思います。 HTTPSは、特にWebおよびDebianパッケージを介した転送のデフォルトプロトコルになるはずです。議論はHTTPSの理由ではなく、なぜそうではないのでしょうか？
• @aalizadeh、私はあなたに同意します。httpsを使用するとオーバーヘッドが発生しますが、大きなオーバーヘッドはありません。 httpsがデフォルトのトランスポートではない主な理由は、一部の組織が暗号化されたトラフィックを明示的に禁止しているためだと思います（従業員がインターネット上で行っていることに鼻を突っ込むことができるようにしたいため）。つまり、リポジトリはサポートする必要があります。 httpとhttpsの両方のトランスポート。他にも考慮事項があるかもしれません
• » Verify-Hostの使用” false “; «は、自己署名証明書を使用しても間違っています。代わりに、クライアントに（正しい）サーバー証明書を認識させる必要があります。
• 確かに、私のクライアントは内部システムのみでした。したがって、適切なpkiインフラストラクチャをすべて作成する代わりに、私は手抜きをしました。そして、はい、後でpkiは適切に解決され、Verify-Hostはfalseになりました。削除されました。はい、ポイントは有効です。
• ubuntu xenialを使用すると、aptパッケージは非特権ユーザー_aptとしてフェッチされます。このスレッドを更新して、ファイル権限の問題を管理または解決した方法の詳細を教えてください。

次のような脆弱性のために注意してください

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467

… InRelease署名を回避するため、とにかくHTTPSを構成することをお勧めします。

これは単一の例ではありません。デフォルトでHTTPに設定されている他の多くの更新システムにも署名検証の失敗の履歴があります。

セキュリティが重要な更新メカニズムではHTTPSとの両方を使用する必要があります / em>署名の検証が堅牢になります。それぞれが他方の障害を軽減します。

コメント

• そして今度もこれも： mirror.fail 別名 usn.ubuntu.com/3746-1 別名CVE-2018-0501。 InReleaseの署名は十分ではありません。 “ただし、すべてのミラーをHTTPSに移動するには、時間と調整が必要です！”。はい。今すぐ始めましょう。これが最後のInReleaseの失敗ではありません。
• ここに’別のエコシステム（アルパイン）からの別の例があります。そのパッケージ管理システムは’デフォルトではHTTPSを使用せず、パッケージの整合性を検証するために署名のみに依存しています…そして、その検証には2018年9月にリモートで悪用可能なバグがありました： justi.cz/security/2018/09/13/alpine-apk-rce.html アルパインが開始するはずです今をデフォルトでHTTPSの使用に移行します。
• （完全な開示：私自身の要点ですが、’は私が知っている唯一の参照ですの）、これは私が’認識しているクライアント側の署名検証の失敗のすべての失敗のリストです。リストのサイズは重要であり、定期的に増加します。歓迎を追加します。 gist.github.com/roycewilliams/cf7fce5777d47a8b22265515dba8d004

「匿名性」のユースケースには、apt-transport-torもあり、tor+http://のようなURIを入力できます。 sources.listファイル。これは、単にミラーへの接続を暗号化するよりもはるかに優れた匿名性保護です。

たとえば、ローカルのオブザーバーは、HTTPSを使用してもソフトウェアを更新またはインストールしていることを認識し、おそらくある程度の推測を行うことができます。

DebianはTor「オニオンサービス」を介してAPTリポジトリを提供しているので、エンドツーエンドの暗号化を取得できます（同様）ドメインネームシステムを信頼する必要なしにTLSに）。この方法で利用できるすべてのDebianサービスについては、 onion.debian.org を参照してください。メインのDebianFTPリポジトリはvwakviie2ienjx6t.onion