Re: SoC: Improve syslogd

[Martin Schütte <lists%mschuette.name@localhost>]

Rainer Gerhards schrieb:
> connection, and if TLS fails
> > it falls back to UDP.
> I personally think this is dangerous, because a man in the middle can
> simply deny TLS and thus force the sender to use UDP  (btw: why not
> fall back to plain TCP in this case?) HOWEVER, user's will obviously
> love this option, and from an operations point of view it can make
> much sense.

The main goal here is to make it easy for users/admins to switch to TLS, 
without having to change their existing config files. The underlying 
assumption is that a TLS transport is always preferable to UDP, even 
without verified certificates.
Now that I think about it I see only one scenario where one relies on 
UDP-behaviour: that is if you use stealth logging (used in honeynets).

If you want to prevent a man-in-the-middle you have to invest some time 
and manage your x509 certificates (either using a CA or keeping a list 
of 'good' certs). Then you would configure syslogd to verify all 
certificates, and of course setting that option has to prevent any kind 
of insecure fallback.

> I have not yet decided how I will handle this for TLS. The current
> implementation requires TLS and does not allow fallback. I think about
> adding a user-configurable option to permit a fallback to non-TLS
> transfer. But does that make sense?

I am primarily influenced by stunnel here. It has a useful verify option 
to determine the extend of client/server authentication 
(http://www.stunnel.org/faq/certs.html#ToC12).

> syslog-transport-tls does not talk
> about this at all (maybe it should...).

It tries to set some requirements in Section "4.2.1. Server Identity"
but there are mainly hostname matching rules (I wonder if those are not 
already specified in some TLS standard).

Then there's:
4.2.3. Cryptographic Level
   Syslog applications SHOULD be implemented in a manner that permits
   administrators, as a matter of local policy, to select the
   cryptographic level and authentication options they desire.

One could argue if disabling authentication is a desirable 
"authentication option"  :-)

(Just for reference: 
http://tools.ietf.org/html/draft-ietf-syslog-transport-tls-11#section-4.2)

--
Martin