[CentOS-devel] Source code missing, and insecure delivery pages linked

Wed Feb 10 02:43:29 UTC 2021
Gordon Messmer <gordon.messmer at gmail.com>

On 2/8/21 10:09 PM, Chris Drake wrote:
> 1. Your info page here:
> links to an insecure download resource: 
> http://mirror.centos.org/centos/8-stream/
> ...
> take a look at the number of warnings related to unsigned code
> ...
> we really need to be able to download binaries ... preferably all with 
> working signatures, but that's a whole other problem, so TLS distro 
> endpoints is at least an interim mitigation


Generally speaking, TLS provides three things: privacy, authentication, 
and integrity.  For package installation, privacy isn't an essential 
component.  There's nothing secret in the package contents.  They're all 
publicly available.  TLS can authenticate the server, but it would fail 
to authenticate the origin of the software itself.  In short, it would 
authenticate the wrong thing.  You'd get integrity.  Nothing wrong with 
that, per se.

The package distribution network as it is does not provide privacy, as 
it is not an essential requirement.  It does, however, provide 
authentication and integrity by signing the package files themselves.  
This has the advantage that the origin (CentOS) is authenticated 
properly, as well as remaining friendly to caching proxy servers.

Running the package distribution network over https would lose the 
advantage of proxy friendliness, increase the costs placed on the mirror 
sites (you cited LetsEncrypt certificates, but are not considering the 
overhead of encrypting gigabit or 10-gigabit data channels), and 
duplicate characteristics already provided by signing the packages.

Additionally, I feel like insisting on HTTPS for the channel overlooks 
one of the most important considerations in the overall design of the 
package distribution network, and that is that the mirrors aren't 
actually trusted systems.  CentOS does not control them, and doesn't 
audit them for correctness.  If a mirror is compromised, and a bad 
package is served from one, HTTPS would do absolutely nothing to protect 
end users.  HTTPS would imply trust where none should be inferred.  The 
system must work over untrusted channels, which makes HTTPS an 
unnecessary and costly overhead.

I'm a little confused at your last point about working signatures.  You 
seem to understand that TLS wouldn't be adequate to the purpose of 
software signing, and it sounds like you're suggesting that the software 
isn't signed now.