[libvirt] [Nbd] [Qemu-devel] spec, RFC: TLS support for NBDµ

Sat Oct 25 10:43:35 UTC 2014

Hi all,

I haven't seen a reply to this anymore. Do people still have comments?
I'm planning on doing a release of nbd later this weekend, and would
like to include this (not the TLS implementation yet, but at least the
spec)

Thanks,

On Tue, Oct 21, 2014 at 08:30:05PM +0200, Wouter Verhelst wrote:
> Hi Markus,
> 
> On Tue, Oct 21, 2014 at 10:17:17AM +0200, Markus Armbruster wrote:
> > Wouter Verhelst <w at uter.be> writes:
> > > On Mon, Oct 20, 2014 at 01:51:43PM +0200, Markus Armbruster wrote:
> [...]
> > >> 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?
> > >
> > > As I've said before in this discussion, encryption downgrade attacks are
> > > not specific to STARTTLS; as soon as you have have an "encrypted" and an
> > > "unencrypted" variant of a protocol, that becomes a problem. After all,
> > > if an attacker can modify the communication so that STARTTLS is filtered
> > > out of the communication, they can most likely also redirect all traffic
> > > to a decrypting/encrypting proxy.
> > >
> > > The only way to fix that is through userspace; make "opportunistic" TLS
> > > (i.e., use it if available, but move on if not) difficult to achieve.
> > >
> > >> See also https://www.agwa.name/blog/post/starttls_considered_harmful
> > >
> > > A random blog post by an author who is speaking about STARTTLS in
> > > general terms is not a good technical argument for why STARTTLS is a bad
> > > idea in *this* specific case.
> > 
> > Misunderstanding.  I didn't mean to claim "STARTTLS is bad".  If I
> > wanted to say that, I would've said it directly.  I was merely asking
> > how you plan to guard against downgrade attacks.  I gather your advice
> > is to make the client (QEMU) insist on TLS, and check the server's
> > certificate.  Correct?
> 
> My advice is to give both client and server the ability to have TLS
> switched on or off, and possibly (but not necessarily so, and certainly
> not by default) also the _ability_ to negotiate TLS if the other side
> supports it, while not aborting if it doesn't.
> 
> > > If I was defining a new protocol from scratch, I might dump the whole
> > > thing in TLS to begin with. But that's just not the case, so I have to
> > > deal with what exists already.
> > 
> > Yes.  You can still start over on a separate port.  However:
> 
> No, I can't, at least not if I want to continue to use an assigned port
> without breaking backwards compatibility. When 10809 was assigned to
> NBD, IANA made it perfectly clear that I wouldn't get a new port number
> for a "secure" variant.
> 
> > > In addition, with the current state of affairs, it is *not possible* to
> > > swap to an NBD device if you need to pipe its data through a separate
> > > socket than the one you're handing to the kernel. The result of that is
> > > that you can't do TLS on a device you want to swap to. This means we
> > > need to continue to support a protocol that can do TLS for some exports,
> > > and plain (unencrypted) traffic for other exports, *in the same running
> > > nbd-server instance*.
> > 
> > I don't understand enough about NBD to challenge this argument.  The sad
> > consequence is more complexity and a larger attack surface.
> > 
> > Out of curiosity: is this "merely" an implementation restriction, or is
> > it more fundamental?
> 
> Well, to some extent, every software issue is merely an implementation
> restriction...
> 
> The problem is that in order to clear memory when your swap device is on
> the other side of a network connection, you need to write to said swap
> device, which causes TCP traffic, which means the kernel needs to read
> TCP ACK packets (or in the case of NBD, the reply packet to the
> NBD_CMD_WRITE request that you sent out) to ensure that the traffic has
> in fact reached its destination. Unfortunately, you can't impose
> ordering on incoming network traffic, so that means you may need to read
> through a whole lot of youtube MPEG traffic or some such in order to
> find your one TCP ACK that tells you your swapout has been processed
> correctly and you can now clear the memory which you wrote out to swap.
> 
> It's fairly obvious how that could lead to a deadlock if you don't know
> that this one data stream is not related to swapspace while this other
> one here is.
> 
> That's why a PF_MEMALLOC kernel-space socket option was created; sockets
> marked with that option are related to a swapdevice, so when the kernel
> is low on memory, it will throw away all incoming network traffic
> _except_ for packets destined for a socket marked with that option, in
> the hope that this will allow us to clear up some memory.
> 
> Since it's a kernel-space only thing, that means you can't mark sockets
> as such from userspace; so if the NBD traffic is wrapped in some other
> traffic from which it needs to be unwrapped in userspace, then the
> userspace component would basically be a proxy with two sockets -- one
> towards the server, one towards the kernel. The socket towards the
> kernel would have the PF_MEMALLOC socket option set, but the one towards
> the server would not, and *that* is the one which actually has data
> flowing in over the network. There's your deadlock again.
> 
> Since, with the current state of affairs, the NBD handshake is done in
> user space with the actual data pushing stuff later being done in kernel
> space, that means you do actually need to unwrap the TLS traffic in
> userspace.
> 
> I can't think of many ways that would allow us to get around that issue:
> - Figure out a way to move negotiated keys from user space to kernel
>   space, and handle the TLS in kernel space rather than user space. I'm
>   not even sure if you _can_ do TLS in kernel space (let alone whether
>   it's a good idea).
> - Move the handshake to kernel space from user space. I'm not a fan of
>   that idea. It would also still require much of the TLS in kernel
>   space.
> - Patch the kernel so that userspace can mark a particular socket with
>   PF_MEMALLOC. And mlock() the whole TLS stack into memory (including
>   keys etc).
> 
> All three of those require "patch the kernel", so at any rate going
> there would require "wait until the kernel supports it before we can do
> TLS", which I think is not a good option.
> 
> > > I did add the NBD_REP_ERR_TLS_REQD message for a server which does not
> > > export anything unencrypted, so that it can (after the initial few
> > > exchanges) reply to anything except for STARTTLS with "lalala, I'm not
> > > listening until you encrypt things". However, unless it's fine to ditch
> > > support for swapping to an NBD device (not an option from where I'm
> > > standing), dropping support for unencrypted communication is not an
> > > option.
> > 
> > That's a good idea.  It doesn't make things less complex, though.
> 
> True.
> 
> -- 
> It is easy to love a country that is famous for chocolate and beer
> 
>   -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
> 
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Nbd-general mailing list
> Nbd-general at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nbd-general
> 

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

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