From the scan, I found that DES encryption isn't marked as RED. This cipher is known of cryptanalysis and brute-force attacks (only 56 bit encryption).

I tried to compile the Application on OpenBSD using LibreSSL.
LibreSSL does not support everything OpenSSL supports. An example would be the compression or NIST/SSLv2.

The following Errors where reported by GCC:

gcc -lssl -o sslscan sslscan.c

sslscan.c: In function 'testCompression':
sslscan.c:746: error: 'SSL_SESSION' has no member named 'compress_meth'
sslscan.c:749: error: 'SSL_SESSION' has no member named 'compress_meth'
sslscan.c: In function 'ssl_print_tmp_key':
sslscan.c:1158: warning: assignment makes pointer from integer without a cast
sslscan.c: In function 'main':
sslscan.c:3116: error: 'VERSION' undeclared (first use in this function)
sslscan.c:3116: error: (Each undeclared identifier is reported only once
sslscan.c:3116: error: for each function it appears in.)

I want to suggest an additional feature of highlight CBC ciphers on TLS 1.0 and lower as vulnerable to BEAST

I have not been able to get the latest version to complete a scan with --starttls-smtp (with or without --bugs). I have attached a copy of both invocations, --verbose did not yeild any extra info. Test system debian/unstable amd64:

(master %):dfc@ronin:~/0xRepos/Cypherpunks/sslscan$ ./sslscan --starttls-smtp  aspmx.l.google.com:25
Version: 1.9.2-rbsec
OpenSSL 1.0.1h-dev xx XXX xxxx

OpenSSL version does not support SSLv2
SSLv2 ciphers will not be detected

Testing SSL server aspmx.l.google.com on port 25

  TLS renegotiation:
    ERROR: The SMTP service on aspmx.l.google.com port 25 did not appear to support STARTTLS.
ERROR: Could not connect.
(master %):dfc@ronin:~/0xRepos/Cypherpunks/sslscan$ ./sslscan --starttls-smtp  --bugs aspmx.l.google.com:25
Version: 1.9.2-rbsec
OpenSSL 1.0.1h-dev xx XXX xxxx

OpenSSL version does not support SSLv2
SSLv2 ciphers will not be detected

Testing SSL server aspmx.l.google.com on port 25

  TLS renegotiation:
    ERROR: The SMTP service on aspmx.l.google.com port 25 did not appear to support STARTTLS.
ERROR: Could not connect.

Somtimes cipher suites hide the details example 'AES128-SHA' is actually 'TLS_RSA_WITH_AES_128_CBC_SHA' However CBC is a keyword which gets missed. similarly other cipher suites also miss out these key details.

Is there a possibility that we can provide the link name of these cipher suites which will ensure grepping etc on the output would give us correct details.

Please adjust the make file in line 83 for OS X compilation:

cd ./openssl; ./Configure darwin64-x86_64-cc

-->

cd ./openssl; ./Configure darwin64-x86_64-cc no-shares enable-weak-ssl-ciphers enable-ssl2 zlib

Hi there,

I have noticed on a number of tests that the signature algorithm is being reportedly incorrectly. Seems to happen when there is more than one signature on a cert, for example a SHA1 and a SHA256. When this is the case, it only reports the first signature algorithm on the cert and as a result it looks like the cert is weaker than it really is.

Please can the output include all signature algorithms?

Thanks!

After successful make static

$ sudo make -B install PREFIX=/usr/local
Password:
install -D sslscan /usr/local/bin/sslscan;
install: illegal option -- D
usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
               [-o owner] file1 file2
       install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
               [-o owner] file1 ... fileN directory
       install -d [-v] [-g group] [-m mode] [-o owner] directory ...
make: *** [install] Error 64

Some hosts seem to be overwhelmed by the requests of sslscan.

If i run ./sslscan --starttls-smtp --failed 68.232.139.67 then it stops after a couple of tested ciphers and shows the message "Resource temporarily unavailable". Sometimes it happens ealier, sometimes later.

In such a case it could help to wait few seconds and retry the failed cipher. Any other ideas?

This request command line:

$ sslscan            \
  --no-ciphersuites  \
  --no-renegotiation \
  --no-compression   \
  --starttls-smtp    \
  '[2a01:238:433d:6500:8c6a:e6c8:f682:fa74]'

