Bug 1056650

Description of problem:
When using sslscan against a server that is configured to only allow requests based with a valid client SSL certificate (aka bi-directional authentication), and sslscan cannot offer such a certificate, sslscan will not report any results.

The TLS handshake agrees on the cipher as part of the Client/Server Hello and before the certificate authentication is completed. That means that for scanning a TLS server to see which ciphers are supported, there is NO need for a client certificate and even NO need for a successful TLS session establishment.

sslscan, however, seem to require a successful TLS session establishment before it reports the status on a connection. When reimplementing sslscan with a script as follows, the script will produce the intended output, whereas sslscan does not report status:

ciphers=$(openssl ciphers ALL | sed 's/:/ /g')
protos="ssl2 ssl3 tls1 tls1_1 tls1_2"

for p in $protos
do
        for c in $ciphers
        do
                openssl s_client -connect ${SERVER}:${PORT} -cipher ${c} -${p} > ${SERVER}.${c}.${p}
        done
done

Version-Release number of selected component (if applicable):

version 1.10.1 (and I guess all earlier versions)


How reproducible:
always


Steps to Reproduce:
1. Set up a server with bidirectional authentication requirement
2. sslscan <server>
3. Monitor output of sslscan

Actual results:
no scan results of supported ciphers

Expected results:
scan results with supported ciphers


Additional info:
N/A