All of lore.kernel.org
 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 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.