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

2010/11/17 Daniel P. Berrange <berrange(a)redhat.com&gt;: > On Wed, Nov 17, 2010 at 02:53:15PM +0100, Matthias Bolte wrote: >> 2010/11/17 Justin Clift <jclift(a)redhat.com&gt;: >> > 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/fcccf9aa0d93c666e8ae31ebdde716cddd6... 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.