Bug 53252 - up2date should not use ssl for plain rpm downloads
Summary: up2date should not use ssl for plain rpm downloads
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date   
(Show other bugs)
Version: 4.0
Hardware: i386 Linux
Target Milestone: ---
: ---
Assignee: Adrian Likins
QA Contact: Jay Turner
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2001-09-05 15:58 UTC by Frank Ch. Eigler
Modified: 2015-01-07 23:51 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-09-05 18:31:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Frank Ch. Eigler 2001-09-05 15:58:33 UTC
up2date always uses SSL to fetch update RPMs. This defeats a possible
optimization installed by some sites such as ours, where the up2date
HTTP proxy is configured to point at a local caching proxy. If
up2date used SSL only for more sensitive data, and were to use plain
HTTP for actual RPMs, it would be possible to cache the RPMs at
intermediate proxies. This would significantly reduce the needed
network traffic if a network of up2date clients were downloading
similar sets of RPM updates.

Please consider it at least as an option.

Steps to Reproduce:
1. Set HTTP proxy for up2date to point to a squid cache.
2. Observe that only uncacheable SSL traffic passes through the cache.
3. Sigh at the waste of bandwidth. :-)

Comment 1 Adrian Likins 2001-09-05 17:19:53 UTC
The http GET's include authentication tokens. So they are ssl
enabled to protect that info.

Comment 2 Frank Ch. Eigler 2001-09-05 18:14:21 UTC
Good point.

Perhaps a option then would be to set a RHN account
preference such that update RPMs come from public
(==> unauthenticated) servers.

Or perhaps the up2date RPMs could be stored on the
priority server, again without authentication, but
in some time-dependent URL directory that allows
some reuse but makes non-RHN access unlikely.

Comment 3 Mihai Ibanescu 2001-09-05 18:20:24 UTC
Probably we need more options in the client-side configuration file (like,
download packages in plain HTTP instead of HTTPS).

Comment 4 Mihai Ibanescu 2001-09-05 18:26:32 UTC
About the authentication tokens: they expire after one hour, and they are only
used for package downloads. You cannot use the token to change passwords or
server profiles. So we should be concerned about privacy only when we come to
serve private packages. As long as we serve public packages I don't think that
someone intercepting the auth token could do a lot of damage. And for private
channels they could turn off the 'download over HTTP' switch, if they really care.

Comment 5 Adrian Likins 2001-09-05 18:31:25 UTC
yup, right on both accounts. planned for the next version.

The current auth tokens are actually time based, so for public packages
it's isnt a big deal. Worse case someone is allowed to download
 public packages from the rhn servers without being a subscriber for
an hour.

The concern is for third party/private channels where grabbing an auth
token would allow someone access to packages they are not authorised
to have at all. 

Adding an option to use http for package fetching wouldnt be difficult
I dont think, so might be something we can change. Depending on what
priority someone decideds on this as a bug.

Comment 6 Frank Ch. Eigler 2001-12-05 15:30:07 UTC
Thanks!  up2date-2.7.1-7.x.1 now supports this, with the new
useNoSSLForPackages=1 option in /etc/sysconfig/rhn/up2date.

Note You need to log in before you can comment on or make changes to this bug.