Hmm, it's almost as if the author of https://whydoesaptnotusehttps.com/ may have overlooked a few things.
It should require multiple things to go wrong for catastrophic failure. This is a lesson from engineering that hasn't made its way to software development yet (outside of security engineering, anyway).
The process of listing all the security failure points and documenting the redundant mechanisms to protect them is called threat modeling.
For a system that installs OS-level binaries as root, it would absolutely be appropriate to threat model it and hold it to a defense in depth standard. In defense systems, they often require three levels of defense in depth, the last being an air gap network.
Lookup "threat modeling" and you will see how abstract a notion it is (even your comment calls for a "redundant mechanism" that may not be exactly what you are looking for), and how little information is available. End result? Most do it for the "checkbox effect". Don't get me wrong, I am not trying to obliterate what you said, just putting some factual data around it.
Open source projects, unfortunately, rarely have such contributors. Probably because building stuff is more fun than threat modeling (which can be quite tedious to do properly).
As an example, when an admin gets an AWS Security Group wrong, thereby exposing database servers / redis / customer data. Consequence... multimillion $ fines, brand/reputation damage.
It's kind of sad how badly things are set up to fail sometimes. :(
FWIW: 16 vulns in apt in NVD [0]; but 202 for openssl [1]
[0] https://nvd.nist.gov/vuln/search/results?form_type=Advanced&...
[1] https://nvd.nist.gov/vuln/search/results?form_type=Advanced&...
(It should be noted that it /does/ match on "possible RCE", which buffer overflows are often tagged with.)
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&...
I'm not saying none of the results from your search are RCEs, but not all are, and many are fairly speculative.
The problem is that there seem to be many classifications of remote code execution including buffer overflow and "code injection" and you can't choose multiple. :(
Lest anyone forgets:
https://www.schneier.com/blog/archives/2008/05/random_number...
APT ≥ 1.6 doesn't use libcurl; it uses GnuTLS directly.
Whether apt using OpenSSL would in fact increase network security is a separate and debatable question, but the argument as stated assumes it would not, and is sound.
SSL provides some security guarantees.
Using signed package databases also provide some security guarantees.
Both may overlap in what security they provide.
BUT!
If one fails, the other can continue to provide a subset of the previously available guarantees.
Priv-sep, correctly handling untrusted files (e.g. 1. check signature, then 2. execute whatever; not the other way round), memory-safe languages, etc. would be more welcome additions.
Could you describe a way to have double the attack surface that would effect the majority of peer servers?
Apt even has the had part already implemented by separating the network I/O in other processes. Only problem is that those currently write directly to system directories, but that can be fixed.
Other options include: not handle http directly in the package manager but use a known-good library (curl?); do priv-sep; not having the package manager execute code from a file before it checked its authenticity...
My personal opinion on the topic is that authenticating servers is a good thing to do (https does this; encryption is an added benefit), but time has shown that https is broken: libs are full of holes; the CA model is broken by design. Maybe share updates using ssh?
Similarly, the apt team ignoring a bug like this "because it's protected by https anyway." Is an invalid argument.
No.
If an attacker can inject packets that break your SSL lib, but wouldn't have broken your package manager, you added a vuln.
Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0545
Sure, there are bugs in libraries, but seeing as https is already widespread you’re not exposing yourself to MORE risk by using https over plain http, and you mitigate attacks like this post. Any random coffee shop, untrusted public WiFi, or attacker with a Pineapple could have used this attack to MITM HTTP apt, whereas the attacker would have to compromise an upstream mirror to pull off the same attack over HTTPS.
And re: the CA model, if you’re THAT worried about compromised or fake certs, then pin the cert for a root server like debian.org, then download PGP-signed cert bundles for mirrors and enforce certificate pinning using those bundles only. Done. Apple and Microsoft use cert pinning for their update systems (IIRC).
We are talking about a specific use case of https: software repositories, which are far higher-value targets than your random website, with another set of challenges. Your package manager can actually do some things as root; once it's owned, your system is Game Over.
Adding yet another lib on top of the (?) most important piece of software on your computer is not a risk to take lightly. There are more elegant solutions (signatures, priv-sep, not trusting anything until authenticated, etc.) that require less risky code to run, and fewer people to come into play.
> Sure, there are bugs in libraries, but seeing as https is already widespread you’re not exposing yourself to MORE risk by using https over plain http
Irrelevant. We're talking about instant game over if it goes to sh.. even if just once. More attack surface = more vulnerabilities.
Stop it, just stop it.
There really is no excuse not to use HTTPS in 2019, period.
> Yes, a malicious mirror could still exploit a bug like this, even with https.
and:
> I wouldn’t have been able to exploit the Dockerfile at the top of this post if the default package servers had been using https.
So which is it?
HTTP: Everyone can pwn you.
Not saying the first one is ideal, but the second one is definitely worse.
STOP IT. Though shall use HTTPS.
With HTTP, this can be exploited by anyone who can MITM a connection between you and the APT server or has control of your DNS.
If you consider all the cases like wi-fi hotspots, that's (potentially) quite a large set of attackers, and a relatively easy attack to pull off in a lot of cases.
With HTTPS, the attacker has either to compromise the whole APT mirror or has to get a valid HTTPS certificate for an APT mirror. This is likely harder to pull off, especially when you look at the work on improving CA security that the browser vendors have been doing over the last couple of years.
Meanwhile it's worth pointing out that OpenSSL has historically been one of the buggiest pieces of code in existence. Despite this being a game over RCE, it's the first of its kind in many years. If OpenSSL had been in the mix, Apt would have required forced upgrades /far/ more often. https://www.openssl.org/news/vulnerabilities.html
If you don't think OpenSSL is a high enough quality implementation, there are many others to choose from.
Even with a range of mirrors, it would still raise the bar for attackers, to require HTTPS.
Consider, why not double-wrap your stream? Put TLS on top of TLS on top of HTTP?
Do you have a response to my question? "Consider, why not double-wrap your stream? Put TLS on top of TLS on top of HTTP?"
Double-encrypting something with the same technique is pretty much always a sign of cargo cult crypto. Modern ciphers, like those used by TLS, are strong enough that there’s no reasonable way to break them applied once, and the downside is that applying them twice is making things slower than they need to be for zero added benefit.
On the other hand, TLS and PGP are very different things serving very different purposes, so nesting those makes sense. There is an added benefit from TLS, namely that you ensure that everything is protected in transit - including the HTTP protocol itself (which is currently not protected and which might be subject to manipulation as shown in this post). Plus, it provides some resistance to eavesdropping (and with eSNI + mirrors hosted on shared hosts, that resistance should improve further).
Sorry I don’t understand what double wrapping has to do with it, or why you’d ever do that.
You can see this pro-HTTPS opinion all over this discussion.
As for your "consider", I personally do double-wrap many streams: I have a VPN for my browser. The VPN is great for hiding my home traffic from being spied on by my ISP. Without the VPN, HTTPS streams would reveal hostnames (SNI) and IP addresses to my ISP.
If it's the exact same implementation then that doesn't really add a second layer. If, however, I am provided the option to run HTTPS over a VPN tunnel, then I would happily do that in a heartbeat. In fact, I frequently do run my web traffic over a proxy, thereby giving it at least two layers of encryption.