Docker image has issues with TLS 1.3

[reijin90]

Running the current Docker release of the tool, warns me about Net::SSLeay not supporting TLSv13:

user@tools:~$ sudo docker run --rm -it owasp/o-saft +check tld.com
/O-Saft/o-saft.pl   +check tld.com | cat
**WARNING: 143: SSL version 'TLSv13': not supported by Net::SSLeay; not checked

[EnDe]

The current docker image uses an openssl version (and hence libssl) which does not support TLS 1.3. An Update is on my todo, but will take some time because the base image (alpine) also changed and needs to be adapted.

[0xe7]

+1 for this

[EnDe]

anybody out there to help updating the docker image? any help appreciated.

Building for docker is a pain and debugging time consuming (my experiance). I can assist, and give hints, but currently have not the time to do the job in the quality I expect it to be.

[spmishra121]

I am facing Warning for TLS version 1.3

WARNING: 058: given path '/etc/pki/tls/certs' does not contain a CA file WARNING: 060: no PEM fila for CA found; some certificate checks may fail WARNING: 120: ancient perl has no 'version' module; version checks may not be accurate; at ./o-saft.pl line 1984. **WARNING: 143: SSL version 'TLSv13': not supported by Net::SSLeay; not checked**

When this can be available?

[polarathene]

When this can be available?

When someone can afford to spare time revising the Dockerfile.

---

Building for docker is a pain and debugging time consuming (my experiance). I can assist, and give hints, but currently have not the time to do the job in the quality I expect it to be.

I have experience with Docker as the maintainer of a popular dockerized project, but am likewise short for time. I don't use this project personally, but I am also happy to assist / advise my expertise with Docker if helpful.

I had a glance over the Dockerfile:

• MAINTAINER is no longer relevant AFAIK and should be changed to a LABEL. There is some official metadata labels you can use see this example. There are some other labels that could probably be adapted to that more recognized metadata kind too.
• You have some ENV defined like for WORKDIR that presumably are only for the image build, they could just be ARG.
• The Alpine workaround due to DNS possibly isn't an issue anymore. Note that the latest 3.17 release has upgraded OpenSSL from 1.1.x series to 3.x series. If you do want the 1.1.x series, it is still available via a separate compat package.
• Multi-stage build would allow you to better manage the debian + alpine support differences.
• For long scripts, these can be better inlined in the Dockerfile RUN with HereDoc syntax, removing the need for appending \ or && \ to each line. Alternatively there's nothing wrong with having a separate shell script and having the RUN execute that. So long as the file has changed, it will invalidate the layer from cache and run the directive again.
• You're using wget to fetch a tarball of the master branch, not an actual release artifact? You can use COPY and expect that the Dockerfile is built from a clone of the repo instead. This should simplify that logic. You can also better leverage that with Github Actions CI to handle the builds (I can also assist with that if you'd like, it will automate build and publish of the image for you).
• The other wget commands could use ADD directive instead to fetch remote files, but there isn't much advantage beyond that, leaving them as wget is fine.

None of the above needs to be done to resolve this issue. I imagine you can bump the alpine version to 3.17 and try build the image and identify where it fails. Anything Docker specific, feel free to ping me and I can chime in :+1:

[EnDe]

I'd appreciate any help in improving the dockerfile. If you interested, please feel free to contact the MAINTAINER PM ;-))

---

When this can be available?

I'm assuming your using the build from docker pull. If so, it contains an old version which checks the SSL ciphers using openssl (beneath SSLeay). You may try in the docker image (start with o-saft-docker shell) then call there perl -I . checkAllCiphers.pl some.tld

Hope this helps as workaround.

[EnDe]

• You're using wget to fetch a tarball of the master branch, not an actual release artifact? You can use COPY and expect that the Dockerfile is built from a clone of the repo instead. This should simplify that logic. You can also better leverage that with Github Actions CI to handle the builds (I can also assist with that if you'd like, it will automate build and publish of the image for you).
• The other wget commands could use ADD directive instead to fetch remote files, but there isn't much advantage beyond that, leaving them as wget is fine.

hmm, I've a couple of memos about pros&cons of ADD and COPY ... we may update my experience here. But, the main reason why wget is used inside the RUN-script is that the used alpine release 3.10 (back in 2019) didn't contain wget, it needed to be installed first (see Dockerfile); finally wget is removed.

[spmishra121]

I am facing Warning for TLS version 1.3

WARNING: 058: given path '/etc/pki/tls/certs' does not contain a CA file WARNING: 060: no PEM fila for CA found; some certificate checks may fail WARNING: 120: ancient perl has no 'version' module; version checks may not be accurate; at ./o-saft.pl line 1984. **WARNING: 143: SSL version 'TLSv13': not supported by Net::SSLeay; not checked**

When this can be available?

Seems, I had raised my query in wrong query thread. Actually I am using o-saft in local env., I am running this in my Linux machine. I am not using docker.

[EnDe]

Hi, the warnings 120 indicates an old perl version. The warnings 058 tells you that your system lacks root certificates. Both ist fine, Just some cert checks cannot be acurate. If you have installed osaft 22.11.22 (or pulled the current version), tls13 ciphers should be checked unless they are switched off. The only problem I'm currently aware off ist that servers providing only strickt tls13 (without backward compatibility) may fail to connect. Such servers are rare. The please post all messages, and the FQDN If possible.