[patch] more TLS configuration options for nnrpd

Julien ÉLIE julien at trigofacile.com
Thu Nov 13 20:22:08 UTC 2014

Hi Christian,

> I have got ECDH support implemented. I'll attach a patch that
> goes on top of the first one, and would very much like people to
> critique this and test it, because the OpenSSL docs are less than
> helpful and I had to resort to reverse engineer the apache source.
> Consider it experimental -- not "crashing your server", but "may be
> insecure".

I'll have a look, thanks for the patch.
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 

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

    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.

=> Same thing:  we should mention that.
Another possibility would be to unconditionally add them (but I believe 
just giving a warning in our documentation would be enough, don't you?).

>> - TLS server_name extension should be added to nnrpd.
> So today the virtualhost is selected based on the user? That's too
> late for SNI.
> With SNI, the client tells the server in the TLS handshake what name
> it wants to reach, akin to the "Host" header in HTTP.
> Then, the respective cert/key pair has to be used for TLS setup.

It therefore looks as though SNI were not related to the concept of 
nnrpd's virtualhosts.  It is indeed something different than Apache's 

RFC 4642:

    The TLS
    extension for Server Name Indication ("server_name") [TLS-EXT] SHOULD
    be implemented by all clients; it also SHOULD be implemented by any
    server implementing STARTTLS that is known by multiple names.
    (Otherwise, it is not possible for a server with several hostnames to
    present the correct certificate to the client.)

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

Julien ÉLIE

« Ta vie ne tient qu'à un fil, Téléféric ! » (Astérix)

More information about the inn-workers mailing list