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
(christian mock)
2. TLS, DH parameters (christian mock)
3. Re: [patch] more TLS configuration options for nnrpd
(christian mock)
4. Re: [patch] more TLS configuration options for nnrpd
(christian mock)
5. Re: [patch] more TLS configuration options for nnrpd (Julien ?LIE)
6. Re: [patch] more TLS configuration options for nnrpd (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Wed, 12 Nov 2014 16:41:08 +0100
From: christian mock <[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
On Wed, Nov 12, 2014 at 10:08:10AM +0100, Julien ?LIE wrote:
> >>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.
What I meant: the code selectively disables known protocols. So if we
changed the keywork to work in reverse from what it is now, we could
say
tlsdisableprotocols: Allows to disable certain known TLS protocol
versions. Known versions: SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2
so in your example I'd configure
tlsdisableprotocols: [ SSLv2 SSLv3 TLSv1 TLSv1.1 ]
and it would result in TLSv1.2 and TLSv1.3 being enabled in your
example. Adding "TLSv1.3" to the config line would result in an error
message.
But, again, to me that feels "backwards".
> The parameter does not exactly enable the list. Newer protocols are
> out of scope
> of the parameter.
Right.
--
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
------------------------------
Message: 2
Date: Wed, 12 Nov 2014 20:10:53 +0100
From: christian mock <[email protected]>
To: [email protected]
Subject: TLS, DH parameters
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
As said previously, I found that even with a 3072 bit RSA key, nnrpd
only offers up 1024 bit DH parameters for Diffie-Hellman negotiation.
Given that the current recommendation for RSA keys is at least 2048
bits, and that the DH key should be of the same size (or it becomes
the weakest link), this is bad.
I now found the reason: nnrpd/tls.c tries, in tmp_dh_cb, to load or
generate DH parameters of the size of the parameter "keylength". The
author probably assumed from the openssl documentation (as I did) that
this "keylength" is in fact the length of the RSA private key.
But it turns out it is not -- deep in the guts of the openssl code one
finds that this parameter can only ever be 512 or 1024, depending on
whether an "export" cipher is negotiated or not. Why there's an
additional "export" parameter to the callback is anyone's guess.
Coding a fix for this would be easy. Deciding on how it should look
like probably not, because compatibility.
Java versions up to 1.6 or 1.7 are said to have problems with DH keys
> 1024 bits. Some firefox (and thunderbird?) versions may have
problems with keys > 2048 bits. Other libraries and clients are
anyone's guess.
>From a technical POV, my idea of a solution would be:
a) compile in a list of known-good DH params of various sizes (the IKE
DH groups, RFC3526, plus for 512 bit the current SKIP group)
b) select the smallest group >= RSA key size
c) use the chosen group (or the 512-bit one for export ciphers)
d) allow the administrator to configure a file to load his preferred DH
params from, overriding b).
The problem I see with this is that the unwitting administrator, on
upgrade, will have his users complain about mysterious connection
failures that will be very hard to debug, and, given the miserable
quality of user interfaces, impossible to distinguish from any other
cause of connection failures.
The backward-compatible solution would be to leave it like it is and
just provide the option to load your own parameters (d above). No
surprises, and one can still configure stronger parameters.
cm.
--
Hat irgendwer schlechte Schwingungen in seiner globalen
Eierkuchen-Aura bekommen weil man ihm gesagt hat er soll bitte nicht
andauernd mit Vollquotes in 10 Gruppen gleichzeitig crossposten?
Albert Koellner in at.usenet
------------------------------
Message: 3
Date: Wed, 12 Nov 2014 20:27:58 +0100
From: christian mock <[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
OK, now to the remaining points:
On Mon, Nov 10, 2014 at 03:21:42PM +0100, Julien ?LIE wrote:
> >>- AUTHINFO USER/PASS exposes the user's password to eavesdropping.
> >>According to RFC 4643: "Any implementation of this command SHOULD
> >>be configurable to disable it whenever a strong encryption layer
> >>(such as that provided by [NNTP-TLS]) is not active, and this
> >>configuration SHOULD be the default. The server will use the 483
> >>response code to indicate that the datastream is insufficiently
> >>secure for the command being attempted."
> >
> >I think that's already implemented, nnrpd.8:
> >
> > If compiled against the TLS/SSL libraries, an auth group
> >with the
> > require_ssl parameter set to true only applies if the incoming
> > connection is using TLS, either from the beginning if the
> >-S flag was
> > passed to nnrpd or after a successful use of STARTTLS.
> >
> >From skimming the code, it seems to be implemented this way.
>
> The case here is when you connect to nnrpd on port 119 (without any
> security layer). Then you will still see "AUTHINFO USER SASL" in
> response
> to CAPABILITIES; and using AUTHINFO USER or AUTHINFO SASL with an
> unsecure
> mechanism will still be allowed (PLAIN, LOGIN and EXTERNAL are the 3
> hard-coded
> mechanisms in INN to disallow).
I see -- when it's not compiled with SSL, it skips the check.
> Looking at the code, it seems that just preventing to set
> PERMcanauthenticatewithoutSSL to true in nnrpd/perm.c when the news
> admin wants to enforce that configuration would do the trick,
> wouldn't it?
Removing all the "#ifdef HAVE_SSL" around the usage of
PERMcanauthenticatewithoutSSL would be my choice, because
nnrpd_starttls_done should never be true in that case.
But it leads us back to compatibility -- people running
non-TLS-compiled nnrpds will not have "require_ssl: false" in their
readers.conf and auth will break...
> Another thing I see in TODO is: "when using SSL, track the amount
> of data that's been transferred to the client and periodically
> renegotiate the session key."
> Is it a recommended practice in bettercrypto too?
No, we haven't discussed that WRT TLS. But I've seen and used it in
IPSEC and OpenVPN VPNs, where it is common practice.
Given the poor quality of OpenSSL's documentation, and the fact that
AFAICT nothing running on TLS does renegotiation (at least for key
renegotiation), so client code may not be well tested, I'd rather not
spend my time on this...
cm.
--
** christian mock in vienna, austria -- http://www.tahina.priv.at/
Inferring the workings of the US legal system from what's posted in
NANAE would be like trying to understand Europe by watching Monty
Python. -- Christopher H. in nanae
------------------------------
Message: 4
Date: Wed, 12 Nov 2014 20:32:54 +0100
From: christian mock <[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
On Tue, Nov 11, 2014 at 03:08:27PM +0100, Julien ?LIE wrote:
> Done for both 2.6.0:
> https://inn.eyrie.org/trac/changeset/9744
> and 2.5.5:
> https://inn.eyrie.org/trac/changeset/9745
Wow, great. I think I've been running INN for 20 years, and this is my
first contribution to it.
> I hope these changes are fine for you.
Yes, great!
cm.
--
** christian mock in vienna, austria -- http://www.tahina.priv.at/
...the [APL] Execution Environment (makes me think about sunny walls,
indifferent marksmen, and the offer of a blindfold and a cigarette)...
-- Mike Andrews
------------------------------
Message: 5
Date: Wed, 12 Nov 2014 21:53:00 +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,
>> The case here is when you connect to nnrpd on port 119 (without
>> any security layer). Then you will still see "AUTHINFO USER SASL"
>> in response to CAPABILITIES; and using AUTHINFO USER or AUTHINFO
>> SASL with an unsecure mechanism will still be allowed (PLAIN, LOGIN
>> and EXTERNAL are the 3 hard-coded mechanisms in INN to disallow).
>
> I see -- when it's not compiled with SSL, it skips the check.
When not built with SSL, it indeed skips the check but not only in that
case. We can also have an SSL-aware INN that is accessed via port 119.
Note that this is considered as best practice according to RFC 4642,
Section 1:
The TLS protocol (formerly known as SSL) provides a way to secure an
application protocol from tampering and eavesdropping. Although
advanced SASL authentication mechanisms [NNTP-AUTH] can provide a
lightweight version of this service, TLS is complementary to both
simple authentication-only SASL mechanisms and deployed clear-text
password login commands.
In some existing implementations, TCP port 563 has been dedicated to
NNTP over TLS. These implementations begin the TLS negotiation
immediately upon connection and then continue with the initial steps
of an NNTP session. This use of TLS on a separate port is
discouraged for the reasons documented in Section 7 of "Using TLS
with IMAP, POP3 and ACAP" [TLS-IMAPPOP].
This specification formalizes the STARTTLS command already in
occasional use by the installed base. The STARTTLS command rectifies
a number of the problems with using a separate port for a "secure"
protocol variant; it is the preferred way of using TLS with NNTP.
>> Looking at the code, it seems that just preventing to set
>> PERMcanauthenticatewithoutSSL to true in nnrpd/perm.c when the news
>> admin wants to enforce that configuration would do the trick,
>> wouldn't it?
>
> Removing all the "#ifdef HAVE_SSL" around the usage of
> PERMcanauthenticatewithoutSSL would be my choice, because
> nnrpd_starttls_done should never be true in that case.
Removing these "#ifdef HAVE_SSL" is not enough because of the
possibility to have readers.conf auth groups without require_ssl. It
should be done in conjunction with PERMcanauthenticatewithoutSSL.
> But it leads us back to compatibility -- people running
> non-TLS-compiled nnrpds will not have "require_ssl: false" in their
> readers.conf and auth will break...
That's why it should be configurable by the admin (whether to comply
with the SHOULD of RFC 4643).
By the way, reading again RFC 4643, I find:
Implementations MUST support a configuration where authentication
mechanisms that are vulnerable to passive eavesdropping attacks (such
as AUTHINFO USER/PASS and SASL [PLAIN]) are not advertised or used
without the presence of an external security layer such as TLS
[NNTP-TLS], and this configuration SHOULD be the default.
Thanks to the idea of your last patch for SSL/TLS protocols, I believe
the above paragraph can be implemented in a similar way, instead of the
hard-coded PLAIN, LOGIN, and EXTERNAL keywords in the sasl code.
It would here really be a "disabling" feature!
I did not do that when I implemented in 2008 the latest NNTP RFCs in INN
because vectors have been recognized in inn.conf since only 2009, when I
added them to configure the list of headers that should be advertised in
LIST OVERVIEW.FMT.
And I also came accross an interesting feature too:
Servers MAY implement a policy whereby the connection is dropped
after a number of failed authentication attempts. If they do so,
they SHOULD NOT drop the connection until at least 3 attempts at
authentication have failed.
Apart for these remaining points, the whole RFC 4643 is implemented in
INN. So, that's already pretty good, and the remaining is feasible
within a reasonable amount of work. I shall have a look for the next
INN release, unless you are interested in working on that (no
obligation, it's something I can do; better concentrate yourself on
TLS-related subtleties that I admit not to know).
>> Another thing I see in TODO is: "when using SSL, track the amount
>> of data that's been transferred to the client and periodically
>> renegotiate the session key."
>> Is it a recommended practice in bettercrypto too?
>
> No, we haven't discussed that WRT TLS. But I've seen and used it in
> IPSEC and OpenVPN VPNs, where it is common practice.
>
> Given the poor quality of OpenSSL's documentation
Is GnuTLS better documented?
--
Julien ?LIE
? Un myope qui lit sur les l?vres entend mieux s'il porte des
lunettes. ? (Philippe Geluck)
------------------------------
Message: 6
Date: Wed, 12 Nov 2014 21:53:04 +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,
> Wow, great. I think I've been running INN for 20 years, and this is my
> first contribution to it.
Searching your name in <https://inn.eyrie.org/> gives a few results :)
Even a new script (contrib/delayer.in). By the way, if you have any
update to this script, or other scripts to contribute, feel free to post
them here.
--
Julien ?LIE
? Un myope qui lit sur les l?vres entend mieux s'il porte des
lunettes. ? (Philippe Geluck)
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 66, Issue 5
******************************************
