[patch] more TLS configuration options for nnrpd

Julien ÉLIE julien at trigofacile.com
Sun Nov 9 14:39:45 UTC 2014


Hi Christian,

> 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


> What it does is to add a few options to inn.conf:
>
> - tlsprotocols: allows to select the SSL/TLS versions that are
>    supported
>
> - tlsciphers: allows to give an OpenSSL cipher string to tailor the
>    cipher suites that are offered to clients
>
> - tlsprefer_server_ciphers: switches on the server-side selection of
>    the cipher suite (TLS default is "client choses")

Great!


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


> The patch is against 2.5.4, and I hope it holds up to your coding
> standards.

Yes, the coding style is fine.  Thanks again!
I will just adapt it for 2.6.0 because we unconditionally deactivated SSLv2.


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

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


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





As you are concerned about vulnerabilities, here is a list of several 
things that could be improved.  In case you wish to work on a few of 
them, do not hesitate to tell us :)
*Of course, no obligation!*

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

- TLS server_name extension should be added to nnrpd.

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



-- 
Julien ÉLIE

« Ils ont coulé mon entreprise. » (les pirates, dans _Astérix_)


More information about the inn-workers mailing list