Hi Openssl version - OpenSSL 0.9.8l 5 Nov 2009
Now regarding the commands and their results : openssl s_client -connect HOSTNAME:443 -cipher LOW:EXP connect: Connection timed out connect:errno=110 openssl s_client -connect HOSTNAME:8000 -cipher LOW:EXP CONNECTED(00000003) write:errno=104 So on 8000 it says connected but there is also an err. Where as first one times out as 443 port is not enabled. Does this mean the server does not support WEAK ciphers. Thanks Noufel Dave Thompson-5 wrote: > >> From: owner-openssl-us...@openssl.org On Behalf Of Nouefel >> Sent: Friday, 25 February, 2011 15:08 > >> Need some help on testing if a server supports weak ciphers . >> >> Here is the command I ran : >> >> openssl s_client -connect HOSTNAME:443 -cipher LOW:EXP >> >> result : >> Connected : err num=110 >> >> openssl s_client -connect HOSTNAME:8000 -cipher LOW:EXP >> result : >> Connected : err num=104 >> > What (version of) openssl are you using? I've never seen one > (in almost ten years) that produces output in that format. > 'openssl version' or even 'openssl version -a' may be helpful, > although if this copy has been hacked up it might not > truthfully indicate its status in its version string(s). > Did you get it from anyplace other than: the OS supplier, > or the www.openssl.org website or an authorized mirror, > or another trustworthy packager like ShiningLight? > >> Should I understand that the host does not support weak >> ciphers with above result. >> > Does it really say 'Connected' and not just 'connect'? > The latter would be almost correct for a connection attempt > that fails at TCP level, before starting SSL/TLS handshake. > On the one Linux system I have to hand, 110 is ETIMEDOUT > and 104 is ECONNRESET, which are the two most common > errors (by far) on failed TCP connection attempts. > (On other operating systems, error codes are different; > the existence of some errors is standard but not the codes.) > > In the Good Old Days it was effectively impossible to get > timeout and reset for different ports *on the same host*; > you said 'a' server so I assume there's only one. > But nowadays with lots of network infrastructure trying > to be 'smart' and even 'helpful' the diagnostics you get > are often misleading and sometimes even deceptive. > > If on Unix or an older Windows (or a newer Windows you > have fixed appropriately) try telnet (or equivalent) > from your (desired) client to the server to make sure TCP > connectivity works. If it doesn't, try traceroute (Windows > tracert) or other network tools to look for the problem. > And/or try a client as close to the server as possible > (either use as client a system that is already there, > or move your client system to be there). (If it does connect, > for standard telnet client just do ctrl-] q u i t RET.) > > If you do have connectivity, try s_client with -msg added > (or -debug which is more verbose) and post what you get, > at least the last good message and any subsequent error(s). > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > > -- View this message in context: http://old.nabble.com/SSL---Weak-Encryption-Test-tp31016002p31036911.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
