Dirk Wetter
Dirk Wetter
Oh, great, thanks for the input! I did 20x runs from Europe against HK with https://github.com/robotattackorg/robot-detect, which was originally used by @dcooper as a basis for porting this to testssl.sh...
robot-detect seems more robust but my statistics weren't good enough. Running robot-detect from Europe --> NY yielded 2x vulnerable, 2x not vulnerable, 16x 'Getting inconsistent results, aborting'. For testssl I...
Hi @briveramelo , sounds like a good idea! Thanks for the pointers. I needed to catch up a bit wrt JUnit XML and bats first. There are two possibilities: native...
Hi, you are right. In cases like yours the openssl supplied cannot connect in the very few instances left where openssl is needed. Looking at your system you were using...
Hi @gkroon , the output should be better now. As said in cases where the system has a better matching OpenSSL to the server side like yours you're better off...
Looking at the system name and kernel revision it pretty much looks like your system has openssl 1.1.1 in ``/usr/bin/openssl``, so ``OSSL_SHORTCUT=true ./testssl.sh `` or (better) ``testssl.sh --openssl /usr/bin/openssl. ``...
There's no easy way providing support for TLS 1.3 AND (SSLv2 and some curves and ciphers). But there's also hope that OpenSSL 1.1.1 will become common on the client side,...
TL;DR: not, atm it's left to the user. (``--openssl=``) There were two minor steps. @dcooper16 extended his TLS 1.3 implementation in sockets, so that partly a full handshake is possible...
??? ``` Start 2020-08-27 17:27:01 -->> 213.154.225.246:443 (secure.cacert.org)