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. New posting-account attribute in Injection-Info for CURRENT
(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
(christian mock)
----------------------------------------------------------------------
Message: 1
Date: Sun, 09 Nov 2014 15:39:45 +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,
> nnrpd's TLS support is basically using OpenSSL's defaults WRT issues
> such as protocol support and cipher suites. In these days of POODLEs
> and other vulnerabilities, I wanted to be able to have better control
> over what's offered there, so I wrote this patch.
Thanks for this patch. It has been hanging in my to-do list for a few
years... It answers (and even does more than) the need:
https://lists.isc.org/pipermail/inn-workers/2011-October/017952.html
> What it does is to add a few options to inn.conf:
>
> - tlsprotocols: allows to select the SSL/TLS versions that are
> supported
>
> - tlsciphers: allows to give an OpenSSL cipher string to tailor the
> cipher suites that are offered to clients
>
> - tlsprefer_server_ciphers: switches on the server-side selection of
> the cipher suite (TLS default is "client choses")
Great!
> Additionally, TLS compression is turned off unconditionally (because
> of the CRIME attack) if the OpenSSL version supports this.
Like Johan, I am a bit reluctant to deactivate it unconditionally. At
least it could be configured with a tlscompression boolean value in
inn.conf that a news admin could set according to his needs.
I for one prefer the advantage of compression against the possibility of
a CRIME attack (especially on my news server that does not contain any
confidential data to steal!).
> The patch is against 2.5.4, and I hope it holds up to your coding
> standards.
Yes, the coding style is fine. Thanks again!
I will just adapt it for 2.6.0 because we unconditionally deactivated SSLv2.
I also believe it should be useful to log an error if a string is not
recognized ("unknown SSLv4 protocol specified in tlsprotocols" for
instance).
Another thing: aren't the "#define TLS_SSLv2" and like a possible
conflict with name spacing of OpenSSL? (INN_TLS_SSLv2 or
INN_PROTOCOL_TLS_SSLv2 are maybe better)
In the inn.conf sample, we should put "DEFAULT" (because it matches the
default value, when the parameter is unset).
Isn't there something to do with SASL? It can add security layers too...
As you are concerned about vulnerabilities, here is a list of several
things that could be improved. In case you wish to work on a few of
them, do not hesitate to tell us :)
*Of course, no obligation!*
- nnrpd currently uses precomputed ephemeral Diffie-Hellman keys. It
should support user-specified files, to eliminate risk of "small group"
attacks.
- TLS server_name extension should be added to nnrpd.
- 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."
--
Julien ?LIE
? Ils ont coul? mon entreprise. ? (les pirates, dans _Ast?rix_)
------------------------------
Message: 2
Date: Sun, 09 Nov 2014 16:10:33 +0100
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: New posting-account attribute in Injection-Info for CURRENT
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
In CURRENT (INN 2.6.0), a new parameter is now available in inn.conf:
addinjectionpostingaccount.
When set to true, the Injection-Info: header field contains an additional
posting-account attribute that mentions the username assigned to the
user at connection time or after authentication. The default value
for this parameter is false.
I know that some of the readers of this list use Perl filters to obfuscate
the contents of the Injection-Info: header fields, especially the posting-host
attribute.
If you want, you can add the posting-account attribute and obfuscate it
the same way you do with the posting-host.
Examples:
If authenticated as the user "julien" (AUTHINFO):
Injection-Info: news.trigofacile.com; posting-account="julien";
posting-host="22.155-224-89.dsl.completel.net:89.224.155.22";
logging-data="4543"; mail-complaints-to="abuse@..."
If sending a post via inews (for which the connection matches the user
"<localhost>" set by an access block in readers.conf):
Injection-Info: news.trigofacile.com; posting-account="<localhost>";
posting-host="localhost.localdomain:127.0.0.1";
logging-data="5458"; mail-complaints-to="abuse@..."
--
Julien ?LIE
? Ils ont coul? mon entreprise. ? (les pirates, dans _Ast?rix_)
------------------------------
Message: 3
Date: Sun, 09 Nov 2014 09:16:15 -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
Johan van Selst <[email protected]> writes:
> I like having control for TLS settings; although sensible defaults are
> generally much more impportant. But I do not understand why this
> specific compression setting is unconditional. To exploit CRIME requires
> a huge amount of carefully triggered, very similar, but slightly
> different server responses. I see no way to exploit this in the Netnews
> context.
There are several places where the server will echo back a message ID
given as input. LIST ACTIVE on a bunch of group names in the same
hierarchy might do it as well. I'm not sure how close the responses need
to be.
--
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: Sun, 09 Nov 2014 18:56:46 +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 all,
>> I like having control for TLS settings; although sensible defaults are
>> generally much more impportant. But I do not understand why this
>> specific compression setting is unconditional. To exploit CRIME requires
>> a huge amount of carefully triggered, very similar, but slightly
>> different server responses. I see no way to exploit this in the Netnews
>> context.
>
> There are several places where the server will echo back a message ID
> given as input. LIST ACTIVE on a bunch of group names in the same
> hierarchy might do it as well. I'm not sure how close the responses need
> to be.
Would this CRIME exploit imply that using compression with encrypted
data is not secure? (Therefore, a possible COMPRESS command for the
NNTP protocol should not be used at the same time as an encrypted
layer... We would then have to choose between compression or encryption!)
--
Julien ?LIE
? Confessio est regina probatio. ?
------------------------------
Message: 5
Date: Sun, 09 Nov 2014 10:12:30 -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:
> Would this CRIME exploit imply that using compression with encrypted
> data is not secure? (Therefore, a possible COMPRESS command for the
> NNTP protocol should not be used at the same time as an encrypted
> layer... We would then have to choose between compression or
> encryption!)
I went and reminded myself of the nature of the attack, and I think it may
not be relevant to NNTP.
The basic idea behind CRIME is that messages with almost the same content
cause noticable artifacts in the compressed output, primarily in sudden
changes in length based on the content of the underlying message. An
observer of multiple almost-identical messages who knows the pattern of
the underlying data can use those variations to extract information about
secure data that's sent as part of the connection.
http://en.wikipedia.org/wiki/CRIME
has a good summary.
This is an attack on HTTP because there are various ways were an attacker
can get a browser to perform multiple requests to a remote server, and
there is secure data (the session cookie) that the attacker wants to
extract. But neither of those apply to NNTP. Because NNTP is stateful,
it doesn't have security information that's sent with every request, which
is the target of a CRIME attack. Security information is sent only once,
at first, as part of the authentication. And there isn't a mechanism for
an attacker to get the NNTP client to send that message many, many times
with slight variations.
So, unless I'm missing something, I don't think this is something we need
to worry about for NNTP. It's similar to IMAP in that regard:
http://security.stackexchange.com/questions/51579/do-the-beast-and-crime-attacks-apply-to-an-imap-service
(I think that message is wrong about the possibility of an attack via
sending the target a bunch of mail, since the other component of the
attack -- the security data contained in each client transmission -- is
still missing.)
--
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: Sun, 9 Nov 2014 23:18:18 +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 Sun, Nov 09, 2014 at 03:39:45PM +0100, Julien ?LIE wrote:
> >nnrpd's TLS support is basically using OpenSSL's defaults WRT issues
> >such as protocol support and cipher suites. In these days of POODLEs
> >and other vulnerabilities, I wanted to be able to have better control
> >over what's offered there, so I wrote this patch.
>
> Thanks for this patch. It has been hanging in my to-do list for a
> few years... It answers (and even does more than) the need:
> https://lists.isc.org/pipermail/inn-workers/2011-October/017952.html
Good to see it's not only my itch...
> >Additionally, TLS compression is turned off unconditionally (because
> >of the CRIME attack) if the OpenSSL version supports this.
>
> Like Johan, I am a bit reluctant to deactivate it unconditionally.
> At least it could be configured with a tlscompression boolean value
> in inn.conf that a news admin could set according to his needs.
OK, so I'll just add that option. BTW, any comments on the defaults I
chose for the other options? (TLSv1.x, prefer server ciphers).
One could argue
a) keep the settings as they were before, as to not change existing
system's behaviour
b) let the defaults be secure (the definition I use here is the one
from bettercrypto.org, where I'm a co-author)
> I for one prefer the advantage of compression against the
> possibility of a CRIME attack (especially on my news server that
> does not contain any confidential data to steal!).
My reason to hard-code it was that it is the only thing I changed
which (AFAIK) doesn't break compatiblity with clients -- and my habit
of turning it off everywhere and wanting to have a unified TLS config
for all services on my systems, whether the attacks are known to be
relevant to NNTP or not (see Russ' mail on the subject).
But the right thing is definitely to leave the option to the admin.
> I also believe it should be useful to log an error if a string is
> not recognized ("unknown SSLv4 protocol specified in tlsprotocols"
> for instance).
OK.
> Another thing: aren't the "#define TLS_SSLv2" and like a possible
> conflict with name spacing of OpenSSL? (INN_TLS_SSLv2 or
> INN_PROTOCOL_TLS_SSLv2 are maybe better)
OK.
> In the inn.conf sample, we should put "DEFAULT" (because it matches
> the default value, when the parameter is unset).
You mean the "tlsciphers" monster string in samples/inn.conf.in? Shall
I just leave it empty, which is the default, which in turn leads to
OpenSSL's default cipher list to be used?
> Isn't there something to do with SASL? It can add security layers too...
I'm far from an expert in SASL, but nnrpd/sasl.c seems to only care
whether we have a TLS connection, how strong (in bits) the negotiated
cipher is, and what the client certificate CN is (if any).
So I don't think any code changes are necessary.
> - nnrpd currently uses precomputed ephemeral Diffie-Hellman keys.
> It should support user-specified files, to eliminate risk of "small
> group" attacks.
Frankly, that is not my first priority, as using well-chosen parameter
sets (such as those from IKE, as we recommend in the bettercrypto
paper after exhaustive discussion) may be safer than self-generated
ones. INN uses parameters from SKIP (as the comments indicate), so one
would have to do research about their quality.
Two interesting issues arise WRT DH parameters, however:
a) I've seen that even with 3072 bit RSA keys, the negotiation is
using the 1024 bit DH parameters -- I'll have a look into that.
b) ISTR that to allow ECDH, some setup of the openssl objects is
necessary; I'll also look into that.
> - 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.
> - 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.
Finally I'll attach another iteration of the patch, against a clean
2.5.4 tree.
cm.
--
** christian mock in vienna, austria -- http://www.tahina.priv.at/
** http://www.vibe.at/ ** http://quintessenz.org/ ** [email protected]
If you really want a tape-based backup solution, use lots of duct tape
to package up IDE hard-drives to keep them safe offsite. -- AdB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: inn-2.5.4-sslconf-v2.patch
Type: text/x-diff
Size: 8599 bytes
Desc: not available
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20141109/5f558a5b/attachment.bin>
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 66, Issue 2
******************************************
