qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/15] Implement TLS support to QEMU NBD server


From: Wouter Verhelst
Subject: Re: [Qemu-devel] [PATCH 00/15] Implement TLS support to QEMU NBD server & client
Date: Wed, 2 Dec 2015 14:45:10 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

On Wed, Dec 02, 2015 at 01:37:08PM +0000, Daniel P. Berrange wrote:
> On Wed, Dec 02, 2015 at 01:56:30PM +0100, Wouter Verhelst wrote:
> > Hi Daniel,
> > 
> > Something occurred to me earlier today:
> > 
> > On Fri, Nov 27, 2015 at 12:20:38PM +0000, Daniel P. Berrange wrote:
> > > As is, if the client connects to a TLS enabled NBD server and then
> > > immediately sends NBD_OPT_EXPORT_NAME, it is not possible for us
> > > to send back NBD_REP_ERR_TLS_REQD as the spec requires that the
> > > server close the connection :-(  For this reason I have made the
> > > qemu NBD client always send NBD_OPT_LIST as the first thing it
> > > does, so that we can see the NBD_REP_ERR_TLS_REQD response.
> > 
> > Why not have it send NBD_OPT_STARTTLS as the first message if you want
> > to do TLS? That way, either the server doesn't support it because too
> > old (and you get NBD_REP_ERR_UNSUP) or configuration (and you get
> > NBD_REP_ERR_POLICY), or it does and you're in TLS.
> > 
> > Did I miss something?
> 
> Yes, if the client wants TLS, it will send NBD_OPT_STARTTLS as the
> first thing it does.
> 
> My comment above was refering to the case of a client not wanting
> TLS which is connecting to a server that does want TLS. In that
> case sending NBD_OPT_LIST is what we need to do in order to get
> a suitable error from the server about requirement for TLS.

Right, of course. Yes, that makes sense. Ignore what I said :-)

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26



reply via email to

[Prev in Thread] Current Thread [Next in Thread]