TLS tolerance scans are limited
tomato42 opened this issue · 5 comments
Because we're using OpenSSL CLI application for performing the scan, our control over the Client Hello sent is limited. For example we can't send TLSv1.3 Client Hello or we can't send a TLS1.2 client hello with TLS1.2 record layer version. We can't send an extension-less client hello if we use the system OpenSSL and so on...
While there is Python implementation of TLS in form of https://github.com/tomato42/tlslite-ng which does allow to do stuff like this, the main selling point for cipherscan is that it has minimal dependencies on the system - it can be run without root access and by just downloading the repo.
While it is possible to build a python tool and distribute it as a single binary (like we do with bundled openssl) that would leave the question of where should the code of this archive live. If in the same, then updating that code would be rather messy. And IMHO we should aim to drop binary files from the repo, not add more of them.
Alternatively we could make a shell wrapper around this python tool and make the wrapper download dependencies to local directory when it is run for the first time.
I'd prefer the second option, what about you @jvehent ?
I just wrote a python application that needs to work on linux and osx, from python 2.6 (rhel 6) to python 3.5+. The experience was horrifying. Even with good testing in place (tox running in travis-ci), there are enough small differences between versions of python and the way OSes handle them to end up in support hell, continuously trying to get users to run cipherscan without issues.
I strongly believe users should be able to run cipherscan following a simple git clone. If we can make tlslite-ng run in a virtualenv without any submodule, pip or apt/yum/brew magic, then it may be a viable solution. I would prefer to have the current cipherscan work as it does now, using the openssl binary, and if the user wants advanced testing, then propose to setup tlslite-ng in a virtualenv by downloading the relevant bits (that shouldn't involve pip, or root access, because that's when things go wrong).
Eventually, I want to rewrite cipherscan in Go, because that's a language that ships to all platform incredibly easily, and I now have enough experience with it to make the right decisions. I looked at Rust, but it's overkill in features & complexity for our needs. In the future, if there is a way to compile tlslite-ng to C, maybe we could import it in Go, and ship a static binary (go get retrieves source code and compile locally).
So I would say: go with option 2, with the goes to deploy tlslite-ng in a venv easily.
Does that make sense?
tlslite-ng and the tlsfuzzer are written in Python 2.6 up to Python 3.5 compatible way, and I don't share the "horrifying" assessment of that. Moreover tlslite-ng is written in a way that hides most of that differences completely for the stuff we'll need to do (And I know it works as I'm running CI over all those versions and occasional testing on RHEL-5 while developing on current Archlinux and Fedora)
If we can make tlslite-ng run in a virtualenv without any submodule, pip or apt/yum/brew
magic, then it may be a viable solution.
even virtualenv is overkill, simply setting PYTHONPATH to location of the library is enough to make it work. (and I don't even have virtualenv installed on my devel machine, expecting users to have it installed goes against the "shouldn't involve pip, or root access"). The most we can expect to have is git, bash-4, coreutils and python>=2.6 without modules. tlslite-ng fits that neatly (now it has no dependencies, later will have just one small - ecdsa package)
Go doesn't work for me, I'd prefer a tool that can work on RHEL-5 (I know that current bash script doesn't) and all architectures, be it x86_64, arm, ppc64, s390x...
I'll prepare a pull request going along the option 2, discussing details with code on hand will be easier.
That seems like a sane option. Let's go with that.
I haven't looked at the source of tlslite-ng, so I have no idea how many dependencies it is using. My comment referred to sops, which uses a fair amount of C libs and python deps, and proved difficult to install in various environments.
aah, with C libs and multiple dependencies I can imagine it being ugly.
It does. And asking the users to do a couple {apt-get,yum,brew}, followed by a pip install, which may conflict with existing packages, quickly becomes a mess. Added to that the complexity or writing python 2.6->3.5 code that doesn't break on types (str vs bytes vs unicode), and has all the needed packages (json vs simplejson, ...), made the whole experience unpleasant.
I know you're not a Go dev, but that language solves these issues so efficiently that I can't think of a better fit for a client tool like cipherscan. That said, I'd prefer to continue having separate component: a main script, an openssl executable, and a tlslite scanner. That way, each component can improve at its own pace without putting pressure on the others.