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