search

offsecginger / CTFd-Docker-Challenges

Docker Challenge creation for CTFd. Allows per team/user containers!
GNU General Public License v3.0
81 stars 51 forks source link

TLS connection to docker daemon not verified #8

Closed vnthn closed 3 years ago

vnthn commented 3 years ago

Latest commit merged a PR that has verify=false in requests as parameter. This was because I did not manage to find out how to properly verify self-signed certificates. Installing them to /etc/ssl/certs did not help (thought it would be checked with the host-installed certs).

As there is still some work to do and because this can be a security concern, I raised this issue. The connection is still encrypted, but not secure against MITM.

See also: https://stackoverflow.com/questions/30405867/how-to-get-python-requests-to-trust-a-self-signed-ssl-certificate

Before the PR there was verify=ca_file.name in the requests parameters. But, at least for me, that did not work. The certificate was not verified and no connection was possible.

offsecginger commented 3 years ago

Hey @vnthn

Unfortunately you're not going to be able to solve this issue without having the ca.pem generated signed by a trusted root authority. That usually costs money. The alternative is to make the scoreboard trust the ca.pem by importing it, but I'm not sure where requests gets its certificate store.

There is no MiTM risk here unless someone steals both the client and the server private key, which is stored on the docker server in my installations. I run a task that auto imports the client keys needed (ca.pem, cert.pem and client-key.pem) into the CTFd.db when I'm building out our CTF infrastructure.

The TLSverify setting in docker forces clients to authenticate with a public key that has been signed by the server's certificate authority certificate. Otherwise docker refuses the connection.

I hope this makes sense

vnthn commented 3 years ago

Hi, I understand the issue wih the root authority. I thought it would also be possible using a self signed cert as it is described in requests documentation. At least in my environment, I am using (or tried to use) a self signed certificate.

Regarding the MITM: You are right, I forgot the client has to authenticate with its client certificate, too.

Thanks for clarification.

offsecginger commented 3 years ago

Yep we use self signed certs too. `verify=False is acceptable in this case!