[patch] more TLS configuration options for nnrpd
julien at trigofacile.com
Thu Nov 13 20:22:08 UTC 2014
> 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
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
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?
« Ta vie ne tient qu'à un fil, Téléféric ! » (Astérix)
More information about the inn-workers