juju internal use of rsyslog should use ssl/tls for aggregation

[Kapil Thangavelu]

at the moment its just sending potentially all kinds of interesting data in clear text over the network. specifically in the maas context there are potentially attackers listening.

[Andrew Wilkins (axwalk)]

I've manually hacked up an environment by following the instructions at http://www.rsyslog.com/doc/rsyslog_secure_tls.html.

I got stuck for a long time because GnuTLS apparently won't run a server with the certs we generate for mongo. I'll have to dig into that, because we'll probably want to use a similar method to generate the certificates for rsyslogd.

[Andrew Wilkins (axwalk)]

Got to the bottom of it. Our code for generating certificates is wrong: we specify the certificate's x509 Key Usage as "data encipherment". This is wrong: TLS does not use certificates to encipher the data stream, it uses them to (a) prove identity, (b) encipher keys, and (b) perform key agreement/establishment. Later, symmetric encryption is used to encrypt the data stream.

The Key Usage should be: digital signature + key encipherment + key agreement. Alternatively, we can just use the serverAuth Extended Key Usage (which is what I'll change it to do).

[Andrew Wilkins (axwalk)]

There's a problem with rsyslog that prevents listening on privileged ports: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/789174

Thus, I have changed the default port to 6514. I'm not tackling upgrades at all yet, as that's going to require significantly more work. For one thing, we'll require a means of updating the port (syslog-port is expected to be immutable), and to enable syslog-tls (also expected to be immutable). It might be better just to have an agent worker that manages syslog configuration.

[Andrew Wilkins (axwalk)]

During code review the way rsyslog-gnutls gets installed changed, which will mean that we'll need to update the juju-local package to also include rsyslog-gnutls.