[patch] more TLS configuration options for nnrpd

[Julien ÉLIE]

Hi Christian,

>> 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, 
Section 1:

    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 
LIST OVERVIEW.FMT.


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?

-- 
Julien ÉLIE

« Un myope qui lit sur les lèvres entend mieux s'il porte des
   lunettes. » (Philippe Geluck)