☰

Launchpad 现支持 HTTPS（2022）

tag-icon • tag-icon apt package-management security ppa
Launchpad 现支持 HTTPS（2022）

我使用了许多通过 ppas 获得的软件包。我花了一些时间尝试用 https 替换它们的 http URL，但无济于事。为什么 ppa.launchpad.net 没有证书？这是否意味着每个人都会受到中间人攻击？

我看到这个帖子里讨论了这个问题： 通过 ftp 或 https 从 ppa.launchpad.net 下载软件包

但它已经有近 10 年的历史了，而且它实际上并没有解释为什么没有 https。这难道不是只需要为 ppa.launchpad.net 放入证书吗？

答案1

Launchpad 现支持 HTTPS（2022）

Launchpad 终于推出了对通过 HTTPS 提供 PPA 的支持！

因此，您现在可以查找并替换任何引用旧域的 apt sources.list 文件：

这对于隐私而言是一个很大的进步，因为窃听者再也无法看到您访问了哪些 PPA 或下载了哪些软件包/操作系统版本。

使用 HTTPS 提供传输层安全性还可以增加纵深防御，以防在 GnuPG 或 apt 包签名机制中发现漏洞。这种情况在过去几年中已经发生过几次，所以这是一个很大的改进。

https://bugs.launchpad.net/launchpad/+bug/1473091

还有另一张票（截至 2022-02-07 仍然开放）用于add-apt-repository默认更改为首选 HTTPS。

https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1959015

答案2

由于您从 launchpad 下载的软件包都经过加密签名，就像其他所有 Debian 存储库一样，因此中间人攻击实际上并不可行。apt检查下载文件的签名.deb，任何篡改都会导致签名无效。无效签名会在安装前导致错误。所以从安全角度来看，我认为这不是一个大问题。

有人可能会说这侵犯了隐私，因为任何监听连接的人都可以看到你正在安装哪些软件。因此，HTTPS 连接确实是更好的选择。

至于你最后一个问题，如果他们不能只添加证书就完事了，我们都不知道 ppa.launchpad.net 背后的基础设施是如何工作的。对于单个服务器来说，事情通常就这么简单。但我怀疑我们谈论的是不是单个简单的服务器。基础设施可能比这更复杂，因此设置可能更复杂。还需要考虑服务器负载问题，因为加密所有传出流量需要比仅仅传送流量更多的 CPU 周期。根据他们收到的流量量，这可能会导致服务器负载过大，而他们可能不想处理。但请记住，这只是我的猜测，原因可能完全不同。

答案3

为什么 ppa.launchpad.net 没有证书？

查看启动板错误 1473091：默认 PPA 为 HTTPS

William Grant (wgrant) 于 2015-07-10 回复：

由于域名上提供任​​意内容，因此这并非易事。我们最好将其完全从 ppa.launchpad.net 中移除。

Colin Watson (cjwatson) 于 2017-03-27 回复：

这需要决定并获取一个不在 launchpad.net 下的合适域（例如，比较 launchpadlibrarian.net，它的存在原因相同），因为否则，ppa.launchpad.net 上用户提供的内容发起的 XSS 攻击将能够从其 launchpad.net 超级域中窃取 cookie。我们目前通过 Secure 属性保存了安全属性，但如果 ppa.launchpad.net 通过 HTTPS 提供服务，这将变得无效。当然，这需要重新配置各种东西以指向它，我预计会有相当多的杂项后果；这种任务需要花费大量时间进行调试。

Colin Watson（cjwatson）于2020-02-03阐述：

Launchpad 需要将其会话 cookie 的域设置为“.launchpad.net”，以便其他虚拟主机（code.launchpad.net、bugs.launchpad.net 等）可以看到它们，但这也会导致 launchpad.net 的所有其他子域都可以看到它们。我们还在这些 cookie 上设置了“安全”标志，这可以确保浏览器至少只通过 HTTPS 发送它们，从而缓解这种情况。但是，如果 ppa.launchpad.net 可以通过 HTTPS 访问，那么那里的任何页面都能够窃取您的会话 cookie。虽然我目前不知道如何让 ppa.launchpad.net 提供 Content-Type: text/html 的任意内容，但它是一项托管大量用户生成文件的服务，构造会混淆浏览器的滥用行为并不需要那么多。我们需要在安全使用 HTTPS 之前将其移动。

Colin Watson (cjwatson) 于 2021-09-28 开始采取行动解决该错误：

我已经提交https://portal.admin.canonical.com/C133313（仅内部链接）要求我们的系统管理员注册另一个域名，以便我们可以开始取得进展。

2021-09-30：

有问题的备用域名已被注册，并且我已提交https://portal.admin.canonical.com/C133345（再次，仅限内部链接）在相关主机上进行配置。

答案4

对于那些到达这里并希望根据上述解决方案快速解决问题的人来说：

相关内容