Using mitmproxy as a SSL/TLS compatibility shim for older systems

[corgski]

The premise is simple - use mitmproxy as an HTTP/SSL proxy to downgrade SSL connections for systems that don't support TLS 1.1 or 1.2

The execution, not so much. Currently I have it working with Safari on PPC OS X, Classilla on MacOS 9, and an older version of Opera on Windows 98. Trying to use Internet Explorer/Netscape Navigator currently fails due to, I think, broken SSLv2 and SSLv3 support.

That said, I did work up a way to generate root CA certificates that will install on older systems. In order to do this you'll need a linux system with OpenSSL and mitmproxy installed - you have to downgrade the signature algorithm to SHA-1 on your root certificate in order for it to install at all in IE 5 for mac or anywhere on Windows 98.

To generate the initial keys/certs use this script after installing mitmproxy but before starting it:

#!/bin/sh

cd ~
mkdir .mitmproxy
cd .mitmproxy
openssl genrsa -out mitmCA.key 2048
openssl req -x509 -new -nodes -key mitmCA.key -sha1 -days 1825 -out mitmCA.pem
cat mitmCA.key mitmCA.pem > mitmproxy-ca.pem
cp mitmCA.pem mitmproxy-ca-cert.pem
openssl pkcs12 -export -out mitmproxy-ca-cert.p12 -in mitmproxy-ca-cert.pem -nokeys -passin pass:root -passout pass:root
openssl x509 -outform der -in mitmproxy-ca.pem -out mitmproxy-ca-cert.cer

This will generate the root CA certificate and all the required certificate formats for the software to operate. Old Microsoft products (including IE5 for Mac) expect the "mitmproxy-ca-cert.cer" file. Classilla, Opera, and Safari will accept "mitmproxy-ca-cert.pem" for their cert.  Weirdly, attempting to install the root certificate into MacOS 9 keychain fails. It appears the certificate format it's looking for is at its core pkcs7 (*.p7b) but not base64 encoded. However, this still results in a blank certificate being imported and an error when trying to view it.

Anyway, to start up mitmproxy, you'll want to use the following command line. Being a pentesting tool more than anything it's not really set up for running in the background. Sticking it on a separate screen, however, works well enough.

screen -dm mitmweb --set ciphers_client=ALL --set ciphers_server=ALL --set ssl_version_client=all

That will enable less secure ciphers and SSL versions for connecting clients and then also allow less secure ciphers for communication with servers that still aren't following best practices.

Now just enter the IP address of your server with port 8080 for your HTTP and HTTPS proxy and copy over and install the root CA certificates and you'll be online.

The issues I'm still running into is that there's something broken in how it handles clients that only support SSLv2/SSLv3. It won't even log a connection attempt from those browsers - Netscape will say the socket was closed and IE for Mac will say that the server sent an invalid response. I'm not sure what my next step is in debugging what exactly is happening, but that's why I'm posting here!

 

[ict]

I unfortunately don't have an answer to your question regarding IE5/Netscape compatibility at the moment, but I did want to thank you for detailing your setup process. I might give this a try over the weekend and see if I can get my StarMax working with it.

For what it's worth, when I was throwing around the idea of setting up a proxy myself, it seemed that caching proxies like Squid may also provide an alternative for SSL downgrading, but I couldn't quite find the time to get something properly set up to try it out.

 

[Cory5412]

The generally accepted method for this is to use a proxy server that strips SSL entirely. I've conveniently forgotten the name of the tool to do it, but basically you configre  your proxy server (running this particular tool, configured a certain way) in the web address and/or other apps you want to use (or system-wide, I forget what OT supports on this front) and then nothing on your vintage mac has to deal with encryption at all.

The bummer is that it doesn't really work for email service because most modern email services require types of authentication older clients don't have.

The other bummer here is that a fair number of SSL protected sites just don't render well in old browsers, meaning that either a service or tool that strips or re-frames the page entirely into something that looks completely different for vintage compatibility is on order, or your best bet is to just use services and tools and sites that work well with old computers on their own.

 

[Cory5412]

Just heard back: at least one of the tools used for this was stunnel.

STunnel is explicitly for "adding" encryption to older tools/apps/computers that don't have it.

Again, you can strip SSL entirely using stunnel, but SSL-protected sites might not render at all in these older browsers.

 

[corgski]

So, it's been a while but I've determined that mitmproxy's implementation of SSLv3 is broken and there's no real motivation in their community to fix it at this point. I'm currently building a custom version of Squid that supports SSL bumping with hopes that that will work.  I've also found a config that uses squid to transparently rewrite https to http and downgrade the connection entirely, but that has more potential for things to go cockeyed as it relies on external scripts and could potentially affect binary files that contain https URLs as strings.

Stunnel on its own only seems to do 1:1 tunneling which is handy for specific services but not practical for the greater web.

 

[techknight]

SSLv3 is a protocol that isnt supposed to be used anymore, is deprecated due to severe security penalties. thats why everything should have moved over to TLS from SSL.

Anyone still running SSLv3 is considered dangerous and likely wont pass ssllabs tests. 

 

[corgski]

Right, and the point of this project is to bump SSLv3 clients to TLS 1.1+ on the local network using a mitm-capable proxy server. Which is what mitmproxy is supposed to be able to do.

That said, I’ve made some more progress on this project and have swapped out mitmproxy for a custom build of Squid 3.5 due to their lack of motivation in fixing the SSLv3 implementation. If I can port it forward I may even be able to add SSLv2 support for Netscape 2 and it’s contemporaries, although that also necessitates configuring the proxy to support upgrading HTTP/1.0 to HTTP/1.1 and injecting the Host: header.

My sticking point right now is figuring out exactly what old versions of Netscape consider a valid CA certificate, because they used so many proprietary extensions over the years.

 

[techknight]

Not entirely sure what root certs were built into netscape, They are probably all expired by now and will need new ones added. 

 

[corgski]

Yeah but there’s so little documentation because people weren’t just creating their own CAs back then. I think I’ve found a list of the proprietary fields needed for a CA cert to be recognized by Netscape 3 (oddly enough in some old oracle documentation) but I won’t know for sure until I’m done with this contract and back home so I can test it.