Hello Team,
I'm cc`ing the upstream of o-saft, Achim.
When I started packaging o-saft for Debian, Achim got in contact
interested in helping us having a high quality package for o-saft.
It happened that we changed some emails but I didn't took enough
time to actually improve the package, and would like some help with
it.
There are a couple of things, and I will paste parts of emails Achim
sent me (with their permission), but the main and tricky problem is
bundling some old version of openssl with the package.
You see, o-saft needs an old version of openssl to be able to check for
old ssl things (ciphers etc.).
I know there has been some talk about getting an "openssl-insecure"
package for the testssl.sh[0] package for the same reason. I think we
should rather talk with upstream and propose some bundling of this
required version of openssl into o-saft.
Currently, o-saft has a helper builder script that downloads and builds
the required openssl, but we can't use it on Debian as we can't download
things at build time.
What I need help to, is figuring out something that upstream can do it
in a way that allow us to ship this statically linked openssl. But I
don't wanna ask upstream for something that could end up not being
useful because somebody on our side blocked the approach.
Here I will paste most of the emails usptream sent me, some of the
changes may have been addressed already and sorry for not removing
it, I removed the parts I remember I have addressed already, I know I
could spend more time on the formatting of the email but I think it's
better to ask for help now as I've been dragging this for too long already:
I'd like to suggest following improvments:
...
2.
o-saft.pl (/usr/bin/
o-
saft)
produces some warnings, quick&drty fix in /usr/bin/
o-
saft:
/usr/share/
o-
saft/
o-saft.pl --no-sslv2 --no-sslv3 --no-tlsv3 "$@"
a more elegant fix would be:
a) in /usr/share/
o-
saft/.
o-saft.pl (remove #):
--no-sslv2
--no-sslv3
--no-tlsv4
b) in usr/bin/
o-
saft:
/usr/share/
o-
saft/
o-saft.pl --rc "$@"
3.
o-saft.pl uses a special compiled openssl. Ist should be build on kali
and installed independent of /usr/bin/openssl, best in /usr/local/openssl/
Most of the warning you currenly get are because modern /usr/bin/openssl
does not support what's needed to check SSL/TLS.
The complete build commands can be found in the Dockerfile, see lines
following
#== Pull, build and install enhanced openssl
If needed, I can provide a special build-script.
Finally, hope you have seen that there already is /usr/share/
o-
saft/
o-
saft
Pleace consider to use that in /usr/bin/
o-
saft in future.
It has option --cli to start as CLI
o-saft.pl , or --gui to start the gui
o-
saft.tcl . It will (next version) start the GUI if there is no tty.
This enables
o-
saft to be started from the panel menu.
Please let me know, if you need assistance.
I've setup contrib/install_openssl.sh to fully work on all debian-based systems
systems. The updated version is available at
https://github.com/OWASP/O-Saft/blob/master/contrib/install_openssl.sh
No need to look in the Dockerfile (as the script uses the same code;-)
Just a few note on contrib/install_openssl.sh
* it downloads source of openssl-chacha
* installs Perl modules using "perl -MCPAN"
* install everything in /usr/local
It's already part of the package and then can be used directly with/from the next
official verion of
o-
saft.tgz.
/usr/local is currently not used by Kali, so you may "pack" that after running
contrib/install_openssl.sh and put it into the
o-
saft package.
As openssl is already installled on Kali as /bin/openssl, and /usr/local/openssl/bin
containing the newly compiled openssl-chacha is not part of the PAH environment
variable, I don't see a conflict.
More difficult would be the installed Perl modules, as Perl's @INC contains /usr/local
before /usr. Currently only Net::SSLeay is effected (which was pre-installed on Kali).
However, a "normal user" won't see the difference, as the adapted Net::SSLeay in
/usr/local backward compatible to the pre-installed in /usr.
Another idea is to install openssl-chacha and the Perl modules in /usr/share/
o-
saft/lib
o-saft.pl is already prepared for that.
Let me know, if this would simplify the packageing.
Finally:
you) I recommend you get used to contrib/install_openssl.sh
as a fully patched openssl enables the full power of o-saft
me) I'll further improve contrib/install_openssl.sh (installing Perl mudule
only if missing, trying to install in /usr/share/o-saft/lib, ...)
we) you tell me where you need assistance ;-)
Does it make sence to provide two packages: o-saft and o-saft-dev ?
Then only o-saft-dev has the dependency libperl-critic-perl.
There is already INSTALL.sh which removes the files not used at runtime,
actually it's the diff of o-saft and o-saft-dev :-)
You may use it like:
env inst=/usr/share/o-saft INSTALL.sh --install --n
Let me know if I should improve or adapt INSTALL.sh.
So yeah, we need to think about a way of having o-saft with support
for all of the openssl things, and also probably split the package into a gui
and a dev one.
Thanks!
--
Samuel Henrique <samueloph>