...
> > PROBLEM: right now all connections to the api server are secured with > > TLS and the client-cert. > > As John says, this isn't actually true - connections are secured with > a server cert and a password. > > Unfortunately I believe it is impossible to lose either one of these > without rendering juju fundamentally insecure against man-in-the-middle > attacks. > > If we take the approach you suggest, that's what we'd end up with. Anyone > that can subvert the network between the "juju connect" command and the > API server could pretend to be the desired environment, forwarding and > changing requests as maliciously as it liked. There's no way that the > client can know that it's talking to the middle-man, and no way for the > server to know that it's not being addressed by the expected client. > > There is also the problem that the "endpoint" can change - with HA the > actual API addresses can and will change (and there are many > possible addresses too - we try to connect to all of them; that's > not very convenient for a small piece of information to copy > and paste) > So we could certainly make it safe once you have securely connected 1 time. In that we can ask what the CA cert is for this environment, and then make sure all future connections are validated with that CA. I'm not going to make the convenience vs security call right now, though I will say being able to give someone a user@URL and have it work is more friendly than having to pass around a file. But probably not a huge difference. Especially if .jenv is a recognized extension so just "launching" the file ends up registering it with your local juju. John =:->
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
