Hi,
On Fri, Sep 05, 2014 at 03:26:09PM +0200, Wouter Verhelst wrote:
> Tunneling the entire protocol inside an SSL connection doesn't fix that;
> if an attacker is able to hijack your TCP connections and change flags,
> then this attacker is also able to hijack your TCP connection and
> redirect it to a decrypting/encrypting proxy.
>
> I agree that preventing a possible SSL downgrade attack (and other forms
> of MITM) should be high on the priority list, but "tunnel the whole
> thing in SSL" doesn't do that.
So, having given this some thought, I wanted to come up with a spec just
so that we had something we could all agree on. As part of that, I had a
look at qemu-nbd, and noticed that it uses the "oldstyle" handshake
protocol (on port 10809 by default -- ew, please don't do that).
I had to change the protocol incompatibly a few years back, because the
oldstyle protocol is broken by design; in the oldstyle negotiation
protocol, the server dumps all information it has on the export to the
client, and then moves on to the data negotiation phase, without waiting
for any reply from the client. This means the oldstyle protocol can't be
used for any sort of negotiation[1].
As such, I strongly suggest that qemu-nbd move to the newstyle protocol.
This would also allow you to use named exports and various other things,
and would allow negotiation of TLS or SASL in a clean and proper way.
[1] That sole issue is the reason I broke backwards compatibility with
the newstyle handshake protocol, and is also why I reserved 10809,
the port assigned to nbd by IANA at my request, to be for newstyle
handshakes only.
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list