add openssl like command line interface

[tomato42]

create a replacement for openssl tool, with support for subcommands like:

• [ ] s_client
• [ ] enc
• [ ] x509
• [ ] dgst
• [ ] verify
• [ ] pkey
• [ ] pkeyutil
• [ ] ocsp

for compatibility with cipherscan and testssl.sh

[tomato42]

@drwetter does that look like a complete set of necessary features to replace the real openssl for testssl.sh? (is x509 and verify necessary?)

[drwetter]

@tomato42 : pkey, pkeyutil and ocsp would miss too. Yes, x509 would be necessary.

s_client we mostly replaced in default mode by sockets. There are leftovers though. The much I appreciate your plan and have big respect regarding the challenge you seem to take: please don't count on testssl.sh replacing openssl in 1+ year. At the moment I still appreciate the fact that for almost every OS no installation is needed which makes testssl.sh good for beginners too.

[tomato42]

The much I appreciate your plan and have big respect regarding the challenge you seem to take

the code is there, it's just a question of providing an interface to it, and while I would be very wary of trying to reimplement the full API, the command line applications should be much easier

please don't count on testssl.sh replacing openssl in 1+ year.

sure, but if I'm close to 90% there, can I expect you (or other people working on testssl.sh) to contribute to this goal?

I'm asking as I'm still on the fence about how to solve the whole TLS 1.3 issue with cipherscan; I can write it fully in python, but then it's custom code, not reusable by others or I can work on openssl-like interface to tlslite-ng, but then I don't know how much help I can expect from others...

At the moment I still appreciate the fact that for almost every OS no installation is needed which makes testssl.sh good for beginners too.

modulo python being available, creating a zip or taball with everything needed to run tlslite-ng, without need to install anything is quite simple – it's also a major requirement for cipherscan, and given that being pure-python implementation is a major development goal for tlslite-ng, it should remain so for foreseeable future

What about verify, is it necessary? Honestly, that's probably the most complex and hardest things to do in this list...

[drwetter]

the code is there, it's just a question of providing an interface to it, and while I would be very wary of trying to reimplement the full API, the command line applications should be much easier

with all STARTTLS protocols?

sure, but if I'm close to 90% there, can I expect you (or other people working on testssl.sh) to contribute to this goal?

not sure what exactly you mean here. That we would test how it works or we contribute in any other way?

Whatever you meant I could make my life easier and say now "yes" without knowing whether I or anybody else will do it. Making promises without knowing I can keep them is not my style.

Now the default is using bash sockets except a few calls where we couldn't get rid of OpenSSL . There are some commands I mentioned and some s_client -connect to e.g. retrieve HTTP headers. But using --ssl-native will switch to using (solely?) OpenSSL binaries. openssl s_client -connect atm is faster but less complete. So technically the biggest advantage would be IMO if tlslite-ng would be another switch like --tlslite-ng and works exactly like OpenSSL but it is complete AND fast. tlslite-ng would then be another alternative.

Albeit from the technical perspective this sounds like an idea which could worth to follow up, pls keep in mind that testssl.sh is a project which at least I do in my spare time.

modulo python being available, creating a zip or taball with everything needed to run tlslite-ng, without need to install anything is quite simple – it's also a major requirement for cipherscan, and given that being pure-python implementation is a major development goal for tlslite-ng, it should remain so for foreseeable future

Cipherscan is targeting different users. testssl.sh deliberately also addresses users which are happy to see just a green or red light without knowing much of the details behind it or worrying about it. I am afraid that DL'ing and installing zip files and installing python is maybe is too much for those. The requirement for testssl.sh is very small: bash, openssl, grep, awk, dd, sed (plus very few other binaries). It works also under MacOS, WSL, Cygwin, FreeBSD out of the box. Only Alpine Linux user need to install 1-2 few things. And OpenBSD doesn't have bash per default installed.

What about verify, is it necessary? Honestly, that's probably the most complex and hardest things to do in this list...

openssl verify is used for determine whether the certificate chain is ok and trusted and for revocation checking via OCSP. The first is important. The second is not done per default, as it has a privacy impact and doesn't work with a proxy yet. (and technically it needs and OCSP URL which is not always the case)

If I were you I would not scratch my head about verify now and complete the other tasks first. And maybe don't worry about me too much ;-)

[tomato42]

with all STARTTLS protocols?

sounds like a fun weekend project to get away from all the crypto stuff ;)

not sure what exactly you mean here. That we would test how it works or we contribute in any other way?

code would be most appreciated, especially for more obscure features, or cipher suite definitions – yes, I know I'm asking for a lot

but knowing if you could help with integration is good to know by itself

works exactly like OpenSSL but it is complete AND fast

that "fast" part may be a problem – initialisation takes good few milliseconds and if testssl.sh would use it the simplest possible way (new process for every command), it may not be as fast as OpenSSL, but may be faster than pure bash; something to check

pls keep in mind that testssl.sh is a project which at least I do in my spare time. And maybe don't worry about me too much ;-)

cipherscan is the same for me, that's why I'm being upfront about it; going this direction (of replicating openssl CLI) is not exactly the most straightforward road for me, but if that means we travel together, it feels to me like we can get further; but it is impossible for me to gauge how much you'd benefit from it