web-dev-qa-db-ja.com

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

NSA啓示とすべてに付随するすべての偏執狂で、私はなぜdebianパッケージインストールメカニズムがデフォルトでそれを使用することはもちろんのこと、そのトランスポートのためにHTTPSをサポートしないのかと思っています。

DebianパッケージにはGPGを使用したある種の署名検証があることは知っていますが、これがセキュリティの面でどれほど重要であるかを考えると、HTTPの代わりにHTTPSトランスポートを使用することは難しいとは思いません。

編集：私は、Debianミラー管理者ではなく、MitM攻撃（トラフィックスニッフィングのみを含む）から身を守りたいと思っています。 HTTPリポジトリは、debianミラーへのトラフィックを誰かが盗聴した場合、システム全体のセットアップをテーブルに置きます。

debiansecurityapthttps
47
zaadeh

有る。パッケージをインストールする必要があります apt-transport-https 。次に、次のような行を使用できます

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

あなたのsources.listファイル。ただし、コンテンツ全体がとにかく公開され、暗号化のオーバーヘッドとレイテンシが追加されるため、通常は必要ありません。攻撃者の公開鍵を信頼しないので、httpトラフィックでさえMitM攻撃から安全です。 aptは、攻撃者が操作されたパッケージを挿入したときに警告を出し、パッケージのインストールに失敗します。

編集：コメントで述べたように、 [〜＃〜] tls [〜＃〜] リポジトリを使用する方が確かに安全です。 調査結果 HTTPトランスポートはリプレイ攻撃に対して脆弱であるため、暗号化されていないリポジトリでaptを使用すると、実際にセキュリティリスクが発生する可能性があります。

50
Marco

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

Debianは利点がほとんどないため、HTTPSのダウンロードを容易にしません。 Debianパッケージ配布には、パッケージを検証するメカニズムがすでに含まれています。すべてのパッケージは Gpg で署名されています。アクティブな中間者がトラフィックを破損したパッケージのあるサーバーにリダイレクトした場合、GPG署名が無効になるため、破損が検出されます。 HTTPSではなくGPGを使用すると、より多くの脅威から保護できるという利点があります。エンドユーザー接続でのアクティブな中間者攻撃だけでなく、悪意のあるまたは感染したミラーまたはパッケージ配布チェーン内のその他の問題からも保護されます。

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

HTTPSが役立つのは、既知の有効なインストールイメージを取得するために信頼をブートストラップする場合です。 Debianはそれを提供していないようです： インストールメディア のチェックサムがありますが、HTTP経由のみです。

17
Gilles 'SO- stop being evil'

最近、会社の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'

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

9
at0S

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

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

...これはInRelease署名を回避しますが、とにかくHTTPSを設定することはおそらく良い考えです。

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

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

8
Royce Williams

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

たとえば、ローカルオブザーバーは、HTTPSを使用してソフトウェアを更新またはインストールしていることをまだ認識しており、どれを実行しているのか（さらには、サイズに基づいてどのパッケージを実行しているのか）について適切な推測を行うことができます。

DebianはAPT Tor "Onion services"を介してリポジトリを提供しているため、ドメイン名システムを信頼する必要なくエンドツーエンドの暗号化（TLSと同様）を取得できます。詳細は onion .debian.org この方法で利用できるすべてのDebianサービス用。メインのDebian FTPリポジトリはvwakviie2ienjx6t.onionにあります

4
meejah