(Note: technically you should read "TLS" everywhere I've written
"SSL".)
OK, I finally have SSL working. Some investigation into the background
of it reveals that in the forthcoming version 1.0 of AMQP, there is a
STARTTLS-style feature for the client and server to negotiate whether to
use SSL for a connection. See Book 5 of this document:
http://www.amqp.org/confluence/download/attachments/7340084/amqp-1.0.0+%2...
This is very much my preferred way of doing things. However, this is not
part of the current AMQP version 0.10 :( The spec also notes a reason
you may need a separate SSL port: a packet-inspecting firewall might see
the AMQP handshake and regard it as not being an SSL connection. (I can
think of another: you may want to configure blocking of non-secure
connections from a portion of the network using your firewall, rather
than through the application.)
Qpid does not support a way of running both SSL and non-SSL connections
on the same port. So it looks like we will indeed have to request a
separate SSL port from the IANA.
As for broker configuration, I suggest we add a MATAHARI_SSL_PORT
environment variable rather than require a ssl-port entry in the config
file. We would handle it the same way as the MATAHARI_PORT variable, so
that it defaults to our assigned port number (presumably 49001) rather
than 5671.
Client configuration will be trickier. At the moment it requires a bunch
of environment variables that the Qpid client library reads, but there
is no nice way of passing those. There was a request that we be able to
set the config file for the Qpid client library so that we could use
/etc/matahari-broker.conf to configure it, but that support is not yet
available. I am inclined to add CLI options to configure it.
That answers my basic SSL questions, but there is a whole other layer of
questions about our security model in general that I am unclear on:
Which users is Matahari targeted at?
a) Public cloud providers
b) Public cloud users
c) Private cloud users
d) All of the above
Where does the broker run?
a) On the same host as the agents
b) On the physical host with the agents in VMs
c) Some centralised location
d) All of the above
Which parts of the communication run on trusted networks (or locally)
and which on untrusted networks?
Who should be authorised to access the Matahari agents?
How do we set up the initial keys to enforce the access policies?
It would be good to document, say, the two or three most common
scenarios that we envision, so that we can optimise for simple
configuration in those cases. I think that would also be valuable in
communicating to potential users whether Matahari is for them.
cheers,
Zane,