fallback to unsigned stream metadata may have security issues

[dann frazier]

When juju is fetching simple streams metadata for images and tools, it appears to look for a signed file (.sjson) first, and falls back to an unsigned one (.json). This process seems susceptible to man-in-the-middle attacks. An attacker could intercept juju's request for a .sjson file and return a 404, then return a malicious .json file on the fallback request.

Juju metadata could support signing of personal streams, and or users could configure Juju to accept a key they trust.

[dann frazier (dannf)]

For reference:
https://juju.ubuntu.com/docs/howto-privatecloud.html

"Metadata may be inline signed, or unsigned. We indicate a metadata file is signed by using the '.sjson' extension. Each location in the path is first searched for signed metadata, and if none is found, unsigned metadata is attempted before moving onto the next path location."

I verified this behavior by overridng the tools metadata url in a juju-core 1.19.2 release (in the source, tools-metadata-url in environments.yaml didn't seem to work), and provided only an unsigned .json file there. The debug output seems to confirm this behavior:

2014-05-16 17:27:39 DEBUG juju.environs.simplestreams simplestreams.go:388 fetchData failed for "http://people.canonical.com/~dannf/tools/streams/v1/index.sjson": cannot find URL "http://people.canonical.com/~dannf/tools/streams/v1/index.sjson" not found
2014-05-16 17:27:39 DEBUG juju.environs.simplestreams simplestreams.go:362 cannot load index "http://people.canonical.com/~dannf/tools/streams/v1/index.sjson": invalid URL "http://people.canonical.com/~dannf/tools/streams/v1/index.sjson" not found
2014-05-16 17:27:39 INFO juju.utils http.go:56 hostname SSL verification enabled
2014-05-16 17:27:39 INFO juju.utils http.go:56 hostname SSL verification enabled
2014-05-16 17:27:40 DEBUG juju.environs.simplestreams simplestreams.go:388 fetchData failed for "http://people.canonical.com/~dannf/tools/streams/v1/mirrors.json": cannot find URL "http://people.canonical.com/~dannf/tools/streams/v1/mirrors.json" not found
2014-05-16 17:27:40 DEBUG juju.environs.simplestreams simplestreams.go:465 no mirror index file found
2014-05-16 17:27:40 DEBUG juju.environs.simplestreams simplestreams.go:446 no mirror information available for {us-east-1 https://ec2.us-east-1.amazonaws.com}: mirror data for "com.ubuntu.juju:released:tools" not found
2014-05-16 17:27:40 DEBUG juju.environs.simplestreams simplestreams.go:366 read metadata index at "http://people.canonical.com/~dannf/tools/streams/v1/index.json"

[Curtis Hovey (sinzui)]

As juju only accepts one source for signing, even I, the publisher of our streams, cannot sign the streams. No human being can sign the streams. so we cannot address this until we have a means for a person or organisation to sign and juju to verify.

[dann frazier (dannf)]

On Fri, May 16, 2014 at 1:58 PM, Curtis Hovey <email address hidden> wrote:
> As juju only accepts one source for signing, even I, the publisher of
> our streams, cannot sign the streams. No human being can sign the
> streams. so we cannot address this until we have a means for a person or
> organisation to sign and juju to verify.

Yeah - personally I'd like to see a trusted keyring external to the juju binary
itself and a way to override the default keyring in my environments.yaml.
Or, in story form...

As an administrator of a private cloud I'd like to be able to create and sign
my own image/tool meatdata with my private key and have juju validate my
signature using a public keyring I provide.

[Curtis Hovey (sinzui)]

As users are frequently discussing the need for signed image and agent (tools) streams, but juju is hard coded to to accept a single key, I have made this issue public. Enterprises and public clouds often require data to be signed, and Juju does not allow them to do this.