produces this result:

...
  Heartbleed:
TLS 1.0 vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.2 not vulnerable to heartbleed

But when I compare to the output of check-ssl-heartbleed.pl (e.g. noxxi/p5-scripts), I get this result:

$ ./heartbleed.pl --starttls smtp '[2a01:238:433d:6500:8c6a:e6c8:f682:fa74]'
...reply to starttls: 220 2.0.0 Ready to start TLS
...ssl received type=22 ver=0x301 ht=0x2 size=90
...ssl received type=22 ver=0x301 ht=0xb size=3743
...ssl received type=22 ver=0x301 ht=0xc size=359
...ssl received type=22 ver=0x301 ht=0xe size=0
...send heartbeat_
no reply - probably not vulnerable

... so... do you have an idea which is the correct answer?

--Dominik

Hearbleed test repeats the same test for all TLS versions.
The testHeartbleed function opens a raw TCP socket, then sends a hardcoded clientHello message:
char hello[] = {0x16,0x03,0x02,0x00...

This ClientHello message also contains a hardcoded TLS version numbers. The output indicates that TLS version 1.0, 1.1 and 1.2 are tested, when the same test (TLS 1.1) is executed three times.

This likely also applies to the hardcoded Heartbeat message.

please add indicators like weak, good, ok or risky to xml output of cipher suites.

The following line results in The SMTP service on 217.69.254.95 port 25 did not appear to support STARTTLS:

sslscan --starttls-smtp 217.69.254.95

It works well with openssl s_client:

openssl s_client -starttls smtp -connect 217.69.254.95:25

Hi,

First off: thank you so much for keeping sslscan alive and up to date.

Could you provide a windows binary? I've spent a few days now getting a MVS2013 project set up and running, and it even now is able to compile, but there are problems with gethostbyname2(), and I'm not familiar enough with the your codebase and the differences between POSIX and WinSock to the point where I can make the conversion.

Hello.
My sslscan (1.10.4-rbsec-wip, OpenSSL 1.0.2a 19 Mar 2015, built today) segfaults when I run it with thoses options: sslscan --xml=./cloudflare.com.xml cloudflare.com

Here is the relevant output from valgrind, when it happens:

==22784== Use of uninitialised value of size 8
==22784==    at 0x4C2E543: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22784==    by 0x40740B: checkCertificate (sslscan.c:1877)
==22784==    by 0x409A84: testHost (sslscan.c:2792)
==22784==    by 0x40B2A9: main (sslscan.c:3301)
==22784== 
==22784== Invalid read of size 1
==22784==    at 0x4C2E543: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22784==    by 0x40740B: checkCertificate (sslscan.c:1877)
==22784==    by 0x409A84: testHost (sslscan.c:2792)
==22784==    by 0x40B2A9: main (sslscan.c:3301)
==22784==  Address 0x4058cb740 is not stack'd, malloc'd or (recently) free'd
==22784== 
==22784== 
==22784== Process terminating with default action of signal 11 (SIGSEGV)
==22784==  Access not within mapped region at address 0x4058CB740
==22784==    at 0x4C2E543: strcmp (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==22784==    by 0x40740B: checkCertificate (sslscan.c:1877)
==22784==    by 0x409A84: testHost (sslscan.c:2792)
==22784==    by 0x40B2A9: main (sslscan.c:3301)
==22784==  If you believe this happened as a result of a stack
==22784==  overflow in your program's main thread (unlikely but
==22784==  possible), you can try to increase the size of the
==22784==  main thread stack using the --main-stacksize= flag.
==22784==  The main thread stack size used in this run was 8388608.

Hi, the last tag on git was 1.10.11, but it looks like it should have been numbered 1.11.1 (at least according to commits and Changelog).

sslscan 1.8.2 on linux mint 17.3
sslscan secure.st-willi.de | grep "40 bits"
Rejected SSLv3 40 bits EXP-EDH-RSA-DES-CBC-SHA
Rejected SSLv3 40 bits EXP-EDH-DSS-DES-CBC-SHA
Rejected SSLv3 40 bits EXP-ADH-DES-CBC-SHA
Rejected SSLv3 40 bits EXP-DES-CBC-SHA
Rejected SSLv3 40 bits EXP-RC2-CBC-MD5
Rejected SSLv3 40 bits EXP-ADH-RC4-MD5
Rejected SSLv3 40 bits EXP-RC4-MD5
Rejected TLSv1 40 bits EXP-EDH-RSA-DES-CBC-SHA
Rejected TLSv1 40 bits EXP-EDH-DSS-DES-CBC-SHA
Rejected TLSv1 40 bits EXP-ADH-DES-CBC-SHA
Rejected TLSv1 40 bits EXP-DES-CBC-SHA
Rejected TLSv1 40 bits EXP-RC2-CBC-MD5
Rejected TLSv1 40 bits EXP-ADH-RC4-MD5
Rejected TLSv1 40 bits EXP-RC4-MD5

sslscan 1.11.1-rbsec-5-g13488b2 on OS X
sslscan secure.st-willi.de | grep "40"
Accepted TLSv1.0 40 bits EXP-DES-CBC-SHA RSA 512 bits
Accepted TLSv1.0 40 bits EXP-RC2-CBC-MD5 RSA 512 bits
Accepted TLSv1.0 40 bits EXP-RC4-MD5 RSA 512 bits

You see, that all that is accepted by the scan in OS X is rejected in the scan in linux.

Which one is right?

To make screenshots for pentesting reports, it would be convenient to only show the problematic items. For example, if the TLS Renegotiation, TLS Compression, and Heartbleed detection come back ok, perhaps they could be hidden, to allow the screenshot to not be an entire screen of text.

Obviously, this would not want to be done all the time, so it would be convenient to have an argument that could be passed to allow it.

A support for SSH would be very helpful.

Since it looks like a large amount of the certificate data has been removed from this version, it'd be worthwhile to show if a certificate is self-signed, similar to how the TLS Renegotiation, TLS Compression, and Heartbleed detections work.

I would imagine something like:

➜  sslscan git:(master) ✗ ./sslscan 10.0.0.1
Version: 1.9.8-rbsec-wip-static
OpenSSL 1.0.1j 15 Oct 2014

Testing SSL server 10.0.0.1 on port 443

  TLS renegotiation:
Secure session renegotiation supported

  TLS Compression:
Compression disabled

  Heartbleed:
TLS 1.0 not vulnerable to heartbleed
TLS 1.1 not vulnerable to heartbleed
TLS 1.2 not vulnerable to heartbleed

  Certificate signature:
Self-signed

  Supported Server Cipher(s):
Accepted  SSLv3    256 bits  DHE-RSA-CAMELLIA256-SHA
Accepted  SSLv3    256 bits  AES256-SHA
Accepted  SSLv3    256 bits  CAMELLIA256-SHA
Accepted  SSLv3    128 bits  DHE-RSA-AES128-SHA
Accepted  SSLv3    128 bits  DHE-RSA-CAMELLIA128-SHA
Accepted  SSLv3    128 bits  AES128-SHA
Accepted  SSLv3    128 bits  CAMELLIA128-SHA

Add XML output for the OCSP info in #48

Add IPv6 support to sslscan.

Trying to scan an SMTP server I used the following command line and scratched my head why this did not respond at all:

sslscan --show-certificate --starttls-smtp mail.example.host:smtp

Looking at the traffic trace shows that sslscan tries to connect to port 0 in this case. Using "mail.example.host:25" does work as expected, so there is an easy workaround. It would be nice to support service names for the port argument similar to tools like telnet, but otherwise it would probably be better to error out when the port isn't numeric to avoid confusion.

Really great that you've improved and incorporated other updates to the original sslscan. While this gives the top preferred cipher for each protocol, the remaining ciphers are just listed in the order they are checked. Ideally there would be an option to determine the full cipher preference order for a server, ordered from most preferred to least (assuming server cipher preference enforcement is enabled)

Appreciate this might be a good bit of work and a lot of requests to the server to determine but figured it wouldn't hurt to ask.

It'd be nice if sslscan flagged the use of MD5/SHA-1 to sign SSL Certificates.

Hi,
I'm using this script to compile and install sslscan on OS X:

#!/bin/bash

TEMPDIR=~/.compilesslscan

rm -Rf $TEMPDIR

mkdir $TEMPDIR
cd $TEMPDIR

git clone https://github.com/rbsec/sslscan.git

cd sslscan

make static
sudo make -B install

rm -Rf $TEMPDIR
sslscan --version

Everything works fine, except
sudo make -B install
fails:
cp sslscan /usr/bin/
cp: /usr/bin/sslscan: Operation not permitted
In OS X 10.11 it is is not allowed to to change the content of /user/bin.
But from what I see, /usr/local/bin is possible and it is in the PATH environment.

Windows 8.1 Enterprise.
Used: https://github.com/rbsec/sslscan/releases/download/1.10.0-rbsec/sslscan-win-1.10.0-rbsec.zip

I've got some issues with the --starttls-ftp function. When I try to test it on a server with vsftpd, it gives me this output:

Any Ideas?

EDIT:

Added environment info

A option to only list red and yellow marked ciphers and only list out compression and simmilar if its vulnerable.

$ sudo make install
install -d sslscan /usr/bin/sslscan;
install: sslscan exists but is not a directory
make: *** [install] Error 71

It worked perfectly without the -d option, but 6c5f8b1 broke it for me.

I need to stream the XML output directly to stdout to parse it while the process is running. If I run the program with --xml=/dev/stdout than the XML output is mixed into the current output on stdout.

What do you think of a --quiet argument that supresses all other information except XML on stdout? Another option is to set the level of verbosity like --verbose=0 (no ouput), --verbose=1 (default) and --verbose=2 (the current verbose).

I was able to get it built on OSX by:

brew install openssl

And the following changes to the Makefile:

diff --git a/Makefile b/Makefile
index df6546c..76d4497 100644
--- a/Makefile
+++ b/Makefile
@@ -18,8 +18,8 @@ WARNINGS = -Wall -Wformat=2
DEFINES = -DVERSION="$(GIT_VERSION)"

for dynamic linkung

-LDFLAGS = -L/usr/local/ssl/lib/
-CFLAGS = -I/usr/local/ssl/include/ -I/usr/local/ssl/include/openssl/
+LDFLAGS = -L/usr/local/opt/openssl/lib
+CFLAGS = -I/usr/local/opt/openssl/include
LIBS = -lssl -lcrypto

for static linking

I'm not versed in how best to share this, or I'd do a pull request. Appreciate help from anyone!

SO, I get that "red" is for insecure, "yellow" if for weak, but now I got purple on some ADH and EXP ciphers, what does purple stands for ?

Maybe for each scan before the ciphers do a
red - insecure
yellow - weak
purple etc..
?

I just tried the following command
sslscan --bugs --verbose --failed --show-client-cas --show-certificate www.networking4all.com

One X509v3 extension that it may contain is the "1.3.6.1.4.1.11129.2.4.2".
This extension contains a certificate with embeded SCT (signed certificate timestamp)

https://github.com/google/certificate-transparency/blob/master/test/testdata/README

The output for this specific ssl certificate on the command line is

......u.......X......gp
.....K_..|.....F0D. lc.O.s.......}=S(..:...Hj..(..... .r....g.M...0.eRZ4.sQ[......|[email protected].../.......D.>.Fv....\....U.......K_..3.....H0F.!.....Z[.qn. .A....fcl).1..d...n.Y.!....i......*...K.).{...z*!4K..z..

On the xml output is different

......u.......X......gp
<5.......w...
.....K_..|.....F0D. lc.O.s.......}=S(..:...Hj..(.....
.r....g.M...0.eRZ4.sQ[......|[email protected].../.......D.>.Fv....\....U.......K_..3.....H0F.!.....Z[.qn.
.A....fcl).1..d...n.Y.!....i......*...K.).{...z*!4K..z..

As you can see it contains a "<" on the second line which breaks the xml output.

I suggest that maybe the output is escaped for xml output or maybe another solution

I have strange 30s pauses in between tests of cipher suits:

https://www.cloudshark.org/captures/2ec3e51ce9a7

Have a look at number 63.

This happens only in ipv4, with ipv6 this does not happen.

This is the command I run:

./sslscan --failed --ipv4 ssl-stats.hacked.jp

I'm using sslscan on ssl-stats.hacked.jp to scan a large number of sites and put the results in a database. But scanning needs to be as fast and a 30s skip is not so good :(

Any Idea what might cause this?

I'm simply wondering what versions of TLS SSLScan scans for. The scan results specify SSL2 and SSL3, but only lists "TLS" for TLS. We want to be able to test for TLS v1 and TLS v1.1.

Debian doesn't have build-essentials rather it has build-essential notice non existing s in the end.

https://packages.debian.org/search?keywords=build-essential&searchon=names&suite=stable&section=all

https://packages.debian.org/search?keywords=build-essentials&searchon=names&suite=stable&section=all

A note for this would help.

I did some digging into the new logjam vulnerability and found that all EXPORT ciphers are vulnerable so i guess this should be a check in the scan.

Also the default DHE ciphers with small parameters are weak.

I could not figure out how to test for the small parameters.

I don't see any expiration date on the validation output, is that something already implemented?

Hi,

Thanks for the awesome tool :)

Any plans to release stable version of SSLscan? It long time from last release. Also could you please include 32 bit and 64 bit version.

Thanks
Aditya Agrawal

Hi,
the new version does not compile on OS X anymore.

This is the output:

$ git clone https://github.com/rbsec/sslscan.git
Cloning into 'sslscan'...
remote: Counting objects: 1141, done.
remote: Compressing objects: 100% (35/35), done.
remote: Total 1141 (delta 18), reused 0 (delta 0), pack-reused 1106
Receiving objects: 100% (1141/1141), 488.18 KiB | 0 bytes/s, done.
Resolving deltas: 100% (717/717), done.
Checking connectivity... done.

$ cd sslscan
$ make static
if [ -d openssl -a -d openssl/.git ]; then
cd ./openssl && git checkout OpenSSL_1_0_2-stable && git pull | grep -q "Already up-to-date." && [ -e ../.openssl.is.fresh ] || touch ../.openssl.is.fresh ;
else
git clone https://github.com/openssl/openssl ./openssl && cd ./openssl && git checkout OpenSSL_1_0_2-stable && touch ../.openssl.is.fresh ;
fi
Cloning into './openssl'...
remote: Counting objects: 189721, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 189721 (delta 1), reused 0 (delta 0), pack-reused 189716
Receiving objects: 100% (189721/189721), 81.46 MiB | 11.14 MiB/s, done.
Resolving deltas: 100% (150246/150246), done.
Checking connectivity... done.
Branch OpenSSL_1_0_2-stable set up to track remote branch OpenSSL_1_0_2-stable from origin.
Switched to a new branch 'OpenSSL_1_0_2-stable'
sed -i 's/# if 0/# if 1/g' openssl/ssl/s2_lib.c
sed: 1: "openssl/ssl/s2_lib.c": invalid command code o
make: *** [opensslpull] Error 1

Can we also have time in miliseconds / seconds for handshake of each of the ciphers. Might help in prioritising which cipher might be a quicker one.

I know this is not a security specific request but something which might help, so if its low priority for you that's fine.

Hello @rbsec,

Well first, let me thank you for bringing back the good old sslscan tool.

Then, I'm suggesting a new option which could allow the user to specify a custom trail of bytes to kickstart an explicit TLS connection: I'm facing more and more that situation, mostly for proprietary protocols which are not based on starttls or equivalent.

The idea is to be able to assess the security of ciphersuites for such TLS implementations, by replaying the observed (through wireshark/tcpdump) sequence of bytes needed to kickstart the further TLS session.
From my experience, this sequence of custom is often invariable, and basically plays the role of a dumb starttls command.

To be clear, I'm thinking about an option that could look like that:
--kickstart \x00\x11\x22\x33... (or whatever else format to specify bytes)

Do you find that useful ? Do you think you could implement it ?

Cheers !

When trying to run sslscan.exe from the command line I receive the below message which seems to point towards the exe isn't compatible with Windows 8.1.

This version of C:\Users\Ashley\Downloads\sslscan-win-1.10.0-rbsec\sslscan.exe is not compatible with the version of Windows that you're running. Check your computer's system information and then contact the software publisher.

In http://git.kali.org/gitweb/?p=packages/sslscan.git;a=tree;f=debian/patches;h=0e998c170e55127ca5878f6d380b5daa8ad89127;hb=HEAD you will find 3 patches that we need to create a proper Kali package:

• Fix-clean-test.patch: this ensures that "make clean" doesn't fail when there's no openssl directory
• Fix-flags.patch: this preserves the user-supplied CFLAGS/LDFLAGS so that hardening build flags can be injected by the packaging tools. In fact you should also include ${CPPFLAGS} in your sslscan compilation command-line...
• Fix-install-path.patch: this makes it possible for us to do "make install DESTDIR=debian/sslscan" and get the files installed in the package build directory (this variable is standardized in autoconf/automake generated makefiles).

It would be nice if you could include those improvements.

Hi,

tested a private server for SSLv2 "forced" ciphers (not using --bugs gives the same output):

# /usr/local/src/sslscan-master/sslscan --ipv4 --no-colour --no-renegotiation --no-compression --no-check-certificate --ssl2 --verbose --bugs 10.10.10.9:5061
Version: 1.11.3-static
OpenSSL 1.0.2h-dev  xx XXX xxxx

Testing SSL server 10.10.10.9 on port 5061

  Heartbleed:
All TLS protocols disabled, cannot check for heartbleed.

  Supported Server Cipher(s):
SSL_get_error(ssl, cipherStatus) said: 1

While the same server (and same port) using tlsfuzzer (https://github.com/tomato42/tlsfuzzer) (removed SSLv3 output):

# PYTHONPATH=. python /usr/local/src/tlsfuzzer/scripts/test-sslv2-force-cipher.py -h 10.10.10.9 -p 5061
Connect with SSLv2 IDEA-CBC-MD5 ...
OK

Connect with SSLv2 EXP-RC4-MD5 ...
Error encountered while processing node <tlsfuzzer.expect.ExpectSSL2Alert object at 0x7f019d28ad90> (child: <tlsfuzzer.expect.ExpectClose object at 0x7f019d28ae10>) with last message being: <tlslite.messages.Message object at 0x7f019d290610>
Error while processing
Traceback (most recent call last):
  File "/usr/local/src/tlsfuzzer/scripts/test-sslv2-force-cipher.py", line 114, in main
    runner.run()
  File "/usr/local/src/tlsfuzzer/tlsfuzzer/runner.py", line 151, in run  RecordHeader2)))
AssertionError: Unexpected message from peer: Handshake(111)

Connect with SSLv2 DES-CBC3-MD5 ...
Error encountered while processing node <tlsfuzzer.expect.ExpectSSL2Alert object at 0x7f019d284e10> (child: <tlsfuzzer.expect.ExpectClose object at 0x7f019d284e90>) with last message being: <tlslite.messages.Message object at 0x7f019d238550>
Error while processing
Traceback (most recent call last):
  File "/usr/local/src/tlsfuzzer/scripts/test-sslv2-force-cipher.py", line 114, in main
    runner.run()
  File "/usr/local/src/tlsfuzzer/tlsfuzzer/runner.py", line 151, in run  RecordHeader2)))
