RE: SSL - Weak Encryption Test
From: owner-openssl-us...@openssl.org On Behalf Of Nouefel Sent: Tuesday, 01 March, 2011 21:26 Answering your questions: Are you even sure HOSTNAME:443 and HOSTNAME:8000 are the same host? Yes . Its a device . 2. 443 is disabled , Hence it disconnects. What you posted is a failure to connect (timeout). That's not the same thing as a disconnect. It is *a* reasonable thing to do for 'disabled' (though I don't think the best; I prefer to explicitly refuse). 3. 8000 is the port we used to communicate. I need to make sure device does not support weak security. Hence , I ran the openssl commands where for 8000 it connected and writeErr . And you don't know why. Try -msg or -debug as I said, that should at least narrow it down. If you have (other) access to the device, does it have relevant log information? But even if it rejects one particular weak handshake, that doesn't prove it will reject all. And even if it uses only strong ciphersuite(s), there are other ways for security to be weak or fail. Many other ways. You can prove it is capable of supporting strong crypto, which may or may not be strong security. You can't prove it doesn't support weak security, except by inspection. (And even then, if there are bugs/flaws the vendor missed, an outside examiner may not catch them either.) 4. when you say weak algorithm , We are using SSLV3 ciphers used SSL_RSA_WITH_RC4_128_SHA. Your posted cases don't show that, but if you are, that's usually good enough assuming RSA = 1024 bits, which isn't enforced by the protocol or by openssl; some people prefer the safety margin of 1536 or 2048. It's not the only good choice; there are many others. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL - Weak Encryption Test
Hi Answering your questions: Are you even sure HOSTNAME:443 and HOSTNAME:8000 are the same host? Yes . Its a device . 2. 443 is disabled , Hence it disconnects. 3. 8000 is the port we used to communicate. I need to make sure device does not support weak security. Hence , I ran the openssl commands where for 8000 it connected and writeErr . 4. when you say weak algorithm , We are using SSLV3 ciphers used SSL_RSA_WITH_RC4_128_SHA. Thanks Noufel Dave Thompson-5 wrote: From: owner-openssl-us...@openssl.org On Behalf Of Nouefel Sent: Monday, 28 February, 2011 19:10 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 Okay, so this is almost certainly Linux and that error means you didn't connect at all. You have NO information what the server supports. However, if ALL clients are like you unable to connect on 443 (see below) then it shouldn't matter if the server software contains support for weak ciphers (or other problems like SQL or script injection, crossdomain forgery, etc.) since no one can send the data that would exploit these problems. openssl s_client -connect HOSTNAME:8000 -cipher LOW:EXP CONNECTED(0003) write:errno=104 That's a bit odd; you connected and then got reset. It's especially odd to get it on write, unless maybe your random-gen for KeyExchange is extra slow or something. Depending on the server (particularly OS), this MAY indicate that the server is failing (e.g. crashing). Normally I would first suggest checking the server logs, but if you're trying to probe basic crypto from outside I'm guessing you don't have access to the logs. As I said, try with -msg (or -debug) to get details of the handshake process. That MAY get far enough to have some information about the crypto support of the server. So on 8000 it says connected but there is also an err. Where as first one times out as 443 port is not enabled. What exactly do you mean by port is not enabled? If there is simply no software listening on port N on a reachable host, connect normally fails with reset. The host might have rules or features to just discard connects (SYNs) on some port(s) e.g. 443 for any reason it likes, possibly to avoid scans or probes like yours. Or, there might be a firewall or similar device between you and the host which decides to discard 443, but let through 8000 -- maybe even to let through the SYNs for 8000 but then subsequently break the connection with RST, although that's rather rude. Are you even sure HOSTNAME:443 and HOSTNAME:8000 are the same host? First, one name can translate in DNS to different addresses at different times, although it is unlikely it would consistently translate to different values for your :443 attempts versus your :8000 ones. Second, a single address could be on a NAT-type box that routes different ports to different hosts; this is fairly common in today's network world. If this host belongs to your organization, or a business partner or something, they should be able to tell you how the network setup works, and quite possibly how the crypto is set up if that is your actual question. Admittedly in some (large) organizations, it can be a chore to find the correct person with such answers. If this host belongs to someone else, they may want you NOT to know this setup, which they may want to change without warning and without you knowing or noticing. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org -- View this message in context: http://old.nabble.com/SSL---Weak-Encryption-Test-tp31016002p31046126.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL - Weak Encryption Test
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(0003) 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 Listopenssl-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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL - Weak Encryption Test
From: owner-openssl-us...@openssl.org On Behalf Of Nouefel Sent: Monday, 28 February, 2011 19:10 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 Okay, so this is almost certainly Linux and that error means you didn't connect at all. You have NO information what the server supports. However, if ALL clients are like you unable to connect on 443 (see below) then it shouldn't matter if the server software contains support for weak ciphers (or other problems like SQL or script injection, crossdomain forgery, etc.) since no one can send the data that would exploit these problems. openssl s_client -connect HOSTNAME:8000 -cipher LOW:EXP CONNECTED(0003) write:errno=104 That's a bit odd; you connected and then got reset. It's especially odd to get it on write, unless maybe your random-gen for KeyExchange is extra slow or something. Depending on the server (particularly OS), this MAY indicate that the server is failing (e.g. crashing). Normally I would first suggest checking the server logs, but if you're trying to probe basic crypto from outside I'm guessing you don't have access to the logs. As I said, try with -msg (or -debug) to get details of the handshake process. That MAY get far enough to have some information about the crypto support of the server. So on 8000 it says connected but there is also an err. Where as first one times out as 443 port is not enabled. What exactly do you mean by port is not enabled? If there is simply no software listening on port N on a reachable host, connect normally fails with reset. The host might have rules or features to just discard connects (SYNs) on some port(s) e.g. 443 for any reason it likes, possibly to avoid scans or probes like yours. Or, there might be a firewall or similar device between you and the host which decides to discard 443, but let through 8000 -- maybe even to let through the SYNs for 8000 but then subsequently break the connection with RST, although that's rather rude. Are you even sure HOSTNAME:443 and HOSTNAME:8000 are the same host? First, one name can translate in DNS to different addresses at different times, although it is unlikely it would consistently translate to different values for your :443 attempts versus your :8000 ones. Second, a single address could be on a NAT-type box that routes different ports to different hosts; this is fairly common in today's network world. If this host belongs to your organization, or a business partner or something, they should be able to tell you how the network setup works, and quite possibly how the crypto is set up if that is your actual question. Admittedly in some (large) organizations, it can be a chore to find the correct person with such answers. If this host belongs to someone else, they may want you NOT to know this setup, which they may want to change without warning and without you knowing or noticing. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: SSL - Weak Encryption Test
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
