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
(christian mock)
----------------------------------------------------------------------
Message: 1
Date: Thu, 13 Nov 2014 21:22:08 +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,
> 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
> insecure".
I'll have a look, thanks for the patch.
One question after reading it: why test
#if !defined(OPENSSL_NO_EC) && defined(TLSEXT_ECPOINTFORMAT_uncompressed)
to set HAVE_SSL_ECC?
TLSEXT_ECPOINTFORMAT_uncompressed is not used afterwards. Isn't
OPENSSL_NO_EC enough?
Getting back to tlsprotocols and tlsciphers, is there something to do
with regards to RFC 4642?
Servers MUST be able to understand backwards-compatible TLS Client
Hello messages (provided that client_version is TLS 1.0 or later),
and clients MAY use backwards-compatible Client Hello messages.
Neither clients nor servers are required to actually support Client
Hello messages for anything other than TLS 1.0.
=> Does it mean that supporting TLS 1.0 is mandatory for a news server,
or does the "Client Hello" stuff mean another thing?
(Would supporting only TLS 1.2 be a complying behaviour?)
I ask because we should add something about that subject in our
documentation (to warn users that some keywords are required for
interoperability - I wonder whether it is only TLSv1).
NNTP client and server implementations MUST implement the
TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite and SHOULD implement the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is
important, as it assures that any two compliant implementations can
be configured to interoperate. All other cipher suites are OPTIONAL.
=> Same thing: we should mention that.
Another possibility would be to unconditionally add them (but I believe
just giving a warning in our documentation would be enough, don't you?).
>> - TLS server_name extension should be added to nnrpd.
>
> 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.
It therefore looks as though SNI were not related to the concept of
nnrpd's virtualhosts. It is indeed something different than Apache's
virtualhosts.
RFC 4642:
The TLS
extension for Server Name Indication ("server_name") [TLS-EXT] SHOULD
be implemented by all clients; it also SHOULD be implemented by any
server implementing STARTTLS that is known by multiple names.
(Otherwise, it is not possible for a server with several hostnames to
present the correct certificate to the client.)
So the NNTP server just has to use the right certificate instead of
always the same one specified in tlskeyfile/tlscertfile, hasn't it?
--
Julien ?LIE
? Ta vie ne tient qu'? un fil, T?l?f?ric ! ? (Ast?rix)
------------------------------
Message: 2
Date: Fri, 14 Nov 2014 09:39:47 +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 Thu, Nov 13, 2014 at 09:22:08PM +0100, Julien ?LIE wrote:
> One question after reading it: why test
>
> #if !defined(OPENSSL_NO_EC) && defined(TLSEXT_ECPOINTFORMAT_uncompressed)
>
> to set HAVE_SSL_ECC?
> TLSEXT_ECPOINTFORMAT_uncompressed is not used afterwards. Isn't
> OPENSSL_NO_EC enough?
This is stolen from apache -- the TLSEXT_ECPOINTFORMAT_uncompressed
would make sure your openssl version actually supports EC, and the
other one makes sure it's not been disabled.
> Getting back to tlsprotocols and tlsciphers, is there something to
> do with regards to RFC 4642?
>
> Servers MUST be able to understand backwards-compatible TLS Client
> Hello messages (provided that client_version is TLS 1.0 or later),
> and clients MAY use backwards-compatible Client Hello messages.
> Neither clients nor servers are required to actually support Client
> Hello messages for anything other than TLS 1.0.
>
> => Does it mean that supporting TLS 1.0 is mandatory for a news
> server, or does the "Client Hello" stuff mean another thing?
> (Would supporting only TLS 1.2 be a complying behaviour?)
I am not sure what the authors intended with that paragraph, except to
force every compliant implementation to forever support TLSv1.0, and
supersede the RFC when something POODLE-like comes along for TLS 1.0.
Or, you can read it differently -- a server configured with only TLS
1.2 does in fact "support" a 1.0 client hello message, it's just that
it replies with a fatal alert "Protocol Version".
> I ask because we should add something about that subject in our
> documentation (to warn users that some keywords are required for
> interoperability - I wonder whether it is only TLSv1).
I think interoperability is something the admin has to decide, because
they know their user base and what clients they need to support.
> NNTP client and server implementations MUST implement the
> TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite and SHOULD implement the
> TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is
> important, as it assures that any two compliant implementations can
> be configured to interoperate. All other cipher suites are OPTIONAL.
In hindsight, that was short-sighted -- 8 years later, and MD5 is
considered broken, RC4 is frowned upon because it's got biases, DSS is
fixed to 1024 bit keys and 3DES is deprecated.
> => Same thing: we should mention that.
Yes, probably.
> Another possibility would be to unconditionally add them (but I
> believe just giving a warning in our documentation would be enough,
> don't you?).
I'm strongly against unconditionally adding those. Warnings are fine,
of course, I'd prefer wording them like "Formally, you are required
..." to make sure it's not taken too seriously.
> So the NNTP server just has to use the right certificate instead of
> always the same one specified in tlskeyfile/tlscertfile, hasn't it?
Yes.
Being able to select a configuration group in readers.conf via SNI
would be nice -- you could have the same user name for different
identities and stuff. But that wouldn't work with plaintext
connections, so there's little practical benefit.
OK, since the weekend is coming up -- where should that be
configurable? I envision something like
snihost foo.example.com {
tlscertfile: /bla/foo.pem
tlskeyfile: /bla/foo.key
...
}
snihost bar.example.com {
tlscertfile: /bla/bar.pem
tlskeyfile: /bla/bar.key
...
}
which won't work in inn.conf, right? So would we move that to
readers.conf, or create a new config file?
I think the existing config values in inn.conf (tls*) should stay
there for backwards compatibility, and be the default values. snihost
blocks require tlscertfile and tlskeyfile and may have any of the
other tls* options, those default to the inn.conf values.
When a client sends an SNI that matches a snihost block, those values
are used, else the defaults.
Does that sound reasonable?
cm.
--
** christian mock in vienna, austria -- http://www.tahina.priv.at/
Metallica wasn't affected much, unsurprisingly. You can play lots
of Metallica MP3s at the same time and it still sounds like
Metallica, only more so. -- Dave Brown
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 66, Issue 6
******************************************
