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