-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TLS tolerance scans are limited #108
Comments
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 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 ( 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)
even 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. |
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 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. |
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 ?
The text was updated successfully, but these errors were encountered: