qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCHv3] Improve documentation for TLS


From: Alex Bligh
Subject: Re: [Qemu-devel] [PATCHv3] Improve documentation for TLS
Date: Thu, 7 Apr 2016 21:05:04 +0100

Eric,

> Qemu's initial implementation of TLS in the client is binary (you either
> want TLS or plaintext; there's no way to connect to a server and then
> decide whether to upgrade to TLS - a plaintext client will never use TLS
> of an OPTIONALTLS server).  In TLS mode, the client always sends
> NBD_OPT_STARTTLS first (and gets a sane error message if the server
> can't/won't use TLS).  In plaintext mode, the client always sends
> NBD_OPT_LIST first - which will get a nice NBD_OPT_ERR_TLS_REQD from a
> FORCEDTLS server, but does NOT error out for a SELECTIVETLS server.

... assuming the export is non-TLS.

>  But
> if it DOES get a listing, it then checks that the desired export was
> present in the listing, which means a SELECTIVETLS server that requires
> TLS on the particular export the client was hoping for will cause the
> client to fail with a graceful error message of "export not present"
> generated by the client, rather than attempting NBD_OPT_EXPORT_NAME, so
> long as the SELECTIVETLS server omitted the TLS-only export in its
> listing.  Only for a really old server (such as non-fixed newstyle),
> where NBD_OPT_LIST cannot be attempted or fails with NBD_OPT_ERR_UNSUP,
> is the client still in the dark about whether TLS is required, but in
> that case, the server probably doesn't support TLS (especially since TLS
> requires fixed newstyle).

Yes.

> But the reason I see no need to modify your text: I'm planning on
> changing qemu's plaintext client to try NBD_OPT_GO rather than
> NBD_OPT_LIST.  For a FORCEDTLS server, the command will fail with
> NBD_REP_ERR_TLS_REQD (whether or not the server knows NBD_OPT_GO); and
> for a SELECTIVETLS server, we just mandated that NBD_OPT_GO must be
> recognized, so it will fail with NBD_REP_ERR_TLS_REQD for a TLS-only
> export, and will succeed (in plaintext) otherwise.  Which means there is
> no longer a need to fall back to NBD_OPT_LIST.

Which is better, as support for INFO is required for TLS
anyway, whereas LIST is optional.

>> +
>> +With regard to the second, any server that does not wish
>> +to be subject to a potential downgrade attack SHOULD either
>> +used FORCEDTLS mode, or should force TLS on those exports
>> +it is concerned about using SELECTIVE mode and TLS-only
>> +exports. It is not possible to avoid downgrade attacks
>> +on exports which may be served either via TLS or in plain
>> +text unless the client insists on TLS. OPTIONALTLS SHOULD NOT
>> +be used where man-in-the-midle attacks are a concern.
> 
> s/midle/middle/

thx

>> @@ -391,7 +679,10 @@ of the newstyle negotiation.
>> - `NBD_OPT_LIST` (3)
>> 
>>     Return a number of `NBD_REP_SERVER` replies, one for each export,
>> -    followed by `NBD_REP_ACK`.
>> +    followed by `NBD_REP_ACK`. The server MAY omit entries from this
>> +    list if TLS has not been negotiated and either the server is
>> +    operating in FORCEDTLS mode or the server is operating in
>> +    SELECTIVETLS mode and the entry concerned is a TLS-only export.
> 
> Not quite right - in FORCEDTLS mode, the server MUST reply with
> NBD_REP_ERR_TLS_REQD.  Correct would be:
> 
> The server MAY omit entries from this list if TLS has not been
> negotiated and the server is operating in SELECTIVETLS mode, where the
> entry concerned is a TLS-only export.
> 
> Maybe even strengthen it to SHOULD, particularly given my above side
> note about qemu's usage of NBD_OPT_LIST to determine if a plaintext
> client is talking to a server that wants TLS.

I went with SHOULD. Note the requirement to reply with NBD_REP_ERR_TLS_REQD
in FORCEDTLS mode if TLS has not been negotiated is documented elsewhere
and of course applies to all options other then NBD_OPT_STARTTLS.

> I'm down to just 2 findings and a side comment, which means we're close
> enough that you can add:
> Reviewed-by: Eric Blake <address@hidden>

Thanks - will send another version anyway.

Alex



> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
> 

--
Alex Bligh




Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


reply via email to

[Prev in Thread] Current Thread [Next in Thread]