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 <eblake@...696...> 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