SSL Verification For Integrations Toogle

[keni0k]

Hello! I tried to integration DT with Defect Dojo, but I ran into the problem that my certificate wasn't trusted. I could add it to the cacerts, but DT is deployed in k8s and it looks difficult.

I found a similar issue with the Fortify SSC: https://github.com/DependencyTrack/dependency-track/issues/589

What do you think about the optional disabling of certificate verification, for example, for Unirest the simple way is: Unirest.config().VerifySsl(false);

Proposed Behavior:

alpine.integrations.ssl.verify option

[nscuro]

Disabling certificate validation is not the solution you want, as it'd make HTTPS almost pointless. You should extend trust to your internal CA, which in case of DT means modifying the Docker image or mounting a custom keystore at runtime (probably the easiest solution).

[keni0k]

Why the solution with modifying the Docker image is inconvinient:

1. Modify the dockerfile DT by adding a copy of the certificate
2. Rebuild the DT image
3. Submit the DT image to docker repository
4. Change the helm chart to work with an alternative image
5. And then support it all when updating versions…

As for mounting the keystore, the situation is better, but it still looks strange. Both the defect dojo and the dependency track are in the k8s and I trust the communication channel between them, that is, I believe that the MITM attack is the last thing to worry about in this case.

If the problem is exaggerated, you can close this issue, as a simple solution, I opened http port for dependency track on the defect dojo.

[nscuro]

Just to be clear, I'm not the maintainer of DT, so it's not my decision whether or not this should be supported.

For k8s deployments of Java applications, it's very common to mount the truststore as volume (e.g. via Secrets or ConfigMaps, see here). If your helm chart doesn't support this use case yet, I'd recommend implementing it (or opening an issue, if you use a community-maintained one).

IMO, allowing certificate validation to be disabled allows for bad deployment / operation patterns, and I don't believe that DT should support it. But as I said, it's ultimately up to @stevespringett to decide.

[stevespringett]

@keni0k The simplest thing to do is to use certificates from a trusted public CA on both DT and Defect Dojo. In doing so, these problems go away.

There's a high correlation between orgs that have internal proxy servers and those that maintain their own PKI. Therefore, DT will automatically disable SSL hostname and certificate validation if a proxy server is configured in DT. So putting a proxy between DT and DD and configuring DT to use the proxy should solve the TLS error message, but you'll loose the authenticity capabilities that TLS provides.

[stevespringett]

No future changes to TLS hostname or certificate validation will be made. The best option for Java is to mount the truststore which will require creation of a new container image.