On 17 Apr 2016, at 12:55, Wouter Verhelst <[email protected]> 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 ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
