[patch] more TLS configuration options for nnrpd

Julien ÉLIE julien at trigofacile.com
Fri Nov 14 13:42:02 UTC 2014


Hi Christian,

>>    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 will try to ask Ken and Jeffrey (the authors of the RFC).
Unless they are currently reading us and wish to comment?



> 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.
> 
> OK, since the weekend is coming up -- where should that be
> configurable?

Beware that parsing readers.conf is not at all as easy as parsing 
inn.conf :)



> 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
>   ...
> }

and could access blocks (and auth blocks?) then also be chosen depending 
on snihost?
For instance:

     auth default {
         hosts: "*"
         auth: "ckpasswd -d <pathdb>/newsusers"
         default: "<anonymous>"
     }

     access foo {
         snihost: "foo.example.com"
         newsgroups: "foo.*"
     }

     access bar {
         snihost: "bar.example.com"
         newsgroups: "bar.*"
     }



> which won't work in inn.conf, right? So would we move that to
> readers.conf, or create a new config file?

The syntax for
     snihost bar.example.com {
         tlscertfile: /bla/bar.pem
         tlskeyfile: /bla/bar.key
        ...
       }
could be possible in inn.conf.

That syntax is allowed:
     http://www.eyrie.org/~eagle/software/inn/docs/config-syntax.html

Yet, it may not currently be accepted in an innconf structure 
(lib/innconf.c)
though lib/confparse.c knows how to parse it.



> 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?

That sounds reasonable to me.

Before implementing that, we should perhaps give time for other people 
on the list
to comment on that feature.  Maybe someone will see specific needs to 
address
as for auth/access blocks based on SNI, which could have an impact on 
how to best
implement it.

-- 
Julien ÉLIE


More information about the inn-workers mailing list