Re: openssl s_client takes over 30 seconds to complete on Windows
Dave Thompson dthomp...@prinpay.com wrote: He could just do a: echo foo | openssl s_client -connect uri.com:443 cert.txt This executes in 1 sec here. What openssl build on what Windows? The one from the Msys package [1]. Running on Win-XP SP3. It has a special dependency as shown here: cygcheck g:\MingW32\msys\bin\openssl.exe G:\MingW32\msys\bin\openssl.exe g:\MingW32\msys\bin\msys-crypto-1.0.0.dll g:\MingW32\msys\bin\msys-1.0.dll f:\windows\system32\KERNEL32.dll f:\windows\system32\ntdll.dll g:\MingW32\msys\bin\msys-ssl-1.0.0.dll (non-standard OpenSSL dll-names). But this does give me an idea: the OP probably could install cygwin, and a cygwin build of openssl. cygwin tries to emulate Unix on Windows and select() is used commonly enough I expect it works. But cygwin is so big and complicated I don't bother with it myself, so I can't check. Not so big and much less complicated than OpenSSL itself :-( But msys is even smaller. [1] Ref. https://sourceforge.net/projects/mingw/files/MSYS/Extension/openssl/openssl-1.0.0-1/ --gv __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: openssl s_client takes over 30 seconds to complete on Windows
From: owner-openssl-us...@openssl.org On Behalf Of Gisle Vanem Sent: Saturday, 06 July, 2013 07:16 He could just do a: echo foo | openssl s_client -connect uri.com:443 cert.txt This executes in 1 sec here. What openssl build on what Windows? On my three Windows (XP SP3, Vista SP1, Server2008R2 SP1) the ShiningLight builds of 1.0.0j and 1.0.1c and also my own vc-win32+nasm (static) builds of those versions all hang for echo foo | as I said before. I can't test a lot of old versions, but this section of code in apps/s_client.c doesn't appear to have changed for at least 5 years, and this part of WinAPI definitely hasn't changed in about 15 years. As for the suggestion /dev/null by Rich Salz: that won't even start on windows. The Windows equivalent NUL: (colon optional but recommended for clarity) hangs the same way; as in Unix it's equivalent to file_that_is_empty . But this does give me an idea: the OP probably could install cygwin, and a cygwin build of openssl. cygwin tries to emulate Unix on Windows and select() is used commonly enough I expect it works. But cygwin is so big and complicated I don't bother with it myself, so I can't check. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: openssl s_client takes over 30 seconds to complete on Windows
echo foo | openssl s_client -connect uri.com:443 cert.txt Or perhaps simpler openssl s_client -connect uri.com:443 cert.txt /dev/null -- Principal Security Engineer Akamai Technology Cambridge, MA __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl s_client takes over 30 seconds to complete on Windows
Dave Thompson dthomp...@prinpay.com wrote: I don't see a simple fix. What you could do is write a simple program that connects to the desired host, if successful gets the peer cert and writes it out, and (always immediately) closes and exits -- or just exits and lets the OS-level TCP disconnect force a close. He could just do a: echo foo | openssl s_client -connect uri.com:443 cert.txt This executes in 1 sec here. --gv __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl s_client takes over 30 seconds to complete on Windows
I have a need to periodically extract a certificate from another automated process and not being a Windows programmer (I work in a different programming discipline) I find that a command line 'openssl s_client -connect uri.com:443 cert.txt' does exactly what I need it to do. In AIX (our preferred version of Unix) this executes and returns to the command line in less than 1 second. In Windows however, this executes, whites out the text file in under a second but the openssl command itself does not return to the command line for another 28 to 30 seconds. Since we are operating synchronously, this imposes a significant delay on our processing__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: openssl s_client takes over 30 seconds to complete on Windows
From: owner-openssl-us...@openssl.org On Behalf Of Graham, Dave Sent: Friday, 05 July, 2013 10:47 I have a need to periodically extract a certificate from another automated process and not being a Windows programmer (I work in a different programming discipline) I find that a command line 'openssl s_client -connect uri.com:443 cert.txt' does exactly what I need it to do. In AIX (our preferred version of Unix) this executes and returns to the command line in less than 1 second. In Windows however, this executes, whites out the text file in under a second but the openssl command itself does not return to the command line for another 28 to 30 seconds. Since we are operating synchronously, this imposes a significant delay on our processing (I assume whites out is a typo for writes out. If not, you have one really weird filesystem!) The command you show does not redirect input, so on all OSes it should wait until the user types something or the server decides to disconnect; 443 implies an HTTPS server most of which will timeout after some period of time with no request, but I would be astonished if it varies depending on the OS or even openssl version from which the connection comes. If you actually redirected input from a diskfile which always has EOF, reached very fast for a small -- or empty -- file; or a pipe which has EOF quickly i.e. write side NOT held open by some long-running process; or /dev/null which always has EOF immediately; then on Unix s_client will promptly close the connection (gracefully if possible) and exit. On my older Windows input redirection seems to hang until a key is hit -- even though that key isn't used or apparently even read -- so you are probably waiting until a server timeout of 30sec. I'll guess this is because WaitForSingleObject doesn't treat a diskfile or full pipe as 'notified' (unlike a console), whereas Unix select() does treat them as 'ready' (like a tty). Winsock select only works for sockets. I don't see a simple fix. What you could do is write a simple program that connects to the desired host, if successful gets the peer cert and writes it out, and (always immediately) closes and exits -- or just exits and lets the OS-level TCP disconnect force a close. If you use connect-BIO I'm pretty sure it will hide the small but annoying differences between Unix BSDsock and Winsock (about 20 lines of #if'ed crud in my code). If you don't support the numerous options s_client does -- or very few -- the rest is only maybe 30 lines. Alternatively I have heard of (but not used) 3rd-party utilities for Windows which simulate user input on GUIs (i.e. enter some data as if you had typed it, invoke a menu or popup action as if you had clicked it, etc.) These (or some) might fake console input too, I don't know. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
