[libvirt] [PATCH] docs: added compiling page and significantly expanded windows page

[Matthias Bolte]

2010/11/17 Daniel P. Berrange <berrange at redhat.com>:
> On Wed, Nov 17, 2010 at 02:53:15PM +0100, Matthias Bolte wrote:
>> 2010/11/17 Justin Clift <jclift at redhat.com>:
>> > Also added an additional menu placement for the windows page, in
>> > order to attract further potential testers.
>> > ---
>>
>> > +      <li>
>> > +        The working connection types at the moment are very limited.  Only
>> > +        <b>qemu+tcp://</b> is known to work for sure.  Anything using SSH,
>> > +        such as <b>qemu+ssh://</b>, definitely doesn't work.  Connecting
>> > +        to ESX servers doesn't yet work either, due to a bug involving
>> > +        GnuTLS, which should be fixed in the next release.
>> > +      </li>
>>
>> Don't blame GnuTLS here. As stated on IRC my initial assumption was
>> wrong. The problem is probably not in GnuTLS, as gnutls-cli works
>> fine. The problem is in the way libcurl and GnuTLS interact. Therefore
>> libvirt's GnuTLS usage is not affected, only libcurl's.
>>
>> I know how to fix it, but I don't understand in detail yet why it works.
>
> Are you referring to this message ?
>
>  "A TLS packet with unexpected length was received"
>
> The place you normally see this is from 'gnutls_handshake()', and it is
> an indication that the handshake has been aborted by either the client
> or server. Typical problems include bad certificates, bad choice of
> encryption ciphers, bad TLS protocol, etc.  It is pretty hard to
> debug, likely want to turn on the verbose GnuTLS debugging options
> in the code, and also verify how the ESX server is configured and
> all your certificates
>
> In particular, by default GnuTLS will reject certificates issued by
> openssl which default to x509 v1, and thus lack the 'Basic Constraints'
> extension from x509 v3.
>
> Daniel
>

Well, yes that's the problem and it is the handshake. As I can tell
from Wireshark the client sends a RST package directly after the
Client Hello. So this is not certificate related or something like
that.

This problem also occurs with

  curl -kv https://www.google.com

and other HTTPS websites. This only happens when curl is compiled with
GnuTLS. curl compiled with OpenSSL or PolarSSL works just fine. Also
this only happens on Windows. I tried to find precompiled curl
binaries that use GnuTLS to check if the problem is in the way I
compile curl, but all binaries I could find use OpenSSL, even the
Fedora mingw32-curl package uses OpenSSL.

I traced the problem down to this libcurl commit

  https://github.com/bagder/curl/commit/fcccf9aa0d93c666e8ae31ebdde716cddd6b4482

from 2006. This commit makes sure that GnuTLS calls send() with the
MSG_NOSIGNAL flag to avoid SIGPIPE. If I revert this commit curl works
just fine with GnuTLS. Also this commit as is has no use on Windows,
because there is no MSG_NOSIGNAL flag for send() on Windows. But this
commit triggers the handshake problem and I didn't understand yet why
it does so.

Matthias