71–80 of 166 posts
Hmm, it's almost as if the author of https://whydoesaptnotusehttps.com/ may have overlooked a few things.
Makes me chuckle, since my comment on the HN post yesterday that highlighted that someone will be bitten if security principles are ignored got downvoted.
Earlier quoted context omitted.
OTOH, they would have been right if there had been (yet another) bug in openssl/whatever lib would be used for https. 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&...
How many of these would result in RCE?
Earlier quoted context omitted.
Because that just makes things slower for no good reason?
Sounds like an argument for rejecting HTTP+TLS single-wrap too. (For apt — not in general.)
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).
Earlier quoted context omitted.
use torrents
The official torrent links are also distributed over insecure HTTP and are also trivially easy to MitM attack.
Earlier quoted context omitted.
use torrents
The official torrent links are also distributed over insecure HTTP and are also trivially easy to MitM attack.
I imagine that this is a higher risk for virtualized servers in a public cloud. I use Linode, so somebody else could have set up a Linode to MITM everybody and serve the exploit. If it were a private home or corporate network, somebody would either have to be on your network, or on a piece of major infrastructure between you and the mirrors.
Is there a way to tell from the apt log whether I am affected? It looks like you can see it trying to install an extra dependency package. Anyway, the logs are not immutable or verifiable, so if somebody got root they could theoretically kill apt, write a fake log in its place and then email that to me...
I took full images of all my servers a few days ago, so at least I have those should I need them.
All my servers do an update and dist-upgrade every 24 hours, and it emails me the log. I saw this post just a few minutes after checking the log for today. I imagine that this is a higher risk for virtualized servers in a public cloud. I use Linode, so somebody else could have set up a Linode to MITM everybody and serve the exploit. If it were a private home or corporate network, somebody would either have to be on y…
I think it might be the other way around (at least in terms of virtualized servers versus physical servers, both on public cloud) -- it is easier to implement IP address and other filtering measures with virtualized servers than inside physical network switches. Linode and other virtual machine providers almost universally implement this filtering, but many dedicated server providers are not as robust.
Earlier quoted context omitted.
The official torrent links are also distributed over insecure HTTP and are also trivially easy to MitM attack.
Ugh couldn’t they just put magnet links on their nice HTTPS site? It sounds like they just really don’t want to have to update their site when new releases come out.
Using HTTP for apt may seem bad, but you should really pay attention to Ubuntu itself: https://github.com/canonical-websites/www.ubuntu.com/issues/... Ubuntu ISOs aren't served securely and are trivially easy to MitM attack. This vulnerability is still being exploited: https://www.bleepingcomputer.com/news/security/turkish-isp-s...
Just downloaded Ubuntu server for some local instances here at home and realized that I hit this path without even knowning.
[edit] Looks like ISO signatures are served over HTTP as well.