AssertionError: Unexpected message from peer: Handshake(239)

Connect with SSLv2 EXP-RC2-CBC-MD5 ...
OK

Connect with SSLv2 RC2-CBC-MD5 ...
OK

Connect with SSLv2 RC4-MD5 ...
Error encountered while processing node <tlsfuzzer.expect.ExpectSSL2Alert object at 0x7f019d28a150> (child: <tlsfuzzer.expect.ExpectClose object at 0x7f019d28a1d0>) with last message being: <tlslite.messages.Message object at 0x7f019d2a5d10>
Error while processing
Traceback (most recent call last):
  File "/usr/local/src/tlsfuzzer/scripts/test-sslv2-force-cipher.py", line 114, in main
    runner.run()
  File "/usr/local/src/tlsfuzzer/tlsfuzzer/runner.py", line 151, in run  RecordHeader2)))
AssertionError: Unexpected message from peer: Handshake(203)


Connect with SSLv2 DES-CBC-MD5 ...
Error encountered while processing node <tlsfuzzer.expect.ExpectSSL2Alert object at 0x7f019d28aa90> (child: <tlsfuzzer.expect.ExpectClose object at 0x7f019d28ab10>) with last message being: <tlslite.messages.Message object at 0x7f019d2385d0>
Error while processing
Traceback (most recent call last):
  File "/usr/local/src/tlsfuzzer/scripts/test-sslv2-force-cipher.py", line 114, in main
    runner.run()
  File "/usr/local/src/tlsfuzzer/tlsfuzzer/runner.py", line 151, in run  RecordHeader2)))
