. > My trace results are attached. There is WSTrace and IPTrace output > for both HTTP and HTTPS plus IPTrace output for wget access of the > same URL. WGet uses a statically linked version of the OpenSSL > library, so it is no real evidence. However, I've tried the same with > the Links browser (which uses exactly the same DLL files) and the > beginning of the IPTrace output is identical to the IPTrace output > for WGet (I just didn't want to include IPTrace output for Links > because it is very long due to the fact that the original URL > redirects elsewhere, contains pictures, etc., and Links loads all of > this, of course, as opposed to the httpsend example or WGet). > > There is no handshake in the IP trace, however I don't think that it > proves the socket handle not being usable outside winsock due to the > other test performed and mentioned in my e-mail sent earlier today. The trace for wget does show the ssl handshake. It starts with packet #6. packet #8 and #9 is the google public key info. Packet #6 in https_iptrace is a ACK FIN which is the start of a tear down of the connection, initiated by the client. In http_iptrace, packet #6 is a send of the GET. Conclusion is that openssl from synapse didn't even start the ssl handshake.
> Interestingly, the return value for the initial call of the imported > _SSLLibraryInit is not checked in ssl_openssl_lib (i.e. it would not > be detected if it failed), but I checked it and it gives 1 (which I > assume is correct, although I know nothing about OpenSSL so this > assumption may be completely wrong). I also checked results of other > imported calls invoked before SSLConnect and SSLSetFD returns 1 and > SSLCtrl returns 0 (whatever these two mean - if nothing else, there > are no negative values returned which seems to suggest success). SSL_library_init always returns 1, whatever happens. The docs therefore also say to not test the return value. SSL_set_fd returning 1 means success (0 is failure). For SSL_ctrl the return value depends on the command parameter but 0 is in general an error. Is that the call with SSL_CTRL_SET_TLSEXT_HOSTNAME? Add a sslcheck after it to see what the error is. > SSLMethod* are all initialized. What's the right way for forcing > another SSLType? I can obviously add some hack to TSSLOpenSSL.Init > for this purpose, but I assume that there is some standard way for > selecting it. ;-) Before calling THTTPSend.HTTPMethod do a THTTPSend.Sock.SSL.SSLType:=LT_SSLv2; or any other TSSLType except for LT_SSHv2 which is not supported by openssl. > Looking again at the WSTrace - I assume that the AF_UNSPEC family is > OK there, right? Note that IPv6 is not supported for OS/2 / eCS > (again, I hope that this should not matter in any way, just to show > that I'm really out of ideas :/ ). I guess that is indeed OK. I'm a little out of ideas also. There is not a problem with calling convention? Another interesting test would be to run the following test program. It will call TSSLOpenSSL.CreateSelfSignedCert which makes a lot of openssl calls. Put a break point in the function and step through it to see if and when it breaks. If something is wrong with openssl, you'll probably won't get very far into the function without a sigsegv. CreateSelfSignedCert doesn't do a lot of error checking though. program openssltest; {$mode objfpc}{$H+} uses blcksock,ssl_openssl; var sock:TTCPBlockSocket; begin sock:=TTCPBlockSocket.Create; sock.bind('0.0.0.0','12345'); sock.ssl.Accept; end. The program doesn't do anything useful :) Ludo ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ synalist-public mailing list synalist-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synalist-public