[patch] more TLS configuration options for nnrpd
julien at trigofacile.com
Sun Nov 9 14:39:45 UTC 2014
> 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:
> What it does is to add a few options to inn.conf:
> - tlsprotocols: allows to select the SSL/TLS versions that are
> - 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")
> 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
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
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"
- 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
« Ils ont coulé mon entreprise. » (les pirates, dans _Astérix_)
More information about the inn-workers