AssertionError: Unexpected message from peer: Handshake(200)

Note: SSLv2 was officially deprecated (MUST NOT use) in 2011, see
      RFC 6176.
      If one or more of the tests fails because of error in form of

      Unexpected message from peer: Handshake()

      With any number inside parethensis, and the server is
      configured to not support SSLv2, it means it most
      likely is vulnerable to CVE-2015-3197.
      In case it's a RC4 or 3DES cipher, you may verify that it
      really supports it using:
      test-sslv2-connection.py

Test end
successful: 17
failed: 4

As you can see some ciphers handshake are aborted while others are allowed.

Unfortunately I'm not allowed to provide some kind of info (it depends), hope this helps.

I can't compile even you add the extra flags. it still struck at the first PATH for both LDFLAGS and CFLAGS as shown below.

❯ make
cc -o sslscan -Wall -Wformat=2 -L/usr/local/opt/openssl/lib -L/usr/local/ssl/lib/   -I/usr/local/opt/openssl/include -I/usr/local/ssl/include/ -I/usr/local/ssl/include/openssl/    -DVERSION=\"1.10.6-rbsec-2-gc980c00-wip\" sslscan.c -lssl -lcrypto
ld: warning: directory not found for option '-L/usr/local/ssl/lib/'

also I have a problem with make static that the architecture not found as shown below.

ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [sslscan] Error 1
make: *** [static] Error 2

