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

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

 



2010/11/17 Daniel P. Berrange <berrange@xxxxxxxxxx>:
> On Wed, Nov 17, 2010 at 02:53:15PM +0100, Matthias Bolte wrote:
>> 2010/11/17 Justin Clift <jclift@xxxxxxxxxx>:
>> > 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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]