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. :-)
The http GET's include authentication tokens. So they are ssl
enabled to protect that info.
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.
Probably we need more options in the client-side configuration file (like,
download packages in plain HTTP instead of HTTPS).
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.
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
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.
Thanks! up2date-2.7.1-7.x.1 now supports this, with the new
useNoSSLForPackages=1 option in /etc/sysconfig/rhn/up2date.