From: Eric Blake <eblake@redhat.com>
To: Alex Bligh <alex@alex.org.uk>,
"Daniel P. Berrange" <berrange@redhat.com>
Cc: "nbd-general@lists.sourceforge.net"
<nbd-general@lists.sourceforge.net>, Wouter Verhelst <w@uter.be>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] Improve documentation for TLS
Date: Thu, 7 Apr 2016 09:35:37 -0600 [thread overview]
Message-ID: <57067E49.8010608@redhat.com> (raw)
In-Reply-To: <97F7DE7A-30CA-49C0-8122-51B3FD71B7E3@alex.org.uk>
[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]
On 04/07/2016 06:36 AM, Alex Bligh wrote:
>
> On 7 Apr 2016, at 13:13, Alex Bligh <alex@alex.org.uk> wrote:
>
>> I guess it's worth documenting
>> this, though I thought it was obvious.
>
> The next version will have this section:
>
> ### Downgrade attacks
>
> A danger inherent in any scheme relying on the negotiation
too much space
> of whether TLS should be employed is downgrade attacks.
>
> There are two main dangers:
>
> * A Man-in-the-Middle (MitM) hijacks a session and impersonates
> the server (possibly by proxying it) claiming not to support
> TLS. In this manner, the client is confused into operating
> in a plain-text manner with the MitM (with the session possibly
> being proxied in plain-text to the server using the method
> below).
looks like too much space is a problem in general in this rough draft;
I'll quit pointing it out and assume you will reflow before final
submission.
>
> * The MitM hijacks a session and impersonates the client
> (possibly by proxying it) claiming not to support TLS. In
> this manner the server is confused into oeprating in a plain-text
s/oeprating/operating/
> manner with the MitM (with the session being possibly
> proxied to the server with the method above).
s/server/client/
>
> With regard to the first, any client that does not wish
> to be subject to potential downgrade attack SHOULD ensure
> that if a TLS endpoint is specified by the client, it
> ensures that TLS is negotiated prior to sending or
> requesting sensitive data. To recap, yhe client MAY send
s/yhe/the/
> `NBD_OPT_STARTTLS` at any point during option haggling,
> and MAY disconnect the session if `NBD_REP_ACK` is not
> provided.
Probably want to add: "but the client SHOULD strongly consider sending
`NBD_OPT_STARTTLS` as its first option"
>
> 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 are may be served either via TLS or
> in plain text.
Probably want to add: "OPTIONALTLS mode SHOULD NOT be used if there is a
potential for man-in-the-middle attacks"
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2016-04-07 15:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-07 11:35 [Qemu-devel] [PATCH] Improve documentation for TLS Alex Bligh
2016-04-07 11:51 ` Daniel P. Berrange
2016-04-07 12:13 ` Alex Bligh
2016-04-07 12:36 ` Alex Bligh
2016-04-07 15:35 ` Eric Blake [this message]
2016-04-07 15:52 ` Alex Bligh
2016-04-07 13:56 ` Daniel P. Berrange
2016-04-07 14:08 ` Alex Bligh
2016-04-09 9:50 ` [Qemu-devel] [Nbd] " Wouter Verhelst
2016-04-09 10:05 ` Alex Bligh
2016-04-09 10:29 ` Wouter Verhelst
2016-04-07 14:33 ` [Qemu-devel] " Eric Blake
2016-04-07 14:31 ` Eric Blake
2016-04-07 14:57 ` Alex Bligh
2016-04-09 9:55 ` [Qemu-devel] [Nbd] " Wouter Verhelst
2016-04-09 10:06 ` Alex Bligh
2016-04-09 9:36 ` Wouter Verhelst
2016-04-09 10:04 ` Alex Bligh
2016-04-09 10:33 ` Wouter Verhelst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57067E49.8010608@redhat.com \
--to=eblake@redhat.com \
--cc=alex@alex.org.uk \
--cc=berrange@redhat.com \
--cc=nbd-general@lists.sourceforge.net \
--cc=qemu-devel@nongnu.org \
--cc=w@uter.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.