From 2d24913830ba4dc9d886485354febf6bc598b912 Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Fri, 21 Jun 2013 10:06:56 +0200 Subject: doc: imrelp & omrelp improvements among others, fix doc done for wrong module... --- doc/imrelp.html | 17 +++++++++++++++++ doc/omrelp.html | 21 +++++++++++++++------ 2 files changed, 32 insertions(+), 6 deletions(-) diff --git a/doc/imrelp.html b/doc/imrelp.html index 73af2659..dfc1cadb 100644 --- a/doc/imrelp.html +++ b/doc/imrelp.html @@ -59,6 +59,23 @@ to changes/upgrades in GnuTLS (to check at config processing time, we would need to hardcode the supported bits and keep them in sync with GnuTLS - this is even impossible when custom GnuTLS changes are made...). +
  • tls.permittedPeer peer
    +Places access restrictions on this listener. Only peers which +have been listed in this parameter may connect. The validation +bases on the certificate the remote peer presents.
    +The peer parameter lists permitted certificate +fingerprints. Note that it is an array parameter, so either +a single or multiple fingerprints can be listed. When a +non-permitted peer connects, the refusal is logged together +with it's fingerprint. So if the administrator knows this was +a valid request, he can simple add the fingerprint by copy and +past from the logfile to rsyslog.conf. +
    To specify multiple fingerprints, just enclose them +in braces like this: +
    tls.permittedPeer=["SHA1:...1", "SHA1:....2"] +
    To specify just a single peer, you can either +specify the string directly or enclose it in braces. +
  • tls.prioritystring (not mandatory, string)
    This parameter permits to specify the so-called "priority string" to GnuTLS. This string gives complete control over all crypto parameters, diff --git a/doc/omrelp.html b/doc/omrelp.html index d01a1add..ecf9d1c3 100644 --- a/doc/omrelp.html +++ b/doc/omrelp.html @@ -43,16 +43,25 @@ must be used. typical text-based log records usually compress rather well.
  • tls.permittedPeer peer
    - Places access restrictions on this listener. Only peers which - have been listed in this parameter may connect. The validation - bases on the cerficate the remote peer presents.
    + Places access restrictions on this forwarder. Only peers which + have been listed in this parameter may be connected to. + This guards against rouge servers and man-in-the-middle + attacks. The validation + bases on the certficate the remote peer presents.
    The peer parameter lists permitted certificate fingerprints. Note that it is an array parameter, so either a single or multiple fingerprints can be listed. When a - non-permitted peer connects, the refusal is logged together - with it's fingerprint. So it the administrator knows this was + non-permitted peer is connected to, the refusal is logged together + with it's fingerprint. So if the administrator knows this was a valid request, he can simple add the fingerprint by copy and - past from the logfile to rsyslog.conf. + past from the logfile to rsyslog.conf. It must be noted, though, + that this situation should usually not happen after initial + client setup and administrators should be alert in this case. +
    Note that usually a single remote peer should be all that + is ever needed. Support for multiple peers is primarily included + in support of load balancing scenarios. If the connection + goes to a specific server, only one specific certificate is ever + expected (just like when connecting to a specific ssh server).
    To specify multiple fingerprints, just enclose them in braces like this:
    tls.permittedPeer=["SHA1:...1", "SHA1:....2"] -- cgit v1.2.3