Defectdojo cant handle secure connections to DB

[parafoxx]

Bug description
Defectdojo is unable to use ssl/tls encypted connections when using Mysql as DB. Therefore it is unable to use in certain environments where secure connections are enforced.

Steps to reproduce
Steps to reproduce the behavior:

1. clone the project

2. change line 70 in the docker-compose.yml to require SSL:
   command: ['mysqld', '--character-set-server=utf8mb4', '--collation-server=utf8mb4_unicode_ci'] --> command: ['mysqld', '--character-set-server=utf8mb4', '--collation-server=utf8mb4_unicode_ci', '--require-secure-transport=ON']

3. build and run the project docker-compose up --build

4. See error in logs from initializer, celerybeat and celeryworker

Expected behavior
Defectdojo tries to use a secure connection by default and exits if no secure connection is possible (unless a specific environment variable is set like "allow unsecure DB connections")

Deployment method (select with an X)

• Kubernetes
• Docker
• setup.bash / legacy-setup.bash (not tested)

Environment information

• Operating System: Docker
• DefectDojo Commit Message: 6d56806: Update README.md [2019-11-26 16:42:15 -0600]

Console logs (optional)
e.g. for initializer:
initializer_1 | .ERROR 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON. initializer_1 | Traceback (most recent call last): initializer_1 | File "manage.py", line 10, in <module> initializer_1 | execute_from_command_line(sys.argv) initializer_1 | File "/usr/local/lib/python3.5/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line initializer_1 | utility.execute() initializer_1 | File "/usr/local/lib/python3.5/site-packages/django/core/management/__init__.py", line 375, in execute initializer_1 | self.fetch_command(subcommand).run_from_argv(self.argv) initializer_1 | File "/usr/local/lib/python3.5/site-packages/django/core/management/base.py", line 323, in run_from_argv initializer_1 | self.execute(*args, **cmd_options) initializer_1 | File "/usr/local/lib/python3.5/site-packages/django/core/management/base.py", line 364, in execute initializer_1 | output = self.handle(*args, **options) initializer_1 | File "/usr/local/lib/python3.5/site-packages/django/core/management/commands/dbshell.py", line 22, in handle initializer_1 | connection.client.runshell() initializer_1 | File "/usr/local/lib/python3.5/site-packages/django/db/backends/mysql/client.py", line 48, in runshell initializer_1 | subprocess.check_call(args) initializer_1 | File "/usr/local/lib/python3.5/subprocess.py", line 271, in check_call initializer_1 | raise CalledProcessError(retcode, cmd) initializer_1 | subprocess.CalledProcessError: Command '['mysql', '--user=defectdojo', '--password=defectdojo', '--host=mysql', '--port=3306', 'defectdojo']' returned non-zero exit status 1

[madchap]

I am using a secured connection to my AWS RDS mysql 5.7. I will take a look at what I did in the coming days and let you know.

[madchap]

OK, so it comes from the fact I am not using MySQL as part of docker-compose.

In this case, I would argue that this is a non-issue, as you certainly would not run a production instance with MySQL as part of your docker-compose stack. It is meant for development purposes only.

[parafoxx]

I disagree. First why can you not run a docker-compose stack in production?
Second, this bug is not limited nor caused by docker-compose. It is just an easy way to reproduce the error. The actual error is in the way dojo is creating the db connection.

Besides you mentioned that you are able to use a AWS MySQL. Could you post your connection string (with replaced credentials)?

[madchap]

AWS RDS databases enable TLS by default, I don't have the actual mysqld start-up string. See https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.SSLSupport for more details.

In my settings.py, I have the RDS TLS certificate as an option, such as:

DATABASES['default']['OPTIONS'] = {
    'ssl': {'ca': '/etc/ssl/certs/rds-combined-ca-bundle.pem'}
}

My DD_DATABASE_URL is simply

DD_DATABASE_URL=mysql://defectdojo:xxxxxx@defectdojo.xxxx.amazonaws.com:3306/defectdojo

And I guess "it just works". I can no longer connect without TLS enabled -- neither with uwsgi nor with the plain mysql client.

[parafoxx]

Thanks for your hints. After some research on the background of this ssl config statement I was able to find whats going on.
My initial expected behavior coheres with the mysql connector defaults
Even though the official C connector has it implemented (I suppose so since the task is marked as completed), the library defectdojo uses has not (mysqlclient). Because actually what I am looking for is the parameter 'ssl_mode' (goto mysqlclient docs and search for 'ssl_mode' ) which should have the default of 'PREFERRED' but is missing in our case. Your option line specifying the ca certificate can be found directly beneath it.
However I am using the docker image from docker hub and therefore changing a file is not a good solution. The docker way is to use an environment variable as explained in section 'Expected behavior' of my initial post.

The reason defectdojo (or rather its dependency mysqlclient) is currently not cohering to the standard of mysql is the old version of it. It was only recently added (3 weeks ago see this merge request ), however no release has happened since then.
Updating the dependency to use the git version (until they release a new version) should therefore make it work in my case without additional settings.

For the sake of configuring e.g. hardening to disallow non-ssl connections and supplying the ca cert or in legacy cases use always unencrypted connections some environment variables to change the behaviour would be awesome.

[madchap]

I see, thanks for digging.

We should hopefully get around a release soon. Meanwhile, if you don't mind trying out the dev branch it could help.

If you feel this is something you could contribute to, please feel free :)

Happy holidays.

[parafoxx]

Hey there,

with Holidays being over off to a fresh start in a new year.
I checked out the dev branch, applied the mysql config from step 2 of steps to reproduce and run it.
Result: nothing changed, same error.

went through the commit history and could not find anything related to the problem. Problem exists in both branches. Both use the same version of mysqlclient (1.4.2) which is the root of the problem as stated in my last post.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.