[patch] more TLS configuration options for nnrpd

christian mock cm at tahina.priv.at
Sun Nov 9 22:18:18 UTC 2014


On Sun, Nov 09, 2014 at 03:39:45PM +0100, Julien ÉLIE wrote:

> >nnrpd's TLS support is basically using OpenSSL's defaults WRT issues
> >such as protocol support and cipher suites. In these days of POODLEs
> >and other vulnerabilities, I wanted to be able to have better control
> >over what's offered there, so I wrote this patch.
> 
> Thanks for this patch.  It has been hanging in my to-do list for a
> few years...  It answers (and even does more than) the need:
>     https://lists.isc.org/pipermail/inn-workers/2011-October/017952.html

Good to see it's not only my itch...

> >Additionally, TLS compression is turned off unconditionally (because
> >of the CRIME attack) if the OpenSSL version supports this.
> 
> Like Johan, I am a bit reluctant to deactivate it unconditionally.
> At least it could be configured with a tlscompression boolean value
> in inn.conf that a news admin could set according to his needs.

OK, so I'll just add that option. BTW, any comments on the defaults I
chose for the other options? (TLSv1.x, prefer server ciphers).

One could argue 

a) keep the settings as they were before, as to not change existing
   system's behaviour

b) let the defaults be secure (the definition I use here is the one
   from bettercrypto.org, where I'm a co-author)

> I for one prefer the advantage of compression against the
> possibility of a CRIME attack (especially on my news server that
> does not contain any confidential data to steal!).

My reason to hard-code it was that it is the only thing I changed
which (AFAIK) doesn't break compatiblity with clients -- and my habit
of turning it off everywhere and wanting to have a unified TLS config
for all services on my systems, whether the attacks are known to be
relevant to NNTP or not (see Russ' mail on the subject).

But the right thing is definitely to leave the option to the admin.

> I also believe it should be useful to log an error if a string is
> not recognized ("unknown SSLv4 protocol specified in tlsprotocols"
> for instance).

OK.

> Another thing:  aren't the "#define TLS_SSLv2" and like a possible
> conflict with name spacing of OpenSSL?  (INN_TLS_SSLv2 or
> INN_PROTOCOL_TLS_SSLv2 are maybe better)

OK.

> In the inn.conf sample, we should put "DEFAULT" (because it matches
> the default value, when the parameter is unset).

You mean the "tlsciphers" monster string in samples/inn.conf.in? Shall
I just leave it empty, which is the default, which in turn leads to
OpenSSL's default cipher list to be used?

> Isn't there something to do with SASL?  It can add security layers too...

I'm far from an expert in SASL, but nnrpd/sasl.c seems to only care
whether we have a TLS connection, how strong (in bits) the negotiated
cipher is, and what the client certificate CN is (if any).

So I don't think any code changes are necessary.

> - nnrpd currently uses precomputed ephemeral Diffie-Hellman keys.
> It should support user-specified files, to eliminate risk of "small
> group" attacks.

Frankly, that is not my first priority, as using well-chosen parameter
sets (such as those from IKE, as we recommend in the bettercrypto
paper after exhaustive discussion) may be safer than self-generated
ones. INN uses parameters from SKIP (as the comments indicate), so one
would have to do research about their quality.

Two interesting issues arise WRT DH parameters, however: 

a) I've seen that even with 3072 bit RSA keys, the negotiation is
   using the 1024 bit DH parameters -- I'll have a look into that.

b) ISTR that to allow ECDH, some setup of the openssl objects is
   necessary; I'll also look into that.

> - TLS server_name extension should be added to nnrpd.

I suppose this should tie in with the virtualhost stuff in
readers.conf, which I've never used myself. So if anybody wants to
guide me WRT integration into the wider scope of things, I'd be happy
to work on the TLS side of it.

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

Finally I'll attach another iteration of the patch, against a clean
2.5.4 tree.

cm.

-- 
** christian mock in vienna, austria -- http://www.tahina.priv.at/
** http://www.vibe.at/ ** http://quintessenz.org/ ** sig at foo.woas.net
If you really want a tape-based backup solution, use lots of duct tape
to package up IDE hard-drives to keep them safe offsite. -- AdB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inn-2.5.4-sslconf-v2.patch
Type: text/x-diff
Size: 8599 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20141109/5f558a5b/attachment-0001.bin>


More information about the inn-workers mailing list