[opensuse-project] Insecure openSUSE Downloads
Hi all, Given the recent case of Linux Mint, I went to double-check how we deal with distribution of checksums and images. It looks like we just distribute them all without TLS, which means there's no hardening against MITM attacks on users trying to download openSUSE. In addition, I couldn't find any mention of GPG signatures for the releases, so there's no web-of-trust way of verifying that an image I download is one that was signed by the key of the cheif maintainers. In addition, the checksums are stored right next to the ISOs, making them useless against a malicious attack (although it is useful for verifying that the download completed). Maybe we could add the checksums to the Wiki (which is served over TLS and is managed completely separately to the download servers). I think this is something we should fix ASAP. If I missed something, please feel free to tell me, and we can work on better advertising the way we secure our downloads. -- Aleksa Sarai Docker Core Specialist SUSE Australia https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 29/02/2016 08:29, Aleksa Sarai wrote:
Hi all,
Given the recent case of Linux Mint, I went to double-check how we deal with distribution of checksums and images. It looks like we just distribute them all without TLS, which means there's no hardening against MITM attacks on users trying to download openSUSE. In addition, I couldn't find any mention of GPG signatures for the releases, so there's no web-of-trust way of verifying that an image I download is one that was signed by the key of the cheif maintainers.
In addition, the checksums are stored right next to the ISOs, making them useless against a malicious attack (although it is useful for verifying that the download completed). Maybe we could add the checksums to the Wiki (which is served over TLS and is managed completely separately to the download servers).
I think this is something we should fix ASAP. If I missed something, please feel free to tell me, and we can work on better advertising the way we secure our downloads.
The checksums also don't match some of the mirrors. This was reported to admin@ a few weeks ago but was originally reported on Reddit 2-3 months ago before I came across it again when getting a Leap ISO. Ticket #10724 Ignoring the obvious major issue of out of date mirrors (it's an old iso on at least 1 mirror - still a massive security issue as teaching people to ignore checksums) but it does highlight that the mirrors are not verified. Jon -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
W dniu 29.02.2016 o 09:39, Jon Brightwell pisze:
On 29/02/2016 08:29, Aleksa Sarai wrote:
Hi all,
Given the recent case of Linux Mint, I went to double-check how we
(...)
download is one that was signed by the key of the cheif maintainers.
In addition, the checksums are stored right next to the ISOs, making them useless against a malicious attack (although it is useful for verifying that the download completed). Maybe we could add the checksums to the Wiki (which is served over TLS and is managed completely separately to the download servers).
I think this is something we should fix ASAP. If I missed something, please feel free to tell me, and we can work on better advertising the way we secure our downloads.
The checksums also don't match some of the mirrors. This was reported to admin@ a few weeks ago but was originally reported on Reddit 2-3 months ago before I came across it again when getting a Leap ISO.
Ticket #10724
Ignoring the obvious major issue of out of date mirrors (it's an old iso on at least 1 mirror - still a massive security issue as teaching people to ignore checksums) but it does highlight that the mirrors are not verified.
But the checksums are pgp signed (inline pgp signature inside the sha256 ckecksum file), so as long as the user has the pubkey used for this signature and uses it to verify the checksums, everything is fine. The pubkey long fingerprint is noted on the main iso download page, not on the mirrors pages. The current setup is far more secure than what Linux Mint had. Don't panic ;-). If an image on a mirror doesn't match the signed checksums, then it should be discarded by the user and redownloaded form another mirror. Simple stuff imho. -- Łukasz "Cyber Killer" Korpalski mail: cyberkiller8@gmail.com xmpp: cyber_killer@jabster.pl site: http://website.cybkil.cu.cc gpgkey: 0x72511999 @ hkp://keys.gnupg.net //When replying to my e-mail, kindly please //write your message below the quoted text.
On 2016-02-29 10:00, Łukasz 'Cyber Killer' Korpalski wrote:
But the checksums are pgp signed (inline pgp signature inside the sha256 ckecksum file), so as long as the user has the pubkey used for this signature and uses it to verify the checksums, everything is fine. The pubkey long fingerprint is noted on the main iso download page, not on the mirrors pages.
But the PGP signatures, to be secure, need a web of trust. A separate and trusted method to download and verify the keys themselves, and this we don't have. Probably a certified page with all keys used by the project for signing downloads and builds. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
W dniu 29.02.2016 o 11:52, Carlos E. R. pisze:
On 2016-02-29 10:00, Łukasz 'Cyber Killer' Korpalski wrote:
But the checksums are pgp signed (inline pgp signature inside the sha256 ckecksum file), so as long as the user has the pubkey used for this signature and uses it to verify the checksums, everything is fine. The pubkey long fingerprint is noted on the main iso download page, not on the mirrors pages.
But the PGP signatures, to be secure, need a web of trust. A separate and trusted method to download and verify the keys themselves, and this we don't have.
Probably a certified page with all keys used by the project for signing downloads and builds.
Certified by who? Some commercial CA? IMHO these are less trustable than any randomly picked PGP key. There is no running from it - at some point you need to trust someone. At this point I trust the openSUSE Project Signing Key 0x3DBDC284 to be okay. I signed it with my key too, so in the future I'll be able to quickly notice if this is the key I trusted today. That is enough of the web of trust, that I need. -- Łukasz "Cyber Killer" Korpalski mail: cyberkiller8@gmail.com xmpp: cyber_killer@jabster.pl site: http://website.cybkil.cu.cc gpgkey: 0x72511999 @ hkp://keys.gnupg.net //When replying to my e-mail, kindly please //write your message below the quoted text.
On 2016-02-29 12:32, Łukasz 'Cyber Killer' Korpalski wrote:
W dniu 29.02.2016 o 11:52, Carlos E. R. pisze:
On 2016-02-29 10:00, Łukasz 'Cyber Killer' Korpalski wrote:
Probably a certified page with all keys used by the project for signing downloads and builds.
Certified by who?
On an https static page, at least.
At this point I trust the openSUSE Project Signing Key 0x3DBDC284 to be okay.
Sure, but how do you know that you got a correct copy of the key, not intercepted?
I signed it with my key too, so in the future I'll be able to quickly notice if this is the key I trusted today. That is enough of the web of trust, that I need.
Yes, but before signing it the first time you have to make a jump of faith that you got the correct one. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
But the checksums are pgp signed (inline pgp signature inside the sha256 ckecksum file), so as long as the user has the pubkey used for this signature and uses it to verify the checksums, everything is fine. The pubkey long fingerprint is noted on the main iso download page, not on the mirrors pages.
But the PGP signatures, to be secure, need a web of trust. A separate and trusted method to download and verify the keys themselves, and this we don't have.
Probably a certified page with all keys used by the project for signing downloads and builds.
Certified by who? Some commercial CA? IMHO these are less trustable than any randomly picked PGP key. There is no running from it - at some point you need to trust someone.
Security isn't binary. Yes, you have to trust /someone/, that isn't an excuse for not providing the keys over TLS. Just because a rogue CA could mess things up doesn't suddenly make TLS useless.
At this point I trust the openSUSE Project Signing Key 0x3DBDC284 to be okay. I signed it with my key too, so in the future I'll be able to quickly notice if this is the key I trusted today. That is enough of the web of trust, that I need.
This is why the whole web of trust exists. Once you've been signed (in person) into the web of trust, you can verify the "level of trust" for any other key in the WoT, which could include the openSUSE signing keys. -- Aleksa Sarai Docker Core Specialist SUSE Australia https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
W dniu 29.02.2016 o 11:52, Carlos E. R. pisze:
On 2016-02-29 10:00, Łukasz 'Cyber Killer' Korpalski wrote:
But the checksums are pgp signed (inline pgp signature inside the sha256 ckecksum file), so as long as the user has the pubkey used for this signature and uses it to verify the checksums, everything is fine. The pubkey long fingerprint is noted on the main iso download page, not on the mirrors pages. But the PGP signatures, to be secure, need a web of trust. A separate and trusted method to download and verify the keys themselves, and this we don't have.
Probably a certified page with all keys used by the project for signing downloads and builds.
Certified by who? Some commercial CA? IMHO these are less trustable than any randomly picked PGP key. There is no running from it - at some point you need to trust someone.
At this point I trust the openSUSE Project Signing Key 0x3DBDC284 to be And 32bit Keyids are not enough anymore. See also here for reference: https://evil32.com/ It takes 4 seconds to generate a colliding 32bit key id on a GPU (using scallion <https://github.com/lachesis/scallion>). Key servers do
Hi, On 02/29/2016 12:32 PM, Łukasz 'Cyber Killer' Korpalski wrote: little verification of uploaded keys and
allow keys with colliding 32bit ids. Further, GPG uses 32bit key ids throughout its interface and does not warn you when an operation might apply to multiple keys.
Sebastian -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers
On 02/29/2016 06:32 AM, Łukasz 'Cyber Killer' Korpalski wrote:
W dniu 29.02.2016 o 11:52, Carlos E. R. pisze:
On 2016-02-29 10:00, Łukasz 'Cyber Killer' Korpalski wrote:
But the checksums are pgp signed (inline pgp signature inside the sha256 ckecksum file), so as long as the user has the pubkey used for this signature and uses it to verify the checksums, everything is fine. The pubkey long fingerprint is noted on the main iso download page, not on the mirrors pages.
But the PGP signatures, to be secure, need a web of trust. A separate and trusted method to download and verify the keys themselves, and this we don't have.
Probably a certified page with all keys used by the project for signing downloads and builds.
Certified by who? Some commercial CA?
Does https://letsencrypt.org/ apply? -- Regards, Uzair Shamim -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 02/29/2016 06:32 AM, Łukasz 'Cyber Killer' Korpalski wrote:
W dniu 29.02.2016 o 11:52, Carlos E. R. pisze:
On 2016-02-29 10:00, Łukasz 'Cyber Killer' Korpalski wrote:
But the checksums are pgp signed (inline pgp signature inside the sha256 ckecksum file), so as long as the user has the pubkey used for this signature and uses it to verify the checksums, everything is fine. The pubkey long fingerprint is noted on the main iso download page, not on the mirrors pages.
But the PGP signatures, to be secure, need a web of trust. A separate and trusted method to download and verify the keys themselves, and this we don't have.
Probably a certified page with all keys used by the project for signing downloads and builds.
Certified by who? Some commercial CA?
Does https://letsencrypt.org/ apply? -- Regards, Uzair Shamim -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
But the checksums are pgp signed (inline pgp signature inside the sha256 ckecksum file), so as long as the user has the pubkey used for this signature and uses it to verify the checksums, everything is fine. The pubkey long fingerprint is noted on the main iso download page, not on the mirrors pages.
But the PGP signatures, to be secure, need a web of trust. A separate and trusted method to download and verify the keys themselves, and this we don't have.
Probably a certified page with all keys used by the project for signing downloads and builds.
Certified by who? Some commercial CA?
Does https://letsencrypt.org/ apply?
LE is backed by a commercial CA (unless some root CA decides to back LE, which is very unlikely since their whole business model depends on paying customers). -- Aleksa Sarai Docker Core Specialist SUSE Australia https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Mon, Feb 29, 2016 at 11:52:51AM +0100, Carlos E. R. wrote:
On 2016-02-29 10:00, Łukasz 'Cyber Killer' Korpalski wrote:
But the checksums are pgp signed (inline pgp signature inside the sha256 ckecksum file), so as long as the user has the pubkey used for this signature and uses it to verify the checksums, everything is fine. The pubkey long fingerprint is noted on the main iso download page, not on the mirrors pages.
But the PGP signatures, to be secure, need a web of trust. A separate and trusted method to download and verify the keys themselves, and this we don't have.
Probably a certified page with all keys used by the project for signing downloads and builds.
$ LANG=C gpg --recv-key 0xB88B2FD43DBDC284 gpg: key 0xB88B2FD43DBDC284: "openSUSE Project Signing Key <opensuse@opensuse.org>" not changed gpg: Total number processed: 1 gpg: unchanged: 1 $ LANG=C gpg --list-sigs 0xB88B2FD43DBDC284 pub rsa2048/0xB88B2FD43DBDC284 2008-11-07 [expires: 2024-05-02] Key fingerprint = 22C0 7BA5 3417 8CD0 2EFE 22AA B88B 2FD4 3DBD C284 uid [ unknown] openSUSE Project Signing Key <opensuse@opensuse.org> sig 3 0xB88B2FD43DBDC284 2008-11-07 openSUSE Project Signing Key <opensuse@opensuse.org> sig 3 0xB88B2FD43DBDC284 2010-05-05 openSUSE Project Signing Key <opensuse@opensuse.org> sig 0xEA7BF3970175623E 2012-08-23 Marcus Meissner <meissner@suse.com> sig 0x77B2E6003D25D3D9 2012-08-23 [User ID not found] sig 0x8BD82E6F30B94B5C 2013-05-04 \xe6\xa5\x8a\xe5\xa3\xab\xe9\x9d\x92 (Yang Shih-Ching) <imacat@mail.imacat.idv.tw> sig 3 0xB88B2FD43DBDC284 2014-05-05 openSUSE Project Signing Key <opensuse@opensuse.org> sig 0x1C2B0DA2920E6F97 2013-08-15 [User ID not found] sig 0x080B3B0AD1E3EBDD 2014-02-11 Sebastian Weber <s.wbr@physik.uni-wuppertal.de> sig 0x37F0BE6297A01F40 2015-09-03 Eric Haberstroh <eric@erixpage.de> sig 0xE7820D7B72511999 2016-02-29 \xc5\x81ukasz Korpalski (Cyber Killer) <cyberkiller8@gmail.com> sig 0xA485A0ED51B8B7C4 2015-05-19 Andreas Boehlk (Privat-Post) <post@boehlk.com> $ So it is signed by me at least. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Aleksa Sarai wrote:
Given the recent case of Linux Mint, I went to double-check how we deal with distribution of checksums and images. It looks like we just distribute them all without TLS, which means there's no hardening against MITM attacks on users trying to download openSUSE. In addition, I couldn't find any mention of GPG signatures for the releases, so there's no web-of-trust way of verifying that an image I download is one that was signed by the key of the cheif maintainers.
Check https://software.opensuse.org, section "Verify your download before use". The sha256 check sum files are signed inline using GPG. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 29/02/16 20:02, Ludwig Nussel wrote:
Aleksa Sarai wrote:
Given the recent case of Linux Mint, I went to double-check how we deal with distribution of checksums and images. It looks like we just distribute them all without TLS, which means there's no hardening against MITM attacks on users trying to download openSUSE. In addition, I couldn't find any mention of GPG signatures for the releases, so there's no web-of-trust way of verifying that an image I download is one that was signed by the key of the cheif maintainers.
Check https://software.opensuse.org, section "Verify your download before use". The sha256 check sum files are signed inline using GPG.
While this might be true for Leap, this doesn't appear to be the case for Tumbleweed: http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-NET-x86_64-C... -- Aleksa Sarai Docker Core Specialist SUSE Australia https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Given the recent case of Linux Mint, I went to double-check how we deal with distribution of checksums and images. It looks like we just distribute them all without TLS, which means there's no hardening against MITM attacks on users trying to download openSUSE. In addition, I couldn't find any mention of GPG signatures for the releases, so there's no web-of-trust way of verifying that an image I download is one that was signed by the key of the cheif maintainers.
Check https://software.opensuse.org, section "Verify your download before use". The sha256 check sum files are signed inline using GPG.
While this might be true for Leap, this doesn't appear to be the case for Tumbleweed:
http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-NET-x86_64-C...
But weirdly, the following URL *does* have an inline-signed signature: http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-NET-x86_64-S... -- Aleksa Sarai Docker Core Specialist SUSE Australia https://www.cyphar.com/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Aleksa Sarai wrote:
On 29/02/16 20:02, Ludwig Nussel wrote:
Aleksa Sarai wrote:
Given the recent case of Linux Mint, I went to double-check how we deal with distribution of checksums and images. It looks like we just distribute them all without TLS, which means there's no hardening against MITM attacks on users trying to download openSUSE. In addition, I couldn't find any mention of GPG signatures for the releases, so there's no web-of-trust way of verifying that an image I download is one that was signed by the key of the cheif maintainers.
Check https://software.opensuse.org, section "Verify your download before use". The sha256 check sum files are signed inline using GPG.
While this might be true for Leap, this doesn't appear to be the case for Tumbleweed:
http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-NET-x86_64-C...
Interesting and unexpected :-) As you can see from the directory listing at http://download.opensuse.org/tumbleweed/iso/ the *-Current.iso.sha256 files don't actually exist. We only have .sha256 files for the files with the actual snapshot number in them. So I guess mirrorbrain generates the content when you request it. So I guess we need some clever redirect to the correct file there. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Ludwig Nussel wrote:
Aleksa Sarai wrote:
On 29/02/16 20:02, Ludwig Nussel wrote:
Aleksa Sarai wrote:
Given the recent case of Linux Mint, I went to double-check how we deal with distribution of checksums and images. It looks like we just distribute them all without TLS, which means there's no hardening against MITM attacks on users trying to download openSUSE. In addition, I couldn't find any mention of GPG signatures for the releases, so there's no web-of-trust way of verifying that an image I download is one that was signed by the key of the cheif maintainers.
Check https://software.opensuse.org, section "Verify your download before use". The sha256 check sum files are signed inline using GPG.
While this might be true for Leap, this doesn't appear to be the case for Tumbleweed:
http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-NET-x86_64-C...
Interesting and unexpected :-) As you can see from the directory listing at http://download.opensuse.org/tumbleweed/iso/ the *-Current.iso.sha256 files don't actually exist. We only have .sha256 files for the files with the actual snapshot number in them. So I guess mirrorbrain generates the content when you request it. So I guess we need some clever redirect to the correct file there.
Ok, that part is done. Mind updating the wiki with instructions on how to use gpg to verify the download? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 2016-02-29 15:02, Ludwig Nussel wrote:
Ok, that part is done. Mind updating the wiki with instructions on how to use gpg to verify the download?
The wiki should be offlimits or read only mode for everybody now, due to spam attack. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (8)
-
Aleksa Sarai -
Carlos E. R. -
Jon Brightwell -
Ludwig Nussel -
Marcus Meissner -
Sebastian -
Uzair Shamim -
Łukasz 'Cyber Killer' Korpalski