logo标签列表

如何使用apt-get与https？

aptconfigurationencryptionofficial-repositorieshttps

apt-get使用https或任何类型的加密吗？有没有办法配置它来使用它？

4请注意，由于存在像https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467这样的漏洞...绕过InRelease签名，配置HTTPS可能是一个不错的主意。 - Royce Williams
4这个功能有一个更加平凡的原因，为什么它会很有用。我经常使用一个有问题的“透明”代理连接到互联网，它倾向于阻止某些deb下载（它们可能触发了一些愚蠢的恶意软件拦截器）。但是通过https，代理不知道我在下载什么，所以它不会干扰。 - Nate Eldredge
5个回答

apt-get（以及其他与APT库相同的包操作命令）可以使用HTTP、HTTPS和FTP（以及挂载的文件系统）。如果您在/etc/apt/sources.list和/etc/apt/sources.list.d/*中指定了https:// URL，则APT将使用HTTPS。

APT验证软件包的签名。因此，您不需要具备提供数据认证的传输方式。如果攻击者修改您正在下载的文件，这将被注意到。使用签名验证比使用HTTPS连接更好，因为它可以检测到您从服务器下载的攻击，而不仅仅是传输过程中的攻击。

更准确地说，一个软件包的（简化的）数据流如下：

  1. 软件包在构建机器上生成。
  2. 软件包在构建机器上签名。
  3. 签名的软件包被复制到下载镜像。
  4. 您下载该软件包。

HTTPS确保第4步正确进行。软件包的签名确保第2至第4步正确进行。

实际上，对于第4步骤来说，HTTPS有一个小的好处：包签名只能确保包是真实的。在第4步骤中，攻击者可以冒充合法服务器并提供过时版本的软件包。例如，攻击者可以阻止您下载任何安全更新，希望利用您的计算机上的漏洞，如果没有这次攻击，您本应该修补这些漏洞。虽然这不是一个非常现实的情况，因为它需要一个主动攻击者（也就是控制您的互联网连接的人），但从原理上讲，这是可能发生的。
HTTPS的另一个好处是，如果您试图隐藏您从网络连接中窥探者那里下载Ubuntu软件包的事实。即使如此，窥探者仍然可以看到您连接到哪个主机；如果您连接到一个Ubuntu镜像并下载数百兆字节的数据，那么很明显您正在下载Ubuntu软件包。窥探者还可以根据文件的大小大致确定您正在下载哪些软件包。因此，除非您从同样大小的其他文件也提供的服务器下载，否则HTTPS只有在下载第三方软件包时才有用，并且只在非常特殊的情况下才有意义。
再强调一下：HTTPS的常规好处是你知道你连接到了真实的服务器，但在下载Ubuntu软件包时这个好处是无用的。软件包上的签名验证提供了比HTTPS更强的保证。
你能为SSL（通过HTTPS）安全性不如apt-get的哈希算法的说法提供更多信息（或参考资料）吗？ - Eliah Kagan
14并不是说它不安全，而是说它与你试图保护的内容关系较小。对于APT来说，加密交易内容并不那么重要，因为你下载的内容非常无争议：只是许多人下载的相同Ubuntu软件包。但重要的是确保你接收到的文件没有被篡改。 - thomasrutter
@EliahKagan 看看我的修改。HTTPS和软件包签名保护链条的不同部分。HTTPS确保你下载的数据来自你联系的服务器，但它不能保证服务器提供的数据就是你想要的数据。软件包签名则保证你获取到的数据是真实的。使用HTTPS有一个小的好处，即防止攻击者提供过时的数据，但我认为这不是一种非常实际的攻击方式。 - Gilles 'SO- stop being evil'
Gilles：谢谢！@neon_overload: HTTPS会数字签名(以及加密)服务器提供的数据。所以这不仅仅是（或者几乎完全不是）为了防止别人知道我在下载什么包。我认为Gilles解释得最好，他指出既然我不知道服务器的副本是否被篡改过，我应该验证软件包文件的原始签名。 - Eliah Kagan
3几周前，我尝试将源更改为https，但是它根本不起作用。当我尝试访问链接时，apt-get update会报错。使用ppas也是一样的情况。有人尝试过吗？ - Strapakowsky
14仓库（更新服务器）必须支持https/SSL才能正常工作。主要的archive.ubuntu.com不支持。您可以在浏览器中通过在URL前加上https://来检查服务器是否支持，看看是否会显示目录列表等内容。 - ish
@strapakowsky 正如izx所写的那样，您需要使用一个提供HTTPS服务的存储库。许多存储库没有这样做，因为这会给服务器和网络基础设施增加负载（无法缓存HTTPS，并且软件包是大文件，不经常更改，所以人们对它们进行缓存非常感兴趣）。 - Gilles 'SO- stop being evil'
8在第4步中，攻击者可以冒充合法的服务器并提供过时版本的软件包。实际上，我们通过给软件包信息设置一个到期日期来防止这种情况发生。APT会在此日期之后警告您的镜像已经过时。 - tumbleweed
@tumbleweed 哦，那太好了。我不知道这一点，谢谢你告诉我。这减少了攻击的机会窗口，但并没有消除威胁。攻击者很可能会使用倒数第二个版本的文件（以利用刚发布的漏洞），而这个版本通常还没有过期。尽管如此，我认为这种威胁相当不太可能发生。 - Gilles 'SO- stop being evil'
那么，如果 archive.ubuntu.com 不支持 HTTPS。有人知道有哪些服务器支持吗？ - Simón
@Simón 你可能想要发布一个新的问题，专门讨论这个。如果你提出一个关于是否存在支持https的镜像的问题，并附上一个解释，说明你并不深入探讨APT如何与https配合的问题，那么你可能会得到一个答案。 - Eliah Kagan
8这是一个支持HTTPS的15个镜像列表，以及生成该列表的脚本：http://pastebin.com/QY2TQ1dq - Shnatsel
几个月前，我可能会同意这个答案。 但在阅读了这篇文章之后，我改变了我的观点：https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/ 我不明白签名如何能够防止这样的攻击，除非它们是通过安全通道传输的（假设哈希算法足够强大，那么包内容本身仍然可以通过未加密的通道传递）。 - didi_X8
@didi_X8 签名确实可以防止中间人攻击（除非通过提供旧版本的软件包列表来隐藏更新）。我只是粗略浏览了这篇文章，除了“很多人可能会对你进行中间人攻击”之外，它还有其他内容吗？当然，你需要一个信任锚点才能开始。 - Gilles 'SO- stop being evil'
@Gilles 你说得对，我把签名和哈希（像git一样）搞混了。 这篇文章主要表明中间人攻击可能比我们大多数人想象的规模更大。 - didi_X8
如果我没记错的话，我在某个地方看到使用GPG签名软件包是可选的。那么在这种情况下它是如何工作的呢？ - VarunAgw
但是你的机器如何获取用于签署软件包的正确公钥呢？换句话说，有什么办法防止攻击者使用自己的密钥签署文件并替换公钥以便apt接受下载的软件包呢？必须有一种验证公钥的方法来确保这个过程的安全性。 - TheGreatContini
1@TheGreatContini 公钥是初始安装镜像的一部分。您需要通过HTTPS下载它来引导安全性。而HTTPS则使用了一个证书链，该链追溯到与您用于下载安装镜像的浏览器或操作系统一起提供的某些签名。 - Gilles 'SO- stop being evil'
3实际上，apt曾存在多个漏洞 (1, 2)，如果使用https而不是http，就能够防止以root权限执行任意代码。因此，https确实提供了真正的安全优势，因为有时候会发生错误，拥有更多的安全层级越好。 - Niklas Holm
1使用https的一个很好的理由是，当您在虚拟机中工作并且您的主机是运行防病毒软件的Windows机器时。防病毒软件有效地像中间人攻击者一样工作。在我的情况下，我正在更新Kali Linux中的Python软件包。 Avast拦截了连接并阻止了一些文件。将Kali的apt仓库切换到https后（请参见https://www.kali.org/blog/kali-linux-repository-https-support/），我不再有这个问题。 - Amedee Van Gasse
使用APT时，更重要的通常不是您的连接是否加密，而是您接收的文件是否被篡改。
APT具有内置的签名验证功能，以确保这一点。
加密可以防止窃听者看到您正在下载什么，但您实际上正在下载（和请求）的内容相当普遍：它将与数千其他Ubuntu用户下载的内容相同，并且文件中不包含任何在许多服务器上都可以自由获取的内容。但是，如果您需要隐私保护，以特定软件包为例，可以使用HTTPS（在sources.list中指定）。
内置于APT中的签名验证将确保您接收的文件未被篡改。无论文件来自何处，甚至可能在您和服务器之间有代理或反向代理以减少服务器负载或加快速度，签名验证仍然确保您获得未经修改的文件，匹配只能使用原始文件和Ubuntu的私钥副本加密生成的签名。
如果您切换到HTTPS，那么您将无法再利用代理服务器来加快访问速度或减轻负载。而且，它不会提供任何额外的保证，因为APT的签名验证已经能够防止篡改。然而，这意味着窃听者（比如您的ISP）将无法看到您正在下载哪些软件包（这些软件包很可能不是机密的，正如Gilles所指出的，他们可以从文件大小猜测）。
3HTTPS不会提供太多隐私，因为文件的大小是可见的。实际上，HTTPS有一个小的好处，就是确保控制您的网络连接的攻击者无法悄悄地插入过期数据。这有点牵强。 - Gilles 'SO- stop being evil'
7好的观点。通过“陈旧数据”，我理解你指的是中间人设置了一个由稍早版本组成的Ubuntu镜像，但仍然与Ubuntu在当时签名的内容保持不变。 - thomasrutter
6没错，就是这样。如果我有些专业术语的话，请毫不犹豫地指出来，我需要记住这里是[ubuntu.se]而不是[security.se]。 - Gilles 'SO- stop being evil'
3似乎在apt中有一个很大的漏洞 - 当您执行apt update时，如果有个人在中间提供虚假的索引，apt将快乐地接受中间人提供的任何内容，并将其写入/var/lib/apt/lists。这不仅仅是针对邪恶的中间人，而是像您在酒店的WiFi上被重定向到登录页面一样，如果您在登录之前运行了apt update，您的/var/lib/apt/lists 将会被酒店主页的HTML破坏。虚假！ 无论如何，基本的TLS证书检查可以立即解决这个问题。 - Marius
@Marius 这应该是不可能的，因为验证机制覆盖了列表和软件包。如果你使用标准的Apt安装进行了复现，你应该向维护者报告此问题。 - thomasrutter
3虽然我理解你的观点，但我不禁觉得，在如今HTTPS的成本非常低廉的情况下，我宁愿不公开我系统中安装的数据包列表，而是让窃听者付出一些努力。信息安全界似乎有一种“如果不是防弹的话就别费心”的态度，这与我（可能是被误导的）常识相悖。我想我不太理解威胁模型。我们是否真的有一支由胜任且积极进攻者组成的部队存在？我认为，如果攻击没有商品化，大多数想要攻击者甚至不会尝试。 - gd1
@ gd1 当这篇文章写的时候，HTTPS被认为比现在更加“可选”。如今，如果你的镜像支持，最好还是使用HTTPS——我不知道有多少镜像支持。尽管如此，以上所有内容仍然是正确的，因为HTTPS对于防止篡改并没有提供任何安全性，毕竟这是由非官方第三方运营的镜像网络。HTTPS可能提供的任何好处都取决于你是否信任你从中下载的特定镜像。 - thomasrutter
1从来没想过HTTPS在这种情况下能提供防篡改的安全性。我的评论只是轻微地质疑Gilles的观点，即HTTPS提供的额外隐私并不值得，因为窃听者可以通过文件大小推断出文件名。 - gd1
2APT具有内置的签名验证功能，以确保此操作。可悲的是，APT也存在内置的漏洞，允许中间人攻击篡改该验证（参见1和2），并以root权限执行任意代码。如果使用https而不是http，这些攻击将被阻止。这证明了深度防御原则在这里同样适用于其他地方。 - Niklas Holm
如果中间人攻击发生在镜像和其上游之间，或者镜像本身被入侵或成为攻击者，那么用户与镜像之间的HTTPS连接并不能防止这种情况。Apt的签名验证旨在保护整个路径，包括对抗恶意镜像。您可以更新apt以防范最近的漏洞。 - thomasrutter

我认为这个问题需要一个适合外行人的答案，所以...

在Ubuntu 19.10（Eoan）的每日构建版本中，默认情况下APT仍然不使用HTTPS（该版本仍在开发中）。可以通过检查/etc/apt/sources.list文件并注意到所有源URL都使用"http:" URL方案来验证这一点。

要配置它使用HTTPS，可以按照以下说明进行操作：

首先，找到一个可信赖的官方Ubuntu存档镜像，支持HTTPS：

  1. 导航至Ubuntu官方镜像存档网页。
  2. 在该网页的表格中，找出那些（A）托管在你认为可信任的网站上的镜像，（B）有一个“http:”镜像，并且可选地，（C）符合你的地理位置接近、服务器速度和更新频率的偏好。
  3. 在该网页的表格中，点击步骤（2）中找到的镜像的“http”链接，以访问镜像的“http:”版本。
  4. 在浏览器地址栏中，手动将网页URL中的“http:”更改为“https:”。
  5. 再次导航至镜像（通过“https:”URL），查看是否解析成功。

例如，我认为维基媒体基金会是可信任的，所以我访问了http://mirrors.wikimedia.org/ubuntu/镜像URL，随后将其更改为https://mirrors.wikimedia.org/ubuntu/，成功解析。

如果您使用的是Firefox（67.0.4）并且安装了HTTPS Everywhere（2019.6.27）扩展，并启用了“加密所有符合条件的网站”功能（通过工具栏按钮面板），则可以省略步骤（4）和（5），因为该扩展将自动修改URL以利用HTTPS，从而更快地确定“https：”版本的URL是否可解析。
其次，更新您的APT源列表：
1. 执行命令sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup备份您的更新源列表。 2. 在命令sudo sed --in-place --regexp-extended 's http://(us\.archive\.ubuntu\.com|security\.ubuntu\.com) https://mirrors.wikimedia.org g' /etc/apt/sources.list中，将镜像基本URL（在此处显示为https://mirrors.wikimedia.org）替换为您首选镜像的基本URL，然后执行该命令。
第三，你应该检查 /etc/apt/sources.list.d/ 目录中的内容，看看是否有来自 Ubuntu 存档之外的软件安装后可能会更改为 "https:" 的 "http:" 源。
例如，微软的 Visual Studio Code 软件包会在该目录中添加一个 vscode.list 文件，其中指定了一个 "http:" URL。将 URL 方案从 "http:" 更改为 "https:" 可以通过 HTTPS 进行更新。
在修改这些文件之前，考虑备份任何此类源文件。
最后，执行更新操作以确保更新能够正常工作：
1. 执行 sudo apt-get update 命令。 2. 如果该命令不按预期工作，请通过执行 sudo cp /etc/apt/sources.list.backup /etc/apt/sources.list 命令恢复备份的源列表文件。
值得注意的是，还有一个apt-transport-https软件包可以为APT添加HTTPS支持。然而，根据网页https://launchpad.net/ubuntu/eoan/+package/apt-transport-https上的信息，这个软件包显然是不必要的，并且自APT 1.5以来就不再需要，这一点在执行命令apt-cache show apt-transport-https后显示的信息中也有说明。
最近的APT版本已经内置了TLS支持，所以您只需要将软件包仓库镜像的URL替换为以https开头的URL即可。对于Debian来说，可能是这样的：
deb https://deb.debian.org/debian/ stretch main
deb https://deb.debian.org/debian-security stretch/updates main
deb https://deb.debian.org/debian/ stretch-updates main

这是有用的，尽管APT包含自己的签名协议以确保软件包不被篡改，因为APT可能存在漏洞（正如已经发生过的：CVE-2016-1252，CVE-2019-3462）。HTTP/TLS协议及其密码算法受到严格审查，因此如果您添加了这一安全层，严重的零日漏洞就不太可能出现。
3哎呀，我现在才意识到这个网站是 Ask Ubuntu。 :) 我找不到类似于 Ubuntu 的 CDN 解决方案。 - Leif Arne Storset
PPA软件包似乎并非如此。 - Sqerstet