[patch] more TLS configuration options for nnrpd

christian mock cm at tahina.priv.at
Wed Nov 12 19:27:58 UTC 2014

OK, now to the remaining points:

On Mon, Nov 10, 2014 at 03:21:42PM +0100, Julien ÉLIE wrote:

> >>- AUTHINFO USER/PASS exposes the user's password to eavesdropping.
> >>According to RFC 4643:  "Any implementation of this command SHOULD
> >>be configurable to disable it whenever a strong encryption layer
> >>(such as that provided by [NNTP-TLS]) is not active, and this
> >>configuration SHOULD be the default.  The server will use the 483
> >>response code to indicate that the datastream is insufficiently
> >>secure for the command being attempted."
> >
> >I think that's already implemented, nnrpd.8:
> >
> >       If compiled against the TLS/SSL libraries, an auth group
> >with the
> >       require_ssl parameter set to true only applies if the incoming
> >       connection is using TLS, either from the beginning if the
> >-S flag was
> >       passed to nnrpd or after a successful use of STARTTLS.
> >
> >From skimming the code, it seems to be implemented this way.
> 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
> 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.

> 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.

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...

> 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, and the fact that
AFAICT nothing running on TLS does renegotiation (at least for key
renegotiation), so client code may not be well tested, I'd rather not
spend my time on this...


** christian mock in vienna, austria -- http://www.tahina.priv.at/
Inferring the workings of the US legal system from what's posted in
NANAE would be like trying to understand Europe by watching Monty
Python. -- Christopher H. in nanae

More information about the inn-workers mailing list