qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).