aab7e028c2
When tls_sockets() is used for run_protocols(), for each protocol version the results will indicate whether the server responded to a ClientHello for that protocol version with (1) a ServerHello for that same protocol version, (2) a ServerHello for a different (hopefully lower) protocol version, or (3) a handshake failure. Currently, however, run_prototest_openssl() does not distinguish between cases in which the server responds with a ServerHello for a different (hopefully lower) protocol version and cases in which the server responds with a handshake failure. This PR changes run_prototest_openssl() so that it distinguishes between these two cases (as long as $OPENSSL supports the protocol version specified in the ServerHello). Making use of the additional information provided by run_prototest_openssl(), this PR also modifies run_protocols() to check that version negotiation was performed correctly even if $using_sockets is false. Note that one special case needed to be addressed. If an SSLv3-only server is being tested using an $OPENSSL that does not support SSLv3, then $latest_supported must not be set to SSLv3. In the case of a server like this, it is possible that support for SSLv3 will be determined by determine_optimal_sockets_params(), which will cause run_protocols() to report that the server supports SSLv3, even though $OPENSSL does not support SSLv3 and testing is being performed in --ssl-native mode. If $latest_supported were set, then later tests in run_protocols() would incorrectly report a version negotiation failure, even though the failure to connect was a result of a limitation of $OPENSSL rather than a fault of the server. |
||
|---|---|---|
| .github | ||
| bin | ||
| doc | ||
| etc | ||
| t | ||
| utils | ||
| .gitignore | ||
| .travis.yml | ||
| CHANGELOG.md | ||
| CONTRIBUTING.md | ||
| CREDITS.md | ||
| Dockerfile | ||
| Dockerfile.md | ||
| LICENSE | ||
| Readme.md | ||
| openssl-iana.mapping.html | ||
| testssl.sh | ||
Readme.md
Intro
testssl.sh is a free command line tool which checks a server's service on
any port for the support of TLS/SSL ciphers, protocols as well as some
cryptographic flaws.
Key features
- Clear output: you can tell easily whether anything is good or bad.
- Machine readable output.
- No installation needed: Linux, OSX/Darwin, FreeBSD, NetBSD, MSYS2/Cygwin, WSL work out of the box. Only OpenBSD needs bash. No need to install or to configure something. No gems, CPAN, pip or the like.
- A Dockerfile is provided, there's also an offical container @ dockerhub.
- Flexibility: You can test any SSL/TLS enabled and STARTTLS service, not only web servers at port 443.
- Toolbox: Several command line options help you to run your test and configure your output.
- Reliability: features are tested thoroughly.
- Privacy: It's only you who sees the result, not a third party.
- Freedom: It's 100% open source. You can look at the code, see what's going on.
- The development is open (github) and participation is welcome.
License
This software is free. You can use it under the terms of GPLv2, see LICENSE. In addition starting from version 3.0rc1 if you're offering a scanner based on testssl.sh as a public and / or paid service in the internet you need to mention to your audience that you're using this program and where to get this program from.
Compatibility
testssl.sh is working on every Linux/BSD distribution out of the box. Latest by 2.9dev
most of the limitations of disabled features from the openssl client are gone
due to bash-socket-based checks. As a result you can also use e.g. LibreSSL or OpenSSL
1.1.1 . testssl.sh also works on other unixoid system out of the box, supposed they have
/bin/bash >= version 3.2 and standard tools like sed and awk installed. An implicit
(silent) check for binaries is done when you start testssl.sh . System V needs probably
to have GNU grep installed. MacOS X and Windows (using MSYS2, Cygwin or WSL) work too.
Update notification here or @ twitter.
Installation
You can download testssl.sh by cloning this git repository:
git clone --depth 1 https://github.com/drwetter/testssl.sh.git
Or help yourself downloading the ZIP archive https://github.com/drwetter/testssl.sh/archive/3.0.zip. Just cd to the directory created (=INSTALLDIR) and run it off there.
Docker
Testssl.sh has minimal requirements. As stated you don't have to install or build anything. You can just run it from the pulled/cloned directory. Still if you don't want to pull the github repo to your directory of choice you can pull a container from dockerhub and run it:
docker run -ti drwetter/testssl.sh <your_cmd_line>
Or if you have cloned this repo you also can just cd to the INSTALLDIR and run
docker build .
followed by docker exec -ti <ID> <your_cmd_line> where ID is the identifier in the last line from the build command like
---> 889fa2f99933
Successfully built 889fa2f99933
Status
We're currently in the late release candidate phase. That means you can and should use it for production and let us know if you encounter any additional bugs. Features implemented in 3.0 are listed in the Changelog.
Support for 2.9.5 has been dropped.
Documentation
- .. it is there for reading. Please do so :-) -- at least before asking questions. See man page in groff, html and markdown format in
~/doc/. - https://testssl.sh/ will help to get you started.
- Will Hunt provides a longer, good description for the (older) version 2.8, including useful background info.
Contributing
Contributions are welcome! See CONTRIBUTING.md for details.
Bug reports
Bug reports are important. It makes this project more robust.
Please file bugs in the issue tracker @ github. Do not forget to provide detailed information, see template for issue, and further details @ https://github.com/drwetter/testssl.sh/wiki/Bug-reporting. Nobody can read your thoughts -- yet. And only agencies your screen ;-)
You can also debug yourself, see here.
External/related projects
Please address questions not specifically to the code of testssl.sh to the respective projects below.