[opensuse-security] download.opensuse.org vs software.opensuse.org
Hi there, why does software.opensuse.org enjoy SSL, while download.opensuse.org doesn´t? best regards M -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Sun, Dec 18, 2016 at 05:29:04PM +0100, Malte Gell wrote:
Hi there,
why does software.opensuse.org enjoy SSL, while download.opensuse.org doesn´t?
software.opensuse.org is entirely hosted on our servers. download.opensuse.org is to a large degree only a redirector to our mirrors. I think that the core repodata that is always delivered from download.opensuse.org should probably be https served though. I will see if I get that implemented. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
Other than obedience to google, what purpose does encrypting open source linux distro binaries & source serve? https makes most content uncacheable, and I know I've saved 700MB in Suse disc images in my cache that wouldn't have been saved with https for most people. On top of that, https slows down transfer and raises latencies. Please reconsider whether https is really needed for "download" or "software". It's not like either is serving sensitive information and I really hate to see another sheep march to google's tune (when they want it to prevent you from selective ad filtering. Marcus Meissner wrote:
On Sun, Dec 18, 2016 at 05:29:04PM +0100, Malte Gell wrote:
Hi there,
why does software.opensuse.org enjoy SSL, while download.opensuse.org doesn�t?
download.opensuse.org so, Marcus
-- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On 12/18/2016 04:20 PM, L.A. Walsh wrote:
Other than obedience to google, what purpose does encrypting open source linux distro binaries & source serve?
https makes most content uncacheable, and I know I've saved 700MB in Suse disc images in my cache that wouldn't have been saved with https for most people. On top of that, https slows down transfer and raises latencies. Please reconsider whether https is really needed for "download" or "software". It's not like either is serving sensitive information and I really hate to see another sheep march to google's tune (when they want it to prevent you from selective ad filtering.
How about this one: I've been unable to update flash-player on several Leap 42.2 boxes for more than a week. Zypper/Yast2 trys to download flash-player-24.0.0.186-2.2.x86_64.rpm from pacman.inode.at, they get to 99%, then the connection is closed by the peer. I've resorted to locking the existing flash-player rpm so that I can complete the other updates. Since no one else is reporting similar issues, my latest hypothesis is that a deep-packet-inspection intrusion prevention device somewhere on my connection path is finding a false-positive hit in the binary and force-closing the connection. I've checked on our local IPS (Tippingpoint) and don't see any hits, but there might be others farther upstream. This is a very large organization. So if my hypothesis is correct, a TLS connection to pacman would allow the updates to complete. Regards, Lew -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On 12/18/2016 05:09 PM, Lew Wolfgang wrote:
On 12/18/2016 04:20 PM, L.A. Walsh wrote:
Other than obedience to google, what purpose does encrypting open source linux distro binaries & source serve?
https makes most content uncacheable, and I know I've saved 700MB in Suse disc images in my cache that wouldn't have been saved with https for most people. On top of that, https slows down transfer and raises latencies. Please reconsider whether https is really needed for "download" or "software". It's not like either is serving sensitive information and I really hate to see another sheep march to google's tune (when they want it to prevent you from selective ad filtering.
How about this one: I've been unable to update flash-player on several Leap 42.2 boxes for more than a week. Zypper/Yast2 trys to download flash-player-24.0.0.186-2.2.x86_64.rpm from pacman.inode.at, they get to 99%, then the connection is closed by the peer. I've resorted to locking the existing flash-player rpm so that I can complete the other updates.
Since no one else is reporting similar issues, my latest hypothesis is that a deep-packet-inspection intrusion prevention device somewhere on my connection path is finding a false-positive hit in the binary and force-closing the connection. I've checked on our local IPS (Tippingpoint) and don't see any hits, but there might be others farther upstream. This is a very large organization.
So if my hypothesis is correct, a TLS connection to pacman would allow the updates to complete.
BTW, I should have mentioned that I haven't had a chance to confirm my hypothesis with tcpdump yet, maybe I can get to that tomorrow. Regards, Lew -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-12-19 02:14, Lew Wolfgang wrote:
On 12/18/2016 05:09 PM, Lew Wolfgang wrote:
Since no one else is reporting similar issues, my latest hypothesis is that a deep-packet-inspection intrusion prevention device somewhere on my connection path is finding a false-positive hit in the binary and force-closing the connection. I've checked on our local IPS (Tippingpoint) and don't see any hits, but there might be others farther upstream. This is a very large organization.
So if my hypothesis is correct, a TLS connection to pacman would allow the updates to complete.
BTW, I should have mentioned that I haven't had a chance to confirm my hypothesis with tcpdump yet, maybe I can get to that tomorrow.
Try download the file manually with a browser. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlhXPUsACgkQja8UbcUWM1wWuQD/f5yxiR7j0ejJSlzEOL9KEKUs 777XrZ2drdUwHZNPwTABAJKvyPNYlUzh+AzE+QX4CinqlhpQTS+SoOv6K760zb12 =6A0L -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On 12/18/2016 05:52 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2016-12-19 02:14, Lew Wolfgang wrote:
On 12/18/2016 05:09 PM, Lew Wolfgang wrote:
Since no one else is reporting similar issues, my latest hypothesis is that a deep-packet-inspection intrusion prevention device somewhere on my connection path is finding a false-positive hit in the binary and force-closing the connection. I've checked on our local IPS (Tippingpoint) and don't see any hits, but there might be others farther upstream. This is a very large organization.
So if my hypothesis is correct, a TLS connection to pacman would allow the updates to complete. BTW, I should have mentioned that I haven't had a chance to confirm my hypothesis with tcpdump yet, maybe I can get to that tomorrow. Try download the file manually with a browser.
Good suggestion Carlos. I tried it with wget and got the same "connection closed by peer" disconnect at 99%. I then tried wget from my home system and it worked, of course. So I used scp to move the rpm to the hosts in question. Proves my point: maybe repo access should be via TLS, if caching proxies aren't an issue. Could both 80 and 443 be supported? Regards, Lew -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
Lew Wolfgang wrote:
Since no one else is reporting similar issues, my latest hypothesis is that a deep-packet-inspection intrusion prevention device somewhere on my connection path is finding a false-positive hit in the binary and force-closing the connection. I've checked on our local IPS (Tippingpoint) and don't see any hits, but there might be others farther upstream. This is a very large organization.
So if my hypothesis is correct, a TLS connection to pacman would allow the updates to complete.
Why would you think that? If it is a large corporation, some of them have already been noted to have subordinated root-certs that would allow them to perform MITM inspection. I.e. TLS wouldn't stop inspection. -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On 12/19/2016 11:26 AM, L A Walsh wrote:
Lew Wolfgang wrote:
Since no one else is reporting similar issues, my latest hypothesis is that a deep-packet-inspection intrusion prevention device somewhere on my connection path is finding a false-positive hit in the binary and force-closing the connection. I've checked on our local IPS (Tippingpoint) and don't see any hits, but there might be others farther upstream. This is a very large organization.
So if my hypothesis is correct, a TLS connection to pacman would allow the updates to complete.
Why would you think that? If it is a large corporation, some of them have already been noted to have subordinated root-certs that would allow them to perform MITM inspection. I.e. TLS wouldn't stop inspection.
In this case they don't do MITM inspection, so my hypothesis stands. TLS would enable me to do on-line updates, without it I have to sneaker-net in the rpm. Sure, it's a minor problem now that I understand what's happening, but it happened nevertheless, and it wasted hours of my time. Regards, Lew -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
Hi Linda, Others mentioned it, but the core reason here is integrity of the software you download. While once you have a repository added the GPG key is known and imported, the initial import of software repositories is tricky and needs to rely on some form of man in the middle protection. https is some form of solution here. Ciao, Marcus On Sun, Dec 18, 2016 at 04:20:23PM -0800, L.A. Walsh wrote:
Other than obedience to google, what purpose does encrypting open source linux distro binaries & source serve?
https makes most content uncacheable, and I know I've saved 700MB in Suse disc images in my cache that wouldn't have been saved with https for most people. On top of that, https slows down transfer and raises latencies.
Please reconsider whether https is really needed for "download" or "software". It's not like either is serving sensitive information and I really hate to see another sheep march to google's tune (when they want it to prevent you from selective ad filtering.
Marcus Meissner wrote:
On Sun, Dec 18, 2016 at 05:29:04PM +0100, Malte Gell wrote:
Hi there,
why does software.opensuse.org enjoy SSL, while download.opensuse.org doesn�t? download.opensuse.org so, Marcus
--
Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real
Marcus Meissner wrote:
While once you have a repository added the GPG key is known and imported, the initial import of software repositories is tricky and needs to rely on some form of man in the middle protection.
https is some form of solution here.
I've seen sites use https for "login" but http for bulk content. I've seen ssh patches that allow unencrypted transfer of bulk content (like using scp), but disallow unencrypted access for interactive sessions -- for exactly the same reason -- the encrypting of the connection noticeably slows down speeds with the difference being more noticeable the faster the connection gets. Though -- isn't it possible to offer *both* connection types -- staying with whatever protocol the user connects with? -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
Am 18.12.2016 um 20:08 schrieb Marcus Meissner:
(...) I think that the core repodata that is always delivered from download.opensuse.org should probably be https served though. I will see if I get that implemented.
Why not the whole stuff? As a distributor you are in a unique position. As we all know, (almost) all CAs are evil, you can´t trust them. You could install a self signed/made certificate and distribute it via Firefox update and ship it with the distribution! This way you save money and don´t depend on malicious CAs :-) You´d have a rock safe certificate. No bad CA being the man in the middle. best regards -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
Am 20.12.2016 um 14:41 schrieb Malte Gell:
Am 18.12.2016 um 20:08 schrieb Marcus Meissner:
(...) I think that the core repodata that is always delivered from download.opensuse.org should probably be https served though. I will see if I get that implemented.
Why not the whole stuff? As a distributor you are in a unique position. As we all know, (almost) all CAs are evil, you can´t trust them. You could install a self signed/made certificate and distribute it via Firefox update and ship it with the distribution! This way you save money and don´t depend on malicious CAs :-) You´d have a rock safe certificate. No bad CA being the man in the middle.
Yes and no. Not everyone uses SUSE products exclusively, and self-installed browsers will not know about the self-signed certificate. Additionally, everyone who wants to start using SUSE products will have to make an initial download without SUSE-modified software. Susan -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Tue, Dec 20, 2016 at 02:41:03PM +0100, Malte Gell wrote:
Am 18.12.2016 um 20:08 schrieb Marcus Meissner:
(...) I think that the core repodata that is always delivered from download.opensuse.org should probably be https served though. I will see if I get that implemented.
Why not the whole stuff? As a distributor you are in a unique position. As we all know, (almost) all CAs are evil, you can´t trust them. You could install a self signed/made certificate and distribute it via Firefox update and ship it with the distribution! This way you save money and don´t depend on malicious CAs :-) You´d have a rock safe certificate. No bad CA being the man in the middle.
The openSUSE mirror infrastructure is largely volunteer ftp sites all around the world, this rules out doing it all over https ;) For the SUSE Linux Enterprise products we pay to use a CDN that handles HTTPS with suse.com specific certificates. The good thing is that the YUM repodata is GPG integrity checked, when you get the correct key and repomd.xml, the rest is integrity checked with SHA256 signatures. Being a trustworthy CA itself is hard. Of course one could limit it to repository handling, then this would be easier... Ciao, Marcus -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
It all seems a bit strange to me. I’d ask what’s the threat you’re defending against? The signed RPMs mean they can’t be interfered with, so there’s only two other things: the metadata which describes the repository and the RPMs; and the requests you’re sending. Using HTTP for the RPMs allows the CDNs to be efficient, reducing the load on the servers. HTTPS prevents that for no benefit as most people get the downloads from a local mirror, which could be corrupted directly. There’s an argument for protecting the metadata from interference. I’m not paranoid enough to worry about someone knowing what software I have loaded on my machines, and there’s no indication in it of which machines have which software. So, what’s the problem / fear? Yours David p.s. for a self-signed CA, how do you securely distribute the root certificate to all the users everywhere in the world?-- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Tuesday 20 December 2016 3:24:47 P.M. GMT Marcus Meissner wrote:
The openSUSE mirror infrastructure is largely volunteer ftp sites all around the world, this rules out doing it all over https ;)
Hi Marcus, The thing which concerns me is the ISOs - there are good reasons to have the mirrors use HTTP, but the checksums used to check the integrity of the ISOs should be downloaded over HTTPS from a verified source, bandwidth requirement for this is very low. I am presuming that there is inbuilt trust for the official repo signatures - I don't recall ever being asked to accept a signing key except when adding a community or other unofficial repo - so all is good once the integrity of the ISO used to install the OS is guaranteed. We then know that updates and additional packages are signed with a trusted key, at least for officially supported packages. This has come up before :) ---------- Forwarded Message ---------- Subject: Re: [opensuse-security] Why no SSL for download.opensuse.org ? Date: Sunday 7 July 2013, 1:11:08 A.M. GMT From: eoinkirwan@eircom.net To: opensuse-security@opensuse.org On Sat 06 Jul 2013 10:34:45 Malte Gell wrote:
We have learned how much effort governments take to control and monitor the Internet. With this in regard, wouldn´t it make sense to switch download.opensuse.org to SSL? I know, rpm packages are signed with GnuPG, but if you add a new repo an attacker still is able to give you a forged GnuPG key and a forged repo, not the repo you actually tried to subscribe to. Thus, GnuPG signing of rpm does not prohibit man in the middle attacks. I think SSL for download.opensuse.org would give more safety to people living in authoritarian regimes who want to download openSUSE software.
Malte
The downloads themselves don't need to be SSL. Nobody should really trust a large download without a checksum or some other sort of error checking. Many people use torrents now anyway, and often they're more reliable. But the openSUSE web page with the checksums for the downloads should absolutely be SSL. This should be easy to do. Regards, Eoin -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
participants (9)
-
Administrator -
Carlos E. R. -
Eoin Kirwan -
L A Walsh -
L.A. Walsh
-
Lew Wolfgang -
Malte Gell -
Marcus Meissner -
Susan Dittmar