Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: [patch] more TLS configuration options for nnrpd (Julien ?LIE)
2. Re: [patch] more TLS configuration options for nnrpd (Julien ?LIE)
3. Re: [patch] more TLS configuration options for nnrpd
(Russ Allbery)
4. Re: [patch] more TLS configuration options for nnrpd (Julien ?LIE)
5. Re: [patch] more TLS configuration options for nnrpd
(Russ Allbery)
6. Re: [patch] more TLS configuration options for nnrpd (Julien ?LIE)
7. Re: [patch] more TLS configuration options for nnrpd
(christian mock)
8. Re: [patch] more TLS configuration options for nnrpd (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Tue, 11 Nov 2014 15:08:27 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: [patch] more TLS configuration options for nnrpd
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Christian,
>> Many thanks for this new patch. I will integrate it into INN and
>> tell you when it has been committed.
>
> Great!
> Yes, I'd really like to see this in the 2.5 series.
Done for both 2.6.0:
https://inn.eyrie.org/trac/changeset/9744
and 2.5.5:
https://inn.eyrie.org/trac/changeset/9745
I have done several tests with the patch, and it works like a charm.
SSLv3 is now disabled on my news server, as I can see with:
openssl s_client -connect news.trigofacile.com:563 -ssl3
Feel free to have a look at the two commits.
The default value is all protocols, compression possible and client
decides the cipher for 2.5.5; only TLS protocols, without compression
and server decides the cipher for 2.6.0.
Note that no inn.conf parameter contains "_" so I used
tlspreferserverciphers instead of tlsprefer_server_ciphers.
I also used booleans instead of integers for the new parameters given to
tls_init_serverengine(), and size_t instead of int for positive variables.
Also, I wrote:
if (!tls_compression) {
#ifdef SSL_OP_NO_COMPRESSION
SSL_CTX_set_options(CTX, SSL_OP_NO_COMPRESSION);
#endif
}
instead of:
#ifdef SSL_OP_NO_COMPRESSION
if (!tls_compression) {
SSL_CTX_set_options(CTX, SSL_OP_NO_COMPRESSION);
}
#endif
because I otherwise had a gcc warning for an unused tls_compression
variable.
I also wrote:
if ((tls_protos & INN_TLS_TLSv1) == 0)
instead of:
if (!(tls_protos & INN_TLS_TLSv1))
for more clarity (the result is not a boolean).
I hope these changes are fine for you.
--
Julien ?LIE
? Confessio est regina probatio. ?
------------------------------
Message: 2
Date: Tue, 11 Nov 2014 19:03:22 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: [patch] more TLS configuration options for nnrpd
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Just an addition to my previous message: I believe we should reword the
documentation for tlsprotocols. It currently states:
The list of SSL/TLS protocol versions to support. Valid protocols are
B<SSLv2>, B<SSLv3>, B<TLSv1>, B<TLSv1.1> and B<TLSv1.2>. The default
value is to only allow TLS protocols:
tlsprotocols: [ TLSv1 TLSv1.1 TLSv1.2 ]
If TLSv1.3, TLSv2 or any other new protocol is provided by OpenSSL in
the future, and a version of INN that does not know such a protocol is
built with that new OpenSSL version, the documentation will be wrong
because the new protocol will be supported (as it cannot be disabled).
I suggest to add the following paragraph:
Note that the listed protocols will be enabled only if the OpenSSL
library INN has been built with supports them. In case OpenSSL
supports protocols more recent than TLSv1.2, they will be
automatically enabled (which anyway is fine regarding security, as
newer protocols are supposed to be more secure).
Does it sound good, or would you prefer another wording?
--
Julien ?LIE
? Confessio est regina probatio. ?
------------------------------
Message: 3
Date: Tue, 11 Nov 2014 11:42:27 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: [patch] more TLS configuration options for nnrpd
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> Just an addition to my previous message: I believe we should reword the
> documentation for tlsprotocols. It currently states:
> The list of SSL/TLS protocol versions to support. Valid protocols are
> B<SSLv2>, B<SSLv3>, B<TLSv1>, B<TLSv1.1> and B<TLSv1.2>. The default
> value is to only allow TLS protocols:
> tlsprotocols: [ TLSv1 TLSv1.1 TLSv1.2 ]
> If TLSv1.3, TLSv2 or any other new protocol is provided by OpenSSL in the
> future, and a version of INN that does not know such a protocol is built
> with that new OpenSSL version, the documentation will be wrong because the
> new protocol will be supported (as it cannot be disabled).
> I suggest to add the following paragraph:
> Note that the listed protocols will be enabled only if the OpenSSL
> library INN has been built with supports them. In case OpenSSL
> supports protocols more recent than TLSv1.2, they will be
> automatically enabled (which anyway is fine regarding security, as
> newer protocols are supposed to be more secure).
> Does it sound good, or would you prefer another wording?
Will they be automatically enabled if one gives this option with an
explicit list? (This may have already been in the other thread; if so,
apologies for missing it.)
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 4
Date: Tue, 11 Nov 2014 21:04:35 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: [patch] more TLS configuration options for nnrpd
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
>> I suggest to add the following paragraph:
>
>> Note that the listed protocols will be enabled only if the OpenSSL
>> library INN has been built with supports them. In case OpenSSL
>> supports protocols more recent than TLSv1.2, they will be
>> automatically enabled (which anyway is fine regarding security, as
>> newer protocols are supposed to be more secure).
>
>> Does it sound good, or would you prefer another wording?
>
> Will they be automatically enabled if one gives this option with an
> explicit list? (This may have already been in the other thread; if so,
> apologies for missing it.)
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.
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.
Wasn't my suggestion of paragraph clear enough about that?
Or should we change the behaviour of the new keyword?
--
Julien ?LIE
? Un myope qui lit sur les l?vres entend mieux s'il porte des
lunettes. ? (Philippe Geluck)
------------------------------
Message: 5
Date: Tue, 11 Nov 2014 12:52:34 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: [patch] more TLS configuration options for nnrpd
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> 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.
> 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.
--
Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<http://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 6
Date: Tue, 11 Nov 2014 22:36:31 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: [patch] more TLS configuration options for nnrpd
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
>> 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.
OK.
>> 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!
--
Julien ?LIE
? Un myope qui lit sur les l?vres entend mieux s'il porte des
lunettes. ? (Philippe Geluck)
------------------------------
Message: 7
Date: Wed, 12 Nov 2014 08:41:08 +0100
From: christian mock <[email protected]>
To: Julien ?LIE <[email protected]>
Cc: [email protected]
Subject: Re: [patch] more TLS configuration options for nnrpd
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Tue, Nov 11, 2014 at 09:04:35PM +0100, Julien ?LIE wrote:
> Wasn't my suggestion of paragraph clear enough about that?
I'm not sure, as I wrote the code and therefore know how it works :-)
> Or should we change the behaviour of the new keyword?
We could change the keyword to work like the code, that is,
to "tlsdisableprotocols". But to me that feels the wrong way 'round.
cm.
--
** christian mock in vienna, austria -- http://www.tahina.priv.at/
> Konzept Kunde/K?nig?
Ist deren Internet kaputt oder meines? Kann ich das wieder hinbiegen
oder die? -- Ralph Angenendt in dasr
------------------------------
Message: 8
Date: Wed, 12 Nov 2014 10:08:10 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: [patch] more TLS configuration options for nnrpd
Message-ID: <[email protected]>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Hi Christian,
>> Wasn't my suggestion of paragraph clear enough about that?
>
> I'm not sure, as I wrote the code and therefore know how it works :-)
>
>> Or should we change the behaviour of the new keyword?
>
> We could change the keyword to work like the code, that is,
> to "tlsdisableprotocols". But to me that feels the wrong way 'round.
I do not understand your remark.
With the current code, if we parameter
tlsprotocols: [ TLSv1.2 ]
and we use an OpenSSL version that supports TLSv1, TLSv1.1, TLSv1.2 and
TLSv1.3,
the protocols that will be available are TLSv1.2 and TLSv1.3 even though
the tlsprotocols parameter only mentions TLSv1.2.
The code will not disable TLSv1.3 as it does not know how to disable it.
So, why aren't you sure about the suggestion of wording?
The parameter does not exactly enable the list. Newer protocols are out
of scope
of the parameter.
--
Julien
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 66, Issue 4
******************************************
