Once you gather the information you need, you can remove the host file entry and stop sslsplit. The “-P” option contains the proxy specification, which takes the following form: PROTOCOL LISTEN_ADDRESS LISTEN_PORT HOST_TO_FORWARD_TO PORT_TO_FORWARD_TOĪnd that’s it! Now if you add an entry to /etc/hosts with your container registry name and the local IP, all communications will flow through SSLsplit. In the example above, I started sslsplit with the “-k” (CA certificate private key), “-c” (CA certificate), “-D” (don’t detach from the terminal and turn on debugging), -X (log packets to file), -L (log content to a text file), and the “-P” option. $ sudo /usr/local/bin/sslsplit -k /home/vagrant/.local/share/mkcert/rootCA-key.pem -c /home/vagrant/.local/share/mkcert/rootCA.pem -P ssl 0.0.0.0 443 10.10.10.250 443 -D -X /home/vagrant/ssl.pkt -L /home/vagrant/ssl.log Now that the foundation is built, we can fire up sslsplit: Next we need to restart dockerd to pick up the new RootCA certificate:
$ docker pull nginx Error response from daemon: Get x509: certificate signed by unknown authority If you skip this step, docker will complain about an unknown certificate authority: $ cp /home/vagrant/.local/share/mkcert/rootCA.pem. Next, we need to tell the OS (CentOS 7 in this case) to trust the new CA certificate: The new RootCA is used to mint the certificate that sslsplit will present to the client (dockerd in this case). First, we need to generate a RootCA certificate and the associated private key. SSLsplit is easy to use, but needs a few things in place before it can start decoding TLS record layer messages. It turns out the sslsplit utility is an ideal solution for this! If you haven’t used it, SSLsplit is a MITM proxy which can be configured to decrypt TLS communications from one or more clients. Ssldump doesn’t currently support decrypting communications with the session key, so I needed to come up with plan B to get the HTTP headers. When forward secrecy is used, the server’s private key is used to encrypt the initial communications, and to negotiate a session key which is used for the remainder of the TLs session. It turns out newer versions of TLS use forward secrecy. When I ran ssldump with the registries private key, I saw numerous application_data lines, but no data. Fortunately I use a private container registry, so I figured I could print the registry communications with ssldump. When I logged into one of the Kubernetes workers, the dockerd debug logs showed it had an issue pulling an image, but it didn’t log WHY it couldn’t pull it. This past weekend I got to debug a super fun issue! One of my Kubernetes clusters was seeing a slew of ErrImagePull errors.
0 kommentar(er)
