On 10/20/2014 01:51 PM, Markus Armbruster wrote:
Furthermore, STARTTLS is vulnerable to active attacks: if you can get between the peers, you can make them fall back to unencrypted silently. How do you plan to guard against that?
The usual way to deal with this is to use different syntax for TLS-enabled and non-TLS addresses (e.g., https:// and http://). With a TLS address, the client must enforce that only TLS-enabled connections are possible. STARTTLS isn't the problem here, it's just an accident of history that many STARTTLS client implementations do not require a TLS handshake before proceeding.
I cannot comment on whether the proposed STARTTLS command is at the correct stage of the NBD protocol. If there is a protocol description for NBD, I can have a look.
-- Florian Weimer / Red Hat Product Security -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
