SSL Fingerprint Mismatch when using DoD Repositories
Hi all, Can anybody explain to me in how the SSL fingerprint check for DoD repositories works and why it is strongly recommended for security reasons in https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.concepts.ht... We use DoD repositories to pin a tumbleweed snapshot we are working on in our private OBS instance. Each repository has the the respective Tumbleweed snapshot at https://download.opensuse.org/history/ together with the SSL fingerprint of download.opensuse.org<https://download.opensuse.org/history/> specified in its master subelement. However, since last week OBS refuses to download new DoD RPMs due to a fingerprint mismatch. dodup.log says: https://download.opensuse.org/history/20210622/tumbleweed/repo/oss/repodata/...: peer fingerprint does not match: 82bac52cf77a1ec92d2184ebb574a97ba28ba98b7b63c3c67656a16ff708fca5 != 286869be29119fd068f94c0b1cd318068568c0b7f3036b303f5d102e512be80f Please notice that 82ba...fca5 is the (current!) fingerprint of download.opensuse.org<https://download.opensuse.org/history/> and 2868...e80f is from ftp.gwdg.de/<https://ftp.gwdg.de/>, which makes kind of perfect sense as a curl on https://download.opensuse.org/history/20210622/tumbleweed/repo/oss/repodata/... on our download server gives the following response: ~> curl https://download.opensuse.org/history/20210622/tumbleweed/repo/oss/repodata/... <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="https://ftp.gwdg.de/pub/opensuse/history/20210622/tumbleweed/repo/oss/repodata/44346e5394dbd93f9071bfba407c8d5e61766999c4bab37b943d892371f65430-primary.xml.gz">here</a>.</p> <hr> <address>Apache/2.4.43 (Linux/SUSE) Server at download.opensuse.org Port 443</address> </body></html> Now to my questions: Is OBS expected to check the fingerprint of documents that can be redirected? I would have expected it to check only the fingerprint of the repomd.xml file in the regarding repository. On other servers I get other redirects (e.g. http://ftp.halifax.rwth-aachen.de). Anyway, I fail to see the sense of an SSL fingerprint check when resources can redirect to other domains. Do I miss an important point here? Wouldn't it be sufficient to rely on the GPG signature of the RPMs? I am considering removing the master subelement completely. This issue does not have its origin in a rotated letsencrypt certificate, we already take that into account. However, a new certificate could be issued the upcoming days so please do not look to closely on the specific fingerprints mentioned in this post but the general questions about fingerprint checks in DoD repositories. Any help is greatly appreciated. Regards, Robert Appendix: Examplary DoD configuration in our OBS <repository name="next"> <download arch="x86_64" url="https://download.opensuse.org/history/20210623/tumbleweed/repo/oss/" repotype="rpmmd"> <master url="https://download.opensuse.org/history/20210623/tumbleweed/repo/oss/" sslfingerprint="sha256:82bac52cf77a1ec92d2184ebb574a97ba28ba98b7b63c3c67656a16ff708fca5"/> <archfilter>x86_64</archfilter> <pubkey> -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.15 (GNU/Linux) mQENBEkUTD8BCADWLy5d5IpJedHQQSXkC1VK/oAZlJEeBVpSZjMCn8LiHaI9Wq3G 3Vp6wvsP1b3kssJGzVFNctdXt5tjvOLxvrEfRJuGfqHTKILByqLzkeyWawbFNfSQ 93/8OunfSTXC1Sx3hgsNXQuOrNVKrDAQUqT620/jj94xNIg09bLSxsjN6EeTvyiO mtE9H1J03o9tY6meNL/gcQhxBvwuo205np0JojYBP0pOfN8l9hnIOLkA0yu4ZXig oKOVmf4iTjX4NImIWldT+UaWTO18NWcCrujtgHueytwYLBNV5N0oJIP2VYuLZfSD VYuPllv7c6O2UEOXJsdbQaVuzU1HLocDyipnABEBAAG0NG9wZW5TVVNFIFByb2pl Y3QgU2lnbmluZyBLZXkgPG9wZW5zdXNlQG9wZW5zdXNlLm9yZz6JATwEEwECACYC GwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCU2dN1AUJHR8ElQAKCRC4iy/UPb3C hGQrB/9teCZ3Nt8vHE0SC5NmYMAE1Spcjkzx6M4r4C70AVTMEQh/8BvgmwkKP/qI CWo2vC1hMXRgLg/TnTtFDq7kW+mHsCXmf5OLh2qOWCKi55Vitlf6bmH7n+h34Sha Ei8gAObSpZSF8BzPGl6v0QmEaGKM3O1oUbbB3Z8i6w21CTg7dbU5vGR8Yhi9rNtr hqrPS+q2yftjNbsODagaOUb85ESfQGx/LqoMePD+7MqGpAXjKMZqsEDP0TbxTwSk 4UKnF4zFCYHPLK3y/hSH5SEJwwPY11l6JGdC1Ue8Zzaj7f//axUs/hTC0UZaEE+a 5v4gbqOcigKaFs9Lc3Bj8b/lE10Y =i2TA -----END PGP PUBLIC KEY BLOCK----- </pubkey> </download> <arch>x86_64</arch> </repository> -- Robert Rose Embedded System Engineer Edge Device Competence Center
Hi Robert, (I am not a big OBS expert, (and especially DoD part of OBS, which I heard first time today), so I hope somebody will provide more strict answer). I think your concern is valid, and it is something which may be improved inside OBS, because e.g. zypper and other utilities are fine to be redirected to mirrors without compromising security. But, if you need assistance with the error itself - a solution may be to use particular mirror in your country (instead of download.opensuse.org), or https://downloadcontent.opensuse.org (that will not redirect to mirrors).
On Mittwoch, 30. Juni 2021, 19:00:00 CEST Andrii Nikitin wrote:
Hi Robert,
(I am not a big OBS expert, (and especially DoD part of OBS, which I heard first time today), so I hope somebody will provide more strict answer).
I think your concern is valid, and it is something which may be improved inside OBS, because e.g. zypper and other utilities are fine to be redirected to mirrors without compromising security.
But, if you need assistance with the error itself - a solution may be to use particular mirror in your country (instead of download.opensuse.org), or https://downloadcontent.opensuse.org (that will not redirect to mirrors).
zypper and friends are validating repositories and packages using GPG. The GPG key is only owned by the provider of a package. While SSL certificates are created by third party authorities. Also in case of a redirect each mirror would have control over the content which can not verified. Therefore it is recommended to pin the SSL ceritifcate to the single owner you trust for your repository meta data. (the packages can come from a mirror and can get verified via the meta data). -- Adrian Schroeter <adrian@suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer
participants (3)
-
Adrian Schröter -
Andrii Nikitin -
Rose, Robert