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.
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.
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 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.
Thanks! up2date-2.7.1-7.x.1 now supports this, with the new useNoSSLForPackages=1 option in /etc/sysconfig/rhn/up2date.