Repository key fetching is insecure

[dann frazier]

This charm verifies an apt repository using a key it downloads via http. This is not a secure way to verify the repository. The point of signing the repository to begin with is because it is not possible to trust a site based on DNS resolution alone. If an attacker is going to go through the effort of poisoning your DNS to cause you to use a bogus repository, there's no reason that can't also sign that repository with a bogus key and return the corresponding public key in the key fetch process.

I'd suggest providing an independently-verified copy of elasticsearch's public key within the charm itself.

[Michael Nelson (michael.nelson)]

The charm verifies an apt repository using whatever key url you provide. The default that it provides is http because that was all that was available at the time [1], but great that they now provide https.

Or am I missing something? Does it not work if you provide an https uri? (I actually never use the default (external) repository for our internal deploys, using an internal repo we control instead).

Happy to update the default. Do you think it's worth providing the public key in the charm itself for the default repo (only)?

Thanks Dann.

[1] https://www.elastic.co/blog/apt-and-yum-repositories

[dann frazier (dannf)]

On Wed, Apr 29, 2015 at 11:10 PM, Michael Nelson
<email address hidden> wrote:
> The charm verifies an apt repository using whatever key url you provide.
> The default that it provides is http because that was all that was
> available at the time [1], but great that they now provide https.
>
> Or am I missing something? Does it not work if you provide an https uri?
> (I actually never use the default (external) repository for our internal
> deploys, using an internal repo we control instead).

I don't know of a reason https wouldn't work - assuming their signing
cert is in good order. Changing the default to use https might even be
an easy answer here.

> Happy to update the default. Do you think it's worth providing the
> public key in the charm itself for the default repo (only)?

+1. That would make it secure-by-default while still allowing users to
opt-in to less secure methods (or secure-by-other means, such as your
example of a local repo on a secure net).

  -dann

> Thanks Dann.
>
> [1] https://www.elastic.co/blog/apt-and-yum-repositories
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1449996
>
> Title:
> Repository key fetching is insecure
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/charms/+source/elasticsearch/+bug/1449996/+subscriptions