Closed reijin90 closed 1 week ago
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.
+1 for this
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.
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?
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.ENV
defined like for WORKDIR
that presumably are only for the image build, they could just be ARG
.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.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).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:
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.
- 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.
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.
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.
With Version 24.09.24 and in particular its new Dockerfile, docker image now supports TLS 1.3.
Keep in mind that version 24.09.24 builds the docker image with openssl 3.x, which has various limitation to detect legacy SSL/TLS implementations. To check such targets with openssl, Dockerfile.openssl must be used.
Running the current Docker release of the tool, warns me about Net::SSLeay not supporting TLSv13: