为什么 debian apt 工具没有 https 传输？

Question

随着 NSA 披露的所有偏执狂，我想知道为什么 Debian 软件包安装机制不支持 HTTPS 进行传输，更不用说默认使用 HTTPS 了。

我知道 Debian 软件包使用 GPG 进行某种签名验证，但是，考虑到这在安全方面的重要性，我仍然认为使用 HTTPS 传输而不是 HTTP 会太难。

编辑：我主要想保护自己免受中间人攻击（包括只是流量嗅探），而不是 Debian 镜像管理员。HTTP 存储库将整个系统放在桌面上，供任何窥探 Debian 镜像流量的人使用。

Answer 1

有。您需要安装该软件包apt-transport-https。然后你可以使用像

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

在您的sources.list文件中。但通常这不是必需的，因为无论如何整个内容都是公开的，并且会增加加密开销和延迟。由于您不信任攻击者的公钥，因此即使是 http 流量也不会受到中间人攻击。apt当攻击者注入受操纵的软件包时，将警告您并且无法安装软件包。

编辑：如评论中所述，使用TLS存储库确实更安全。研究表明，在未加密的存储库上使用 apt 确实会带来安全风险，因为 HTTP 传输容易受到重放攻击。

Answer 2

您的假设是错误的：您可以使用 HTTPS 下载。你只需要找到一个支持它的镜像，并将它的 URL 放在你的源列表中。您需要安装该apt-transport-https软件包。

Debian 没有让 HTTPS 下载变得容易，因为它的好处很少。Debian 包分发已经包含了一个验证包的机制：所有包都用Gpg签名。如果活动的中间人将您的流量重定向到包含损坏包的服务器，则会检测到损坏，因为 GPG 签名将无效。使用 GPG 而不是 HTTPS 的优势在于它可以抵御更多威胁：不仅可以抵御最终用户连接上的活跃中间人，还可以抵御流氓或受感染的镜像或包分发链中任何地方的其他问题.

HTTPS 确实提供了轻微的隐私优势，因为它隐藏了您下载的包。然而，被动观察者仍然可以检测您的计算机和软件包服务器之间的流量，因此他们会知道您正在下载 Debian 软件包。他们还可以很好地了解您正在从文件大小下载哪些软件包。

HTTPS 可以帮助的一个地方是引导信任，以获得已知有效的安装映像。Debian 似乎没有提供：有安装媒体的校验和，但只能通过 HTTP。

Answer 3

就在最近，我遇到了我公司的 apt 存储库的问题。问题是，如果我们使用标准的 http 传输，其他任何人都可以轻松获得包。由于公司正在打包自己的专有软件并且不想与所有人共享，因此 http 传输成为一个问题。不是悲剧，而是问题。有几种方法可以限制对包的访问 - 防火墙、限制 Web 服务器级别的访问、使用 ssh 作为传输。可以在此处找到有关此主题的非常易于阅读的阅读： 限制访问您的私有 Debian 存储库

在我们的例子中，我们决定使用 https 传输 + 客户端证书认证。简而言之，只需要：

1. 准备自签名证书、客户端和服务器（使用easy-rsa）；

2. 配置前端存储库的网络服务器仅接受 https；在 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'

我们开始了，不再有对存储库的未经授权的访问。所以这是非常有用和强大的东西。

Answer 4

请注意，由于像这样的漏洞

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

...绕过了 InRelease 签名，无论如何配置 HTTPS 可能是个好主意。

这不是一个单一的例子——许多其他默认为 HTTP 的更新系统也有签名验证失败的历史。

安全关键更新机制应同时使用 HTTPS和签名验证以保持稳健。每一个都减轻了另一个的失败。