Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Download release checksums via trusted connection #43

Closed
2 of 5 tasks
gronke opened this issue Aug 29, 2017 · 8 comments
Closed
2 of 5 tasks

Download release checksums via trusted connection #43

gronke opened this issue Aug 29, 2017 · 8 comments

Comments

@gronke
Copy link
Member

gronke commented Aug 29, 2017

The manifest containing the release asset signatures is downloaded from the same untrusted http resource as the assets. To be an effective security feature we need to verify this signatures from trusted sources.

  • downloads Hardened BSD signatures via encrypted connection
  • downloads FreeBSD signatures via encrypted connection
  • allows to specify a custom signature source

CLI

  • allows the user to skip verification (currently --verify/--no-verify option
  • allows to manually specify signatures (e.g. --signatures base=62acaee7e... or similar)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@igalic
Copy link
Collaborator

igalic commented Aug 30, 2017

is there a specific reason the images aren't downloaded https to begin with?

@gronke gronke changed the title Check signatures via trusted connection Download release checksums via trusted connection Aug 30, 2017
@gronke
Copy link
Member Author

gronke commented Sep 2, 2017

FreeBSD must have recently enabled encryption on download.freebsd.org - I can't remember this to be there when I started working on fetch! For HardenedBSD I can't find encrypted resources at this time.

@igalic
Copy link
Collaborator

igalic commented Sep 2, 2017

not very hardened, imo then 😝

@gronke
Copy link
Member Author

gronke commented Sep 2, 2017

I would not consider downloading from https very secure either. It's just protecting against the simplest network attacks to compromise downloaded releases. (Btw. we do have checks of downloaded assets so that they do not compromise the host)

I would prefer to ship libiocage with a signed set of release hashes. They don't change that often and in case there is an unknown one, we can offer manual input and print a link to our issue tracker with a text snippet ready to copy/paste. We can even setup monitoring that watches MANIFEST files on the release servers for changes.

@gronke
Copy link
Member Author

gronke commented Sep 16, 2017

In irc.freenode.net #hardehedbsd @xmj mentioned we should look at the way hbsd-update update verifies the signatures.

unbound-host gave me some result, but I could not find a way to verify the txz assets from such keys. Here's an example from a test host:

# unbound-host -v -t txt -r "$(uname -m).master.11-stable.hardened.hardenedbsd.updates.hardenedbsd.org" 
amd64.master.11-stable.hardened.hardenedbsd.updates.hardenedbsd.org has TXT record "1505101784|hbsd-v1100049-548eb60819e04c5d06671a95f5a7082e194fb7d4|sha256:398c7c76884c951ba8feb3862557b1caa104b96dd2415b31e16cee48140c1ec2" (insecure)

Another thin I've noticed is the MANIFEST.asc file among the build assets. We could use that to verify the signatures file for HardenedBSD.

No progress on FreeBSD signature verification yet.

@gronke
Copy link
Member Author

gronke commented Sep 24, 2017

With #112 (f31745f) we switched the FreeBSD mirror to an encrypted resource. HardenedBSD still outstanding.

@gronke
Copy link
Member Author

gronke commented Feb 24, 2018

In the meanwhile HardenedBSD assets are also fetched via encrypted connection. Manual specification of hashes is still outstanding.

@gronke
Copy link
Member Author

gronke commented Aug 9, 2018

Releases are entirely downloaded and updated involving the trust chain and signatures obtained via HTTPS. There is still need to manually override signatures and to skip verification at all, but it is a different concern than this issue aimed to be.

@gronke gronke closed this as completed Aug 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants