Results 1 to 3 of 3

Thread: Downloads page has insecure gpg-pubkey.asc and misnamed sha256 file

  1. #1

    Default Downloads page has insecure gpg-pubkey.asc and misnamed sha256 file

    Hi, I want to report two bugs on the downloads page of the website, but I'm brand new to the community and not sure if this is an already known issue and exactly where to report it. Both are related to redirects to the mirror network.

    1. PGP Public Key Insecure

    The gpg-pubkey.asc PGP signing public key is served over HTTP. This is insecure and could enable a MITM attack.

    How To Repeat

    1. Go to https://get.opensuse.org/tumbleweed/
    2. Copy the link at the bottom of the page for the key, which currently is https://download.opensuse.org/tumble...4-53674dd4.asc
    3. Examine the download with `curl -v https://download.opensuse.org/tumbleweed/repo/oss/gpg-pubkey-3dbdc284-53674dd4.asc`
    4. Note the HTTP 302 response location is to an HTTP mirror < location: http://mirror.us.leaseweb.net/opensu...4-53674dd4.asc

    Expected behavior

    Serve PGP key over a secure connection.

    Workaround

    Not known.

    Suggested fix

    Host the .asc file directly on the web server, not on the mirror network. Or, have a flag which redirects to HTTPS mirrors only.

    2. Checksum filename mismatch

    The SHA256 checksum file uses different file name than download, so sha256sum -c doesn't work.

    How To Repeat

    1. Go to https://get.opensuse.org/tumbleweed/
    2. Click Download link for the Offline Image ISO: https://download.opensuse.org/tumble...64-Current.iso
    3. Click the Checksum link for the same ISO: https://download.opensuse.org/tumble...ent.iso.sha256
    4. Notice that the checksum link redirects to a file with a different name: https://download.opensuse.org/tumble...dia.iso.sha256
    5. Run `sha256sum -c openSUSE-Tumbleweed-DVD*.iso.sha256`, and it reports no file found.

    Workaround

    Rename the downloaded ISO from "Current" to "Snapshot20220406-Media".

    Suggested fix

    Redirect to the "SnapshotYYYYMMDD-Media.iso" file name rather than the "Current.iso" name, the same as is done for the sha256 file already.

    Regards,

    Tim

  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    16,018
    Blog Entries
    3

    Default Re: Downloads page has insecure gpg-pubkey.asc and misnamed sha256 file

    Quote Originally Posted by softmoth View Post
    The gpg-pubkey.asc PGP signing public key is served over HTTP. This is insecure and could enable a MITM attack.
    I don't see this as a real problem. After downloading the "*.sha256" and "*.asc" file, I used GPG to verify the signature. The GPG system provides enough protection against MITM attacks. It arguably provides better protection than does the use of "https".

    2. Copy the link at the bottom of the page for the key, which currently is https://download.opensuse.org/tumble...4-53674dd4.asc
    After you download that key, you should use GPG to attempt to verify some of the signatures on the key.

    The SHA256 checksum file uses different file name than download, so sha256sum -c doesn't work.
    Yes, I agree that this can be a problem.

    I avoid it by going directly to https://download.opensuse.org/tumbleweed/iso/ for downloads, and I download the file that has the snapshot number as part of the file name. Hmm, I notice that this page is actually served by "https".
    openSUSE Leap 15.4; KDE Plasma 5.24.4;
    testing Tumbleweed.

  3. #3
    Join Date
    Sep 2012
    Posts
    7,880

    Default Re: Downloads page has insecure gpg-pubkey.asc and misnamed sha256 file

    Quote Originally Posted by nrickert View Post
    After downloading the "*.sha256" and "*.asc" file
    The first problem is not about key used to sign checksum, but about RPM signing key (as usual, posting several different issues in one thread is bad because they get easily confused). Theoretically someone could rebuild the whole distribution and sign with different key. Such MITM attack is only possible on initial repository definition, because later zypper would warn about repository key mismatch.

    This would invalidate file name though (it contains keyid) - I do not know whether zypper checks it.

    Also as was often mentioned in similar discussions - HTTPS only ensures that data is not changed between server and client. It does not ensure that you can actually trust data returned by server. Because there are other means to verify this data (packages are signed, repository metadata is signed) HTTPS does not really add much to the security in this case.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •