Re: [Nbd] [Qemu-devel] spec, RFC: TLS support for NBD
- To: Stefan Hajnoczi <stefanha@...696...>
- Cc: Florian Weimer <fweimer@...696...>, "Daniel P. Berrange" <berrange@...696...>, libvir-list@...696..., mprivozn@...696..., nbd-general@...72..., "Richard W.M. Jones" <rjones@...696...>, qemu-devel@...530..., Wouter Verhelst <w@...112...>, Paolo Bonzini <pbonzini@...696...>, Max Reitz <mreitz@...696...>
- Subject: Re: [Nbd] [Qemu-devel] spec, RFC: TLS support for NBD
- From: Markus Armbruster <armbru@...696...>
- Date: Mon, 20 Oct 2014 13:51:43 +0200
- Message-id: <8738ajq7qo.fsf@...1802...>
- In-reply-to: <20141020095621.GA28515@...1390...> (Stefan Hajnoczi's message of "Mon, 20 Oct 2014 10:56:21 +0100")
- References: <20140903164417.GA32748@...1390...> <20140905084618.GA3720@...1599...> <20140905132608.GB26974@...3...> <20141001202326.GA2533@...3...> <20141002110516.GG13032@...696...> <542D36E8.2010705@...696...> <20141017220323.GC31287@...3...> <20141018063322.GC1349@...696...> <20141020075814.GB19687@...696...> <20141020095621.GA28515@...1390...>
Stefan Hajnoczi <stefanha@...696...> writes:
> On Mon, Oct 20, 2014 at 08:58:14AM +0100, Daniel P. Berrange wrote:
>> On Sat, Oct 18, 2014 at 07:33:22AM +0100, Richard W.M. Jones wrote:
>> > On Sat, Oct 18, 2014 at 12:03:23AM +0200, Wouter Verhelst wrote:
>> > > Hi all,
>> > >
>> > > (added rjones from nbdkit fame -- hi there)
>> >
>> > [I'm happy to implement whatever you come up with, but I've added
>> > Florian Weimer to CC who is part of Red Hat's product security group]
>> >
>> > > So I think the following would make sense to allow TLS in NBD.
>> > >
>> > > This would extend the newstyle negotiation by adding two options (i.e.,
>> > > client requests), one server reply, and one server error as well as
>> > > extend one existing reply, in the following manner:
>> > >
>> > > - The two new commands are NBD_OPT_PEEK_EXPORT and NBD_OPT_STARTTLS. The
>> > > former would be used to verify if the server will do TLS for a given
>> > > export:
>> > >
>> > > C: NBD_OPT_PEEK_EXPORT
>> > > S: NBD_REP_SERVER, with an extra field after the export name
>> > > containing flags that describe the export (R/O vs R/W state,
>> > > whether TLS is allowed and/or required).
>>
>> IMHO the server should never provide *any* information about the exported
>> volume(s) until the TLS layer has been fully setup. ie we shouldn't only
>> think about the actual block data transfers, we should protect the entire
>> NBD protocol even metadata related operations.
>
> This makes sense.
Seconded.
> TLS is about the transport, not about a particular NBD export. The only
> thing that should be communicated is STARTTLS.
Furthermore, STARTTLS is vulnerable to active attacks: if you can get
between the peers, you can make them fall back to unencrypted silently.
How do you plan to guard against that?
See also https://www.agwa.name/blog/post/starttls_considered_harmful
Reply to: