[patch] more TLS configuration options for nnrpd
julien at trigofacile.com
Wed Nov 12 20:53:00 UTC 2014
>> The case here is when you connect to nnrpd on port 119 (without
>> any security layer). Then you will still see "AUTHINFO USER SASL"
>> in response to CAPABILITIES; and using AUTHINFO USER or AUTHINFO
>> SASL with an unsecure mechanism will still be allowed (PLAIN, LOGIN
>> and EXTERNAL are the 3 hard-coded mechanisms in INN to disallow).
> I see -- when it's not compiled with SSL, it skips the check.
When not built with SSL, it indeed skips the check but not only in that
case. We can also have an SSL-aware INN that is accessed via port 119.
Note that this is considered as best practice according to RFC 4642,
The TLS protocol (formerly known as SSL) provides a way to secure an
application protocol from tampering and eavesdropping. Although
advanced SASL authentication mechanisms [NNTP-AUTH] can provide a
lightweight version of this service, TLS is complementary to both
simple authentication-only SASL mechanisms and deployed clear-text
password login commands.
In some existing implementations, TCP port 563 has been dedicated to
NNTP over TLS. These implementations begin the TLS negotiation
immediately upon connection and then continue with the initial steps
of an NNTP session. This use of TLS on a separate port is
discouraged for the reasons documented in Section 7 of "Using TLS
with IMAP, POP3 and ACAP" [TLS-IMAPPOP].
This specification formalizes the STARTTLS command already in
occasional use by the installed base. The STARTTLS command rectifies
a number of the problems with using a separate port for a "secure"
protocol variant; it is the preferred way of using TLS with NNTP.
>> Looking at the code, it seems that just preventing to set
>> PERMcanauthenticatewithoutSSL to true in nnrpd/perm.c when the news
>> admin wants to enforce that configuration would do the trick,
>> wouldn't it?
> Removing all the "#ifdef HAVE_SSL" around the usage of
> PERMcanauthenticatewithoutSSL would be my choice, because
> nnrpd_starttls_done should never be true in that case.
Removing these "#ifdef HAVE_SSL" is not enough because of the
possibility to have readers.conf auth groups without require_ssl. It
should be done in conjunction with PERMcanauthenticatewithoutSSL.
> But it leads us back to compatibility -- people running
> non-TLS-compiled nnrpds will not have "require_ssl: false" in their
> readers.conf and auth will break...
That's why it should be configurable by the admin (whether to comply
with the SHOULD of RFC 4643).
By the way, reading again RFC 4643, I find:
Implementations MUST support a configuration where authentication
mechanisms that are vulnerable to passive eavesdropping attacks (such
as AUTHINFO USER/PASS and SASL [PLAIN]) are not advertised or used
without the presence of an external security layer such as TLS
[NNTP-TLS], and this configuration SHOULD be the default.
Thanks to the idea of your last patch for SSL/TLS protocols, I believe
the above paragraph can be implemented in a similar way, instead of the
hard-coded PLAIN, LOGIN, and EXTERNAL keywords in the sasl code.
It would here really be a "disabling" feature!
I did not do that when I implemented in 2008 the latest NNTP RFCs in INN
because vectors have been recognized in inn.conf since only 2009, when I
added them to configure the list of headers that should be advertised in
And I also came accross an interesting feature too:
Servers MAY implement a policy whereby the connection is dropped
after a number of failed authentication attempts. If they do so,
they SHOULD NOT drop the connection until at least 3 attempts at
authentication have failed.
Apart for these remaining points, the whole RFC 4643 is implemented in
INN. So, that's already pretty good, and the remaining is feasible
within a reasonable amount of work. I shall have a look for the next
INN release, unless you are interested in working on that (no
obligation, it's something I can do; better concentrate yourself on
TLS-related subtleties that I admit not to know).
>> Another thing I see in TODO is: "when using SSL, track the amount
>> of data that's been transferred to the client and periodically
>> renegotiate the session key."
>> Is it a recommended practice in bettercrypto too?
> No, we haven't discussed that WRT TLS. But I've seen and used it in
> IPSEC and OpenVPN VPNs, where it is common practice.
> Given the poor quality of OpenSSL's documentation
Is GnuTLS better documented?
« Un myope qui lit sur les lèvres entend mieux s'il porte des
lunettes. » (Philippe Geluck)
More information about the inn-workers