[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Nbd] TLS implementation in reference nbd-server



Wouter,

> On 12 Oct 2016, at 19:40, Wouter Verhelst <w@...112...> wrote:
> 
> While stuck in an airport on a 9-hour layover two days ago, I (finally)
> spent some time working on a STARTTLS implementation for the reference
> nbd-server implementation. Configuration is fairly basic; just add a
> "tlsdir = " configuration item to the nbd-server config file, create a
> ca.pem, priv.pem, and cert.pem file in that location, and you're good.
> The current implementation doesn't allow for authenticating clients
> through certificates or other means; I will probably want to add that at
> some point in the future, but not just yet.
> 
> It's not been tested yet, however, because the client side hasn't been
> done yet. I will do that before I release this (probably by adding Alex'
> implementation from a few months back). Also, I think I should test
> against current implementations of the NBD STARTTLS option (e.g., qemu),
> and see if things interoperate with that too, before going further.
> Hasn't been done yet (mostly because the documentation on how to do
> starttls in qemu nbd seems incomplete, at best; a pointer to an example
> or some such would be welcome), but expect this in the next few weeks or
> so.
> 
> If you want to check it out, just run nbd-server from git master.
> Feedback (and/or review) welcome :-)

I'm happy to have a detailed look at this later (and indeed
do some interoperability testing - I'll see if I can dig out
the qemu-img command line I used to test gonbdserver), but
a couple of questions from now:

1. I take it you want patch comments by email here (not in
   github)?

2. I really don't like the 'tlsdir' configuration option. It
   seems like a recipe for getting things wrong. Firstly
   Linux (at least) already seems to have standards for where
   SSL certs go - in /etc/ssl/certs and /etc/ssl/private,
   i.e. two separate directories. These already have permissions
   set correctly, and facilitate sharing with other applications
   for the same server name. Secondly, it's not obvious why the
   certificate, private key file, and cert should have that name.
   Thirdly this precludes a configuration where the private key
   and certificate are in the same file and only one path is
   given. Fourthly, if you aren't checking client certificates,
   why is a CA file mandatory?

   Can I suggest you copy what I did in gonbdserver ( :-) )

	• certfile: Path to TLS cert file in PEM format. Optional, if not provided, defaults to KeyFile and assumes the PEM at keyfile has the certificate in as well as the private key.
	• servername: Server name as announced by TLS. Optional, if not provided defaults to host name.
	• cacertfile: Path to a file containing one or more CA certificates in PEM format. Optional, but required if validating client certificates

   In fact, feel free to nick the entirety of the configuration section
   from here: https://github.com/abligh/gonbdserver

3. You don't seem to permit validating client certificates. This
   is (a) pretty easy, and (b) pretty important.

-- 
Alex Bligh







Reply to: