Re: [Nbd] NBD_OPT_GO
- To: Wouter Verhelst <w@...112...>
- Cc: "nbd-general@lists.sourceforge.net" <nbd-general@lists.sourceforge.net>
- Subject: Re: [Nbd] NBD_OPT_GO
- From: Alex Bligh <alex@...872...>
- Date: Tue, 5 Apr 2016 18:29:10 +0100
- Message-id: <568D6CC3-032F-487E-909A-BF9938F15BC6@...872...>
- In-reply-to: <20160405171713.GB31392@...3...>
- References: <BCE061F2-C16D-44E7-865A-4BB0A7C85088@...2364...> <5703C25F.6080303@...696...> <C329E25D-B352-471C-B348-82EC7C5EDCE1@...2364...> <5703D708.9080605@...696...> <C7AACE89-CBCD-4CC7-ACA7-C360D8BD3E75@...2364...> <5703DE26.2090707@...696...> <4FCD1D5B-6F3F-4EC7-8412-0E806518E0EB@...872...> <20160405171713.GB31392@...3...>
On 5 Apr 2016, at 18:17, Wouter Verhelst <w@...112...> wrote:
> On Tue, Apr 05, 2016 at 04:56:28PM +0100, Alex Bligh wrote:
>> What I presumed was the reason was that the client could try
>> selecting disk 'foo' prior to the TLS, but a man-in-the-middle
>> could (whilst cleverly hijacking the TCP session) change this
>> to a select of disk 'bar' (which might be his own and laden
>> with malware).
>
> That was (more or less) the idea, yes. Data sent over the wire in the
> clear should *not* be able to poison an encrypted connection later on,
> even if it is done in the same TCP session.
This is in general a really good reason to drop keeping state
server side (as you suggested in your other mail re this specific
case).
--
Alex Bligh
Reply to: