10 thoughts on - Can’t Upgrade Sssd-*

• The short reply size made me think to try a packet capture, and it turned out to be a message from the site’s “transparent” HTTP proxy, telling me that content’s blocked.

  Rather than fight with site IT over the block list, I have a new question: is there any plan for getting HTTPS-only updates in CentOS? Changing all “http” to “https” in my repo conf files just made the update stall, so I assume there are mirrors that are still HTTP-only.

• No .. we host things on donated servers, we therefore are not putting private keys on there. That (and external mirrors) is why we SIGN
  repodata.xml. We just can’t risk putting private keys for CentOS.org on machines that are donated.

• The mirror I still maintain IS http only:

  http://bay.uchicago.edu/CentOS/

  as of this moment I have no plans to change anything (like remove CentOS
  from mirror machine, or force/redirect http to https on the server side).

  I hope, this helps.

  Valeri

  —
  ++++++++++++++++++++++++++++++++++++++++
  Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
  ++++++++++++++++++++++++++++++++++++++++

• We had such a discussion in the past on the list. I assume there are no plans for improvements?

  Would a change from dnf’s “mirrorlist” to “metalink” be a starting point? Albeit mirrorlist.CentOS.org would be still on http only.

  metalink would allow to configure https-only mirrors. Like:

  $ curl
  “https://mirrors.fedoraproject.org/metalink?protocol=https&repo=epel-8&arch=x86_64”

  But to be honest the mirrorlist.CentOS.org element in the chain must have also a secure solution.

  —
  Leon

• I guess I don’t understand how the mirror system works, then, because I thought DNF/YUM contacted a central server (presumably under CentOS.org) which then selected one or more mirrors with an entirely different Internet domain, with none of the actual package traffic being on the CentOS.org servers, only metadata.

  While I might be nice to have the metadata secured as well — more than nice, since an attacker could do bad stuff by MITM’ing it — my immediate problem would be solved if it contacted the mirror over HTTPS, since I haven’t configured this box to accept keys minted by any sort of snoopware box on the site LAN.

  I suppose the site might just block HTTPS entirely if it doesn’t pass through their snoopware, but one problem at a time, yes?

  Meanwhile, I suppose I’ll just download the packages on another box and manually rpm -U them.

• Yes .. BUT wrt private keys .. we don’t want any to live on machines we don’t physically own. (A requirement to stand up the web sever for https).

• Yeah, I get that.

  What I don’t get is why, if DNF goes to http://foo.CentOS.org to pull metadata, and it tells DNF to go to https://bar.qux.example.edu to download the packages specified by that metadata, why must there be any private keys for *.CentOS.org involved on example.edu’s servers?

  Surely the sysadmin of bar.qux.example.edu obtains a TLS key pair from some trusted CA that certifies that bar.qux.example.edu is valid according to the worldwide TLS public PKI.

  If we’re talking about package signing keys, surely that all happens on CentOS.org servers, and the resulting RPM packages are distributed as-is, not re-signed on each mirror server.

• I don’t think they do require it unless that node is supposed to look like a part of mirror.CentOS.org. The issue is that various tools fail when a mirrorlist sends them data which is not the same as ‘requested’. So if you send over a http link and get an https, the tool may crash or try to talk HTTP to the TLS port etc.

  “`
  $ curl ‘http://mirrorlist.CentOS.org/?release=8&arch=x86_64&repo=BaseOS’
  http://mirror.us.oneandone.net/linux/distributions/CentOS/8.3.2011/BaseOS/x86_64/os/
  http://mirror.cs.vt.edu/pub/CentOS/8.3.2011/BaseOS/x86_64/os/
  http://distro.ibiblio.org/CentOS/8.3.2011/BaseOS/x86_64/os/
  http://ftpmirror.your.org/pub/CentOS/8.3.2011/BaseOS/x86_64/os/
  http://mirrors.rit.edu/CentOS/8.3.2011/BaseOS/x86_64/os/
  http://mirror.atl.genesisadaptive.com/CentOS/8.3.2011/BaseOS/x86_64/os/
  http://atl.mirrors.clouvider.net/CentOS/8.3.2011/BaseOS/x86_64/os/
  http://repos-va.psychz.net/CentOS/8.3.2011/BaseOS/x86_64/os/
  http://CentOS-distro.cavecreek.net/CentOS/8.3.2011/BaseOS/x86_64/os/
  http://mirror.vtti.vt.edu/CentOS/8.3.2011/BaseOS/x86_64/os/
  “`

  A metalink system provides different data which would allow for these
  ‘transfers’ but it has other problems which are mitigated with TLS
  connections

  “`
  
  
  
  1603150039
  6282
  
  7de20cbe8e7ef87b4fc1b35191277ab4
  7d0c65c0daf1677eda2152e25e39a3dc4f3be027
  7a75be2ebd56e44c9d33252a12158c8b7079331e9c73aa62c609414299dabf06
  dfcc30a274b140d3ff65c3b3c9987a7c057a30e89880b13472f61be5fdd8829761653e11309d25680dc89d1af91d015ea0ca6992bbabec60d8b472f3e81ebba2
  
  
  
  http://download-ib01.fedoraproject.org/pub/fedora/linux/releases/33/Everything/x86_64/os/repodata/repomd.xml
  
  rsync://
  download-ib01.fedoraproject.org/fedora-enchilada/linux/releases/33/Everything/x86_64/os/repodata/repomd.xml
  
  
  https://download-ib01.fedoraproject.org/pub/fedora/linux/releases/33/Everything/x86_64/os/repodata/repomd.xml
  
  
  
  
  
  “`

  In this way the tool can know and choose the version of TLS or download protocol (rsync) which it can deal with.

  I don’t present this as a better way, just a different way. Both systems make different security and availability choices to meet different requirements. [The Fedora system is known to be fragile in TLS bringup during the thundering bison rush of several million EPEL systems updating caches at 04:00 while the CentOS system doesn’t have this issue.]

  —
  Stephen J Smoogen.

• Correct .. I am talking only about donated machines that are part of the mirror.CentOS.org dns name.

  Other mirrors that have their own hostnames that are non CentOS.org can use https and it works fine.

  We just don’t use it w/ mirror.CentOS.org machines.

  but we do sign the metadata .. so you can make sure the rpms, no matter their origin, are real if you enable signed repodata in yum/dnf regardless of where they are downloaded and if http or https.

• My key incorrect assumption was that this is just a front end, and all of the actual file pulls came from other second-level domains. I didn’t realize you were allowing other organizations to masquerade as CentOS.org.

  The usual solution to this sort of problem is to set up another domain; CentOSmirrors.org or similar. Then you can separately manage the key spaces of the two domains.

  This sort of design also solves certain types of CORS and XSS problems, such as third-parties getting sent cookies for the main site they haven’t actually got any business seeing, because the HTTP client can’t tell the difference.

  This is why you’ll find your uploads to social media sites being served back from domains other than the main user-facing one: it’s user-provided content, so they refuse to ship it from the domain that handles authentication.

  I wasn’t worried about that. I just wanted to use HTTPS to hide the RPM data from the site’s overly paranoid “translucent” HTTP gateway proxy, so it wouldn’t block the download.