Re: [Nbd] option haggling: reordering and TLS
On 17 Apr 2016, at 12:55, Wouter Verhelst <w@...112...> wrote:
> Something just occurred to me.
>
> A client sends:
> NBD_OPT_LIST
> NBD_OPT_STARTTLS
>
> without waiting for replies from the server. The server hasn't finished
> replying to NBD_OPT_LIST yet (although it may have started) by the time
> it sees NBD_OPT_STARTTLS.
>
> One way to reply to this could be to send NBD_REP_ACK(NBD_OPT_STARTTLS)
> before the NBD_REP_ACK(NBD_OPT_LIST). At that point, the client hasn't
> seen the full reply to NBD_OPT_LIST (if it has seen anything at all).
Well this is another consequences of being able to process things
out of order. Even more amusing:
A client sends NBD_OPT_LIST and NBD_OPT_STARTTLS, but the server
decides to process the NBD_OPT_STARTTLS first, and sets up a TLS
negotiation the client is not expecting (as he's expecting
his NBD_OPT_LIST reply in the plain).
Or alternatively:
A client sends NBD_OPT_STARTTLS and just when the server is
about to reply to it, it sends NBD_OPT_LIST in the clear.
This then gets mixed up with the start TLS handshake and it fails.
> How do we handle this?
>
> - We can say that this is not allowed (an upgrade to TLS can only be
> performed once all outstanding requests have been handled)
> - We can say that this is allowed, and that upgrading to TLS cancels all
> outstanding requests.
> - We can say that this is allowed, and that upgrading to TLS does *not*
> cancel all outstanding requests.
I believe the only way around that is to say NBD_OPT_STARTTLS must
be the only outstanding option when it's sent, and the client
must not send any further options until it's got a reply.
Personally I would just ban more than one inflight option at once,
as it provides complications for no gain.
> The first is easiest to implement, but adds ordering requirements.
And adds ordering requirements as a compulsory thing for a server
to do whether or not it wants to deal with hypothetical clients
that send more than one option at once.
Also, doesn't handle the 'broken handshake' issue if the client
sends another option 'during' the starttls.
> The
> second is harder to implement, but can allow the server to leak less
> data.
Save for the fact it doesn't work in the cases that actually
corrupt the TLS handshake.
> In both cases, a client will likely issue another NBD_OPT_LIST in
> the TLS channel, so the first (certainly) as well as the second
> (possibly) provides plaintext for an eavesdropper, which will allow the
> latter to perform a known-plaintext attack.
>
> The third does away with the known plaintext issue, but it does make it
> much much harder for a client to keep track of things.
Again, doesn't handle the 'broken handshake' issue.
Go with the far simpler option I proposed, and preferably go further
and ban more than one inflight thing.
--
Alex Bligh
Reply to: