we’re using a 3rd party library that shall remain nameless. vendor provides this library to us in form of few .so files, few headers and sample code. we have a small custom c++ wrapper for it.
whenever library is initialized – it makes a call to licensing server and does some challenge/response verification. on one sunny day TLS certificate on that server expired and it took over 48h for the library supplier to address it.
dirty workaround to get that tool working? one would be to edit the behavior of binary… another – use the fact that the license check mechanism was working and we just had to convince library to connect to server with an expired cert; fortunately our library was well behaved and obeyed http_proxy, https_proxy environmental variables:
apt-get install mitmproxy
# run mitmproxy temporarily - it can be under unprivileged user
# during the first run it'll create in ~/.mitmproxy it's own certificate
# that will be used to sign decrypted and re-encrypted communication
mkdir /usr/local/share/ca-certificates/mitmproxy
openssl x509 -inform PEM -in /home/mitmproxyuser/.mitmproxy/mitmproxy-ca-cert.cer -out /usr/local/share/ca-certificates/mitmproxy/mitmproxy-ca-cert.crt
update-ca-certificates
# start mitmproxy again, under mitmproxyuser
mitmproxy --ssl-insecure --mode upstream:http://10.1.2.3:3128
# start our wrapper for 3rd party lib, instruct it to use mitmproxy
http_proxy=127.0.0.1:8080 https_proxy=127.0.0.1:8080 ./ourtool this, obviously, is insecure – mitmproxy would blindly trust not only expired certs but also potentially incorrect certs inserted by attacker. for us that was acceptable risk.
we’re in a very sad world where DRM for all sort of things that we think we’ve bought can stop working at any time… or for code that we think we run on our own infrastructure can stop working because its supplier goes belly up or has an outage.