[patch] more TLS configuration options for nnrpd
cm at tahina.priv.at
Mon Nov 10 23:05:16 UTC 2014
On Mon, Nov 10, 2014 at 03:21:42PM +0100, Julien ÉLIE wrote:
> Hi Christian,
> >I'll attach another iteration of the patch, against a clean 2.5.4 tree.
> Many thanks for this new patch.
> I will integrate it into INN and tell you when it has been committed.
> I would be inclined not to change existing system's behaviour
> for the next STABLE 2.5.5 release, and to enforce secure settings
> by default for CURRENT 2.6.0.
Yes, that seems like a good idea, see "principle of least surprise".
> I think I will integrate your patch this way in STABLE 2.5.5 and
> CURRENT 2.6.0; unless other
Yes, I'd really like to see this in the 2.5 series.
> I was concerned with the SASL security layer it can add (depending on
> the SASL mechanism used).
I leave that for Russ to answer.
> >b) ISTR that to allow ECDH, some setup of the openssl objects is
> > necessary; I'll also look into that.
> In case you find anything suspicious or are aware of any improvement
> that can be done, do not hesitate to tell us.
In fact, 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
Configuration-wise, this patch has yet another config entry
"tlseccurve", which takes the name of a curve OpenSSL knows about:
The name of the elliptic curve to use for ephemeral key exchanges.
To see the list of curves supported by OpenSSL, use C<openssl
The default is unset, which means an appropriate curve is
auto-selected (if your OpenSSL version supports it) or the NIST
P-256 curve is used.
This option is only effective if your OpenSSL version has ECDH
I think this provides for "works out of the box", and if you don't
want ECDH (say, you don't trust the NIST curves, which are all that's
available at the moment), you can turn it off by removing all traces
of ECDH from tlsciphers.
> >>- TLS server_name extension should be added to nnrpd.
> >I suppose this should tie in with the virtualhost stuff in
> >readers.conf, which I've never used myself. So if anybody wants to
> >guide me WRT integration into the wider scope of things, I'd be happy
> >to work on the TLS side of it.
> What information would nnrpd need to use this extension?
> When virtualhost is true, should we just have tlscertfile and tlskeyfile
> support in readers.conf to override the value of these two parameters
> from inn.conf, and then use these two values when negotiating a TLS
> session with a user matching an access block with virtualhost?
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.
That's the TLS part.
Like in HTTP, it would seem logical to then tie the virtualhost to the
server name -- but this is not HTTP, and I've got no idea how people
are using virtualhost functionality now, and what they'd like to do
> Do you know from your experience on that subject how that extension
> is used by other programs?
Only for web servers. Apache, with SNI, basically uses the
SNI-indicated name instead of the Host: header to select the
applicable <Virtualhost> section.
It's getting too late, I'll try and answer the remaining questions
Es ist jedenfalls VIEL besser als "Sie haben keinen Virus versandt und
hätten auch keinen erhalten, aber irgendwo in den Weiten des Internet
wurde eine mail gekillt, die zufällig ihre Adresse im From hatte."
-- Matthias Kahlert in aip
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 8136 bytes
Desc: not available
More information about the inn-workers