[patch] more TLS configuration options for nnrpd

christian mock cm at tahina.priv.at
Fri Nov 14 08:39:47 UTC 2014

On Thu, Nov 13, 2014 at 09:22:08PM +0100, Julien ÉLIE wrote:

> One question after reading it:  why test
> #if !defined(OPENSSL_NO_EC) && defined(TLSEXT_ECPOINTFORMAT_uncompressed)
> to set HAVE_SSL_ECC?
> TLSEXT_ECPOINTFORMAT_uncompressed is not used afterwards.  Isn't
> OPENSSL_NO_EC enough?

This is stolen from apache -- the TLSEXT_ECPOINTFORMAT_uncompressed
would make sure your openssl version actually supports EC, and the
other one makes sure it's not been disabled.

> Getting back to tlsprotocols and tlsciphers, is there something to
> do with regards to RFC 4642?
>    Servers MUST be able to understand backwards-compatible TLS Client
>    Hello messages (provided that client_version is TLS 1.0 or later),
>    and clients MAY use backwards-compatible Client Hello messages.
>    Neither clients nor servers are required to actually support Client
>    Hello messages for anything other than TLS 1.0.
> => Does it mean that supporting TLS 1.0 is mandatory for a news
> server, or does the "Client Hello" stuff mean another thing?
> (Would supporting only TLS 1.2 be a complying behaviour?)

I am not sure what the authors intended with that paragraph, except to
force every compliant implementation to forever support TLSv1.0, and
supersede the RFC when something POODLE-like comes along for TLS 1.0.

Or, you can read it differently -- a server configured with only TLS
1.2 does in fact "support" a 1.0 client hello message, it's just that
it replies with a fatal alert "Protocol Version".

> I ask because we should add something about that subject in our
> documentation (to warn users that some keywords are required for
> interoperability - I wonder whether it is only TLSv1).

I think interoperability is something the admin has to decide, because
they know their user base and what clients they need to support.

>    NNTP client and server implementations MUST implement the
>    TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite and SHOULD implement the
>    TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite.  This is
>    important, as it assures that any two compliant implementations can
>    be configured to interoperate.  All other cipher suites are OPTIONAL.

In hindsight, that was short-sighted -- 8 years later, and MD5 is
considered broken, RC4 is frowned upon because it's got biases, DSS is
fixed to 1024 bit keys and 3DES is deprecated.

> => Same thing:  we should mention that.

Yes, probably. 

> Another possibility would be to unconditionally add them (but I
> believe just giving a warning in our documentation would be enough,
> don't you?).

I'm strongly against unconditionally adding those. Warnings are fine,
of course, I'd prefer wording them like "Formally, you are required
..." to make sure it's not taken too seriously.

> So the NNTP server just has to use the right certificate instead of
> always the same one specified in tlskeyfile/tlscertfile, hasn't it?


Being able to select a configuration group in readers.conf via SNI
would be nice -- you could have the same user name for different
identities and stuff. But that wouldn't work with plaintext
connections, so there's little practical benefit.

OK, since the weekend is coming up -- where should that be
configurable? I envision something like

snihost foo.example.com {
  tlscertfile: /bla/foo.pem
  tlskeyfile: /bla/foo.key

snihost bar.example.com {
  tlscertfile: /bla/bar.pem
  tlskeyfile: /bla/bar.key

which won't work in inn.conf, right? So would we move that to
readers.conf, or create a new config file?

I think the existing config values in inn.conf (tls*) should stay
there for backwards compatibility, and be the default values. snihost
blocks require tlscertfile and tlskeyfile and may have any of the
other tls* options, those default to the inn.conf values.

When a client sends an SNI that matches a snihost block, those values
are used, else the defaults.

Does that sound reasonable?


** christian mock in vienna, austria -- http://www.tahina.priv.at/
Metallica wasn't affected much, unsurprisingly.  You can play lots
of Metallica MP3s at the same time and it still sounds like
Metallica, only more so. -- Dave Brown

More information about the inn-workers mailing list