since no support for compression and support for renegotiation are
necessary for the server to have a secure configuration, collect
and report those two too
since the signature and hash algorithm in TLSv1.2 is selectable by server
and negotiated using TLS extensions, we can check what sig algs is
the server willing to perform and whatever it does honour client
selection
it also tests what happens if the client doesn't offer any sigalgs that
are necessary to use the ciphers selected by server
buggy servers may choke on large ClientHello's, TLSv1.2 ClientHello's,
etc. try to detect such failures and report them
among tried connections are TLS1.2, TLS1.1, TLS1.0 and SSLv3 with
ability to downgrade to lower protocol versions as well as a size
limited client hello, both TLS1.2 and TLS1.0 version
EXP is self explanatory - export grade
DES-CBC3-MD5 is available only in SSLv2 - not secure
RC4-64-MD5 is also a weakened version (though not marked as export grade)
since early versions of 1.0.2 openssl supports -curves command line
option, it allows us to set the curves advertised as supported
use the same approach to testing: advertise all, check what server
accepts, remove the accepted from list, repeat. When server aborts
connection or selects non ECC cipher, we know that we've tested all.
CApath is about 20% faster than CAfile so use it, also
save the received certificates from the servers for later analysis
(proper hostname checking, looking for certificates sharing private key,
etc.)
Use the mechanism from cipherscan to find location of ca cert bundle
firstly, test_cipher_on_target() will try at least 4 connections before
incurring the sleep, for aggressive rate limiter on server side it may be
too much, so sleep before every connection
secondly, because running external commands like sleep incurs a fork
penalty, we first check if it is necessary
it's relatively easy to make the cipher selection generic,
so that adding different clients is as easy as converting their
client hello cipher ordering to openssl cipher names
since now we know if server honours client order or not, we can use it
to properly simulate handshakes for a given client, also report
the general stats of this server configuration variable
the ECDH parameters come from server certificate - the point
on elliptic curve. The RSA comes from the signature on the certificate
which comes from CA
because neither M2crypto nor OpenSSL packages provide extensive
enough API to do certificate chain building, verification
and outputting of details, we have to pre-parse the data
with a C app that can access the full OpenSSL API.
I've also tried monkey patching the packages, but unfortunately
the result wasn't working reliably
The actual statistic collection (both about the chains and
specific certificates) will be done in a python script
Hubert Kario
Julien Vehent
Hubert Kario