[patch] more TLS configuration options for nnrpd
julien at trigofacile.com
Tue Nov 11 21:36:31 UTC 2014
>> The fact is that newer protocols aren't known by INN. We do not know
>> the name of the OpenSSL option to disable them. Consequently, newer
>> protocols are automatically enabled.
>> The new tlsprotocols keyword works this way: if "TLSv1.2" is in the
>> explicit list, INN sets the SSL_OP_NO_TLSv1_2 option for the TLS engine.
I wish to correct what I wrote in my previous mail (I believe you
corrected it when reading): if "TLSv1.2" is *not* in the explicit list,
INN sets the SSL_OP_NO_TLSv1_2 option for the TLS engine, to disable the
use of TLSv1.2.
>> INN does not know the "TLSv1.3", "TLSv2" or "XYZv1" protocol (none of
>> them currently exist) so these keywords are not recognized, and
>> therefore no option can be given to the TLS engine for them. So if INN
>> 2.5.5 is built with a future OpenSSL version knowing for instance
>> "TLSv1.3", this protocol will always be automatically enabled. There is
>> no possibility to disable it.
> Ah, okay. Then yeah, that paragraph sounds fine.
>> Wasn't my suggestion of paragraph clear enough about that? Or should we
>> change the behaviour of the new keyword?
> The paragraph was clear -- the behavior just wasn't intuitively what I'd
> expect, since I was assuming that the list was being passed to OpenSSL
> under the hood as the only acceptable ciphers. Now that you explain
> what's actually happening, it all makes sense.
This tlsprotocols keyword indeed differs from tlsciphers (a list of
ciphers given as-is to OpenSSL) and also tlseccurve (the name of a curve
to use, also given as-is to OpenSSL). I bet that's why you had the
assumption of a similar list for the protocols as well!
« Un myope qui lit sur les lèvres entend mieux s'il porte des
lunettes. » (Philippe Geluck)
More information about the inn-workers