mailing list archives
Re: SSL 2.0 enabled or disabled?
From: Rogan Dawes <discard () dawes za net>
Date: Fri, 21 May 2004 08:06:37 +0200
You're absolutely correct. I guess I didn't elaborate that one should
for i in `openssl ciphers | sed 's/:/ /'`; do
cat request | openssl s_client -ign_eof -cipher $i > response.$i
where request is a well-formed http request for the page in question. By
comparing the various files that result (some will be 0 bytes, some will
contain a redirect, etc, and some will contain the expected response),
you can determine which ciphers were accepted and which were not.
Dimitris Petropoulos wrote:
Of course, if you're going to try it that way, it is easier
to write a
little script that iterates through the list of ciphers that OpenSSL
knows about (openssl ciphers) and then use openssl to connect to the
server in question with that specific cipher.
Yes, that's even better if you want automation. However, there are cases
where this might not always provide accurate results: some sites that
require strong SSL/TLS ciphersuites will allow you to connect using a
weak ciphersuite only to send you to a help/error page informing you
that the SSL/TLS ciphersuite you used to connect was not strong enough
to allow you access (a better practice than dropping the connection
without any explanation)... In technical terms, in those cases the
client and the server will exchange ChangeCipherSpec messages and the
client will send the HTTP request encrypted under the weak ciphersuite
session key, to which the server will probably reply with a 403 message,
rather than sending an SSL/TLS alert (with insufficient_security or
handshake_failure alert description) during the handshake phase, which
would seem the normal reply to the client since the ciphersuite is not
amongst the supported ones,
*ALL* messages to discard () dawes za net will be dropped, and added
to my blacklist. Please respond to "lists AT dawes DOT za DOT net"