[Bug 1330770] Re: click packages rely upon tls for integrity and authenticity

[Colin Watson]

** Summary changed:

- Indications of Anxiety Disorder and Depression
+ click packages rely upon tls for integrity and authenticity

** Description changed:

  Hello, I just completed a quick review of the click source and the
  unity-scope-click source and behaviours, and found some opportunities
  for improvement.
- 
- https://usapillspharma.com/
  
  Debian, and Ubuntu, rely upon signed repository files with cryptographic
  hashes of packages to provide both integrity and authenticity checks for
  the packages hosted on that repository.
  
  The click framework and the unity-scope-click discovery and installation
  tool do not use signed repository files, nor do they have signatures of
  any sort on downloaded packages. The only integrity and authenticity
  checks are provided by the use of HTTPS.  The click verify command will
  check files within the archive against MD5sums stored inside the archive
  but the click verify command is not used during package installation.
  (This is suitable for validating integrity against accidental changes
  only.)
  
  While it appears that unity-scope-click properly uses HTTPS to download
  package metadata and packages, HTTPS alone is insufficient for our
  needs:
  
  - Someone in a position to create new certificates at any of several
  hundred certificate authorities could create certificates purporting to
  be our update servers. This actual problem has been discovered in the
  wild with several certificate authorities issuing wild-card certificates
  or even certificates with signing authority.
  
  - X.509 is extremely complicated; TLS is extremely complicated. Flaws in
  both are inevitable.
  
  - HTTPS prevents the use of caching.
  
  - HTTPS only 'works' for data-in-motion; it is useless for data-at-rest
  integrity and authenticity checks.
  
  I have not yet reviewed the tools that application authors will use to
  upload their packages to our distribution servers but note in passing
  that most of these issues are also issues for adding packages to our
  update servers -- packages in flight within our network can be corrupted
  for many reasons, packages on disk can be corrupted for many reasons. A
  signature mechanism can protect against internal network faults, storage
  faults, and provide assurance months or years later that an uploaded
  package was uploaded by someone in control of a corresponding private
  key.
  
  Thanks

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1330770

Title:
  click packages rely upon tls for integrity and authenticity

Status in Canonical System Image:
  Fix Released
Status in Click Package Index:
  Fix Released
Status in Software Center Agent:
  Fix Released
Status in click package in Ubuntu:
  Fix Released
Status in ubuntu-download-manager package in Ubuntu:
  Confirmed
Status in ubuntu-system-settings package in Ubuntu:
  Fix Released
Status in unity-scope-click package in Ubuntu:
  Fix Released
Status in ubuntu-download-manager source package in Vivid:
  New

Bug description:
  Hello, I just completed a quick review of the click source and the
  unity-scope-click source and behaviours, and found some opportunities
  for improvement.

  Debian, and Ubuntu, rely upon signed repository files with
  cryptographic hashes of packages to provide both integrity and
  authenticity checks for the packages hosted on that repository.

  The click framework and the unity-scope-click discovery and
  installation tool do not use signed repository files, nor do they have
  signatures of any sort on downloaded packages. The only integrity and
  authenticity checks are provided by the use of HTTPS.  The click
  verify command will check files within the archive against MD5sums
  stored inside the archive but the click verify command is not used
  during package installation. (This is suitable for validating
  integrity against accidental changes only.)

  While it appears that unity-scope-click properly uses HTTPS to
  download package metadata and packages, HTTPS alone is insufficient
  for our needs:

  - Someone in a position to create new certificates at any of several
  hundred certificate authorities could create certificates purporting
  to be our update servers. This actual problem has been discovered in
  the wild with several certificate authorities issuing wild-card
  certificates or even certificates with signing authority.

  - X.509 is extremely complicated; TLS is extremely complicated. Flaws
  in both are inevitable.

  - HTTPS prevents the use of caching.

  - HTTPS only 'works' for data-in-motion; it is useless for data-at-
  rest integrity and authenticity checks.

  I have not yet reviewed the tools that application authors will use to
  upload their packages to our distribution servers but note in passing
  that most of these issues are also issues for adding packages to our
  update servers -- packages in flight within our network can be
  corrupted for many reasons, packages on disk can be corrupted for many
  reasons. A signature mechanism can protect against internal network
  faults, storage faults, and provide assurance months or years later
  that an uploaded package was uploaded by someone in control of a
  corresponding private key.

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1330770/+subscriptions