qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Improve documentation for TLS


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH] Improve documentation for TLS
Date: Thu, 7 Apr 2016 09:35:37 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1

On 04/07/2016 06:36 AM, Alex Bligh wrote:
> 
> On 7 Apr 2016, at 13:13, Alex Bligh <address@hidden> 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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]