Bug 53252

Summary:	up2date should not use ssl for plain rpm downloads
Product:	Red Hat Enterprise Linux 4	Reporter:	Frank Ch. Eigler <fche>
Component:	up2date	Assignee:	Adrian Likins <alikins>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Jay Turner <jturner>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.0	CC:	cturner, gafton, mihai.ibanescu, pjones, srevivo, taw
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-09-05 18:31:29 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.