The workaround for me is just make command and comment put only the available path for both flags.

Did I miss anything during the installation?

If a specific TLS version is specified on the command line, e.g. --tls12, and that version of TLS is not supported by the server, an error message is displayed which reads Failed to connect to get certificate. Most likley cause is server not supporting TLSv1.0, try manually specifying version. However, it may not be TLS v1.0 that was selected at the command line.

The error message should include the version of TLS that was used, rather than the hard-coded value of "1.0".

The final version is against
OpenSSL 1.0.2h-dev xx XXX xxxx

Should it not by against that version
OpenSSL 1.0.2g 1 Mar 2016

Is there a problem if the if-statement in the make-file?

$ git clone https://github.com/rbsec/sslscan.git
Cloning into 'sslscan'...
remote: Counting objects: 1191, done.
remote: Total 1191 (delta 0), reused 0 (delta 0), pack-reused 1191
Receiving objects: 100% (1191/1191), 474.71 KiB | 0 bytes/s, done.
Resolving deltas: 100% (756/756), done.
Checking connectivity... done.
$ cd sslscan
$ make static
if [ -d openssl -a -d openssl/.git ]; then \
        cd ./openssl && git checkout OpenSSL_1_0_2-stable && git pull | grep -q "Already up-to-date." && [ -e ../.openssl.is.fresh ] || touch ../.openssl.is.fresh ; \
    else \
        git clone --depth 1 -b OpenSSL_1_0_2-stable https://github.com/openssl/openssl ./openssl && cd ./openssl && touch ../.openssl.is.fresh ; \
    fi
Cloning into './openssl'...
remote: Counting objects: 2388, done.
remote: Compressing objects: 100% (2106/2106), done.
remote: Total 2388 (delta 631), reused 1076 (delta 252), pack-reused 0
Receiving objects: 100% (2388/2388), 5.98 MiB | 1.34 MiB/s, done.
Resolving deltas: 100% (631/631), done.
Checking connectivity... done.
sed -i.bak 's/# if 0/# if 1/g' openssl/ssl/s2_lib.c
rm openssl/ssl/s2_lib.c.bak
true
cd ./openssl; ./Configure enable-ssl2 enable-weak-ssl-ciphers zlib darwin64-x86_64-cc
Configuring for darwin64-x86_64-cc
    no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)

....

$ sslscan --version
        1.11.5-rbsec-static
        OpenSSL 1.0.2h-dev  xx XXX xxxx

There are some hosts that cause sslscan and s_client to hang. It is reproducable with:

strace ./sslscan --failed --verbose 70.244.71.1

or

openssl s_client -debug -cipher 'ECDHE-RSA-AES256-SHA' -connect 70.244.71.1:443

sslscan stops at the call of SSL_connect():

If the certificate is a multidomain certificate. hostname might be one of the Altname and not the subject.
hence we might also want to display that.