On Tuesday, February 9, 2021 7:41 PM, Jake Shipton <listmail at crazylinuxnerd.net> wrote: > On Wed, 2021-02-10 at 06:48 +1000, Chris Drake wrote: > > > Your Wkii page here: > > https://wiki.centos.org/FAQ/CentOSStream#Where_is_the_source_code.3F > > After discussion in which it was confirmed that TLS could be > > implemented "but traditionally we have not done so", was just updated > > by > > Manuel Wolfshant with the following lie:- > > Note: downloads are hosted on a mirror network, where we cannot > > mandate > > that every mirror node runs SSL/TLS, hence using regular http and not > > enforcing httpsFalse statements are disgusting to begin with, but ones that attempt > > to > > excuse the lazy decision to put all CentOS customers at risk are > > totally > > unacceptable. LE is free and easy to use and setup - it's a no- > > brainer to > > fix this problem, assuming someone isn't getting a kickback from some > > 3-letter-agency to leave this exploitable security hole open ? > > > > CentOS-devel mailing list > > CentOS-devel at centos.org > > https://lists.centos.org/mailman/listinfo/centos-devel > > Well.. > > Technically CentOS users are not customers - at all in fact - unless > they also happen to also own a paid RHEL subscription. > > Now onto the issue at hand. While the info should be accurate, I don't > think it's a big deal. > > TLS is certainly preferable for the mirror network, it isn't entirely > required from a security point of view. > > Realistically TLS shines most when you're transporting customer (user > data) or are dealing with some kind of sensitive information, trying to > stop prying eyes etc. > > From a mirror perspective it's not overly important because the only > protection TLS can add in this case is to prevent RPM tampering. But > even if someone intercepted your connection and successfully switched > the RPM while it was downloading the risk is minimal. > > This is because your local machine has the GPG key identity required > for the packages. All CentOS (and most RPM distros) sign their packages > with a GPG key, which package managers then use to verify the RPM has > not been tampered with. > > That's why if you want to install a non-GPG signed package from a repo > you need to specifically tell yum/dnf to ignore GPG signing. > > So, TLS or not, if your package has been swapped with a fake, your > package manager should notice this and refuse to install that package. > > The biggest problem from a security point of view would probably be a > rogue mirror that serves up modified packages.. a rogue mirror could > also carry TLS. > > That's why you sign the RPM for security. > > If you're worried that someone sees the package your about to install, > just remember two things: > > 1. Mirrors are public, everyone can easily know what packages and their > versions exist. > > 2. If there's an exploitable package just waiting to be installed for > an easy exploit.. whoever has that exploit will probably be randomly > probing systems for it - they won't need to monitor a mirrors > downloads.. > > This of course is all my quick and short personal opinion, I don't work > for Red Net. I reserve the right to be dead wrong. > > Just my 3c. I agree that TLS is being oversold as being a security benefit in this situation. As long as we are being pedantic about repository security, my person observation is the best point of attack is the repo XML files. These are not signed. If a rogue mirror or a man in the middle attack did take place, this seems like the best target. From what I can tell, DNF (and libxml2) typically are parsing these files while running as root. A zero-day against libxml2 would be gold. I would not go as far as to indicate this proves anyone has been lazy. Red Hat has been responsive to patching libxml2 as soon as they become aware of problems. But it would be nice if this was handled better. What excites me about Stream is the potential to push security enhancements forward sooner than just contributing into Fedora does. We may be able to backport important changes into Stream that the RHEL team may not have taken the time to in the past. Maybe someday we will see a pull request to createrepo to support adding a signature element towards the top of the XML file. And then another pull request for dnf to perform signature checking before xml parsing, preferably running in an unpriviledged/sandboxed way when possible. Normally even after the pull requests have proven themselves in Fedora for a while we would have to wait for the next RHEL cycle to see the changes in RHEL itself. But I think Stream may give hope of getting something like "gpgcheckxml" for dnf into a Technology Preview for Stream/RHEL 8. Right now it is still unclear to what degree we will just be mere consumers of Stream or how much we will be drivers of the roadmap. It seems like in the short term we might have to purpose a dnf-NG SIG group instead of being able to contribute back directly. But even that would be an improvement over how things worked in the past.