Using Apache to intercept HTTPS traffic

Due to the increase in processing power available, the use of SSL has become more widespread. This is obviously a good thing, especially with UK ISPs spying on ( and annoyingly, replaying ) web traffic recently, however this can be a showstopper when trying to debug a misbehaving application.

To get around this, and allow us to see what exactly an application, or even a web browser is doing, we can use Apache ( with mod_proxy and mod_dumpio ) to perform a man-in-the-middle attack , and view the traffic.

This solution is specifically for one domain ( although you could probably make it work using apache vhosts and specific certificate for each domain you are intercepting ), and is designed for intercepting data from another machine on your network – I tested using a ‘victim’ Windows VM, a Gentoo web server for the interception and an external test server , so the flow of traffic looks like this, once we have everything setup:

Windows VM ( victim ) -> Gentoo Apache ( interception ) -> Target 

The first step is obviously to install apache, with SSL support, mod_proxy ( again, with SSL support ) and mod_dumpio. On gentoo it is as simple as ensuring these USE flags are enabled:

ssl apache2_modules_proxy_http apache2_modules_dumpio 
apache2_modules_proxy

and running:

emerge -va apache

Once apache is installed , and assuming openssl is installed ( it should be brought in as a dependancy on Gentoo by installing apache with the ssl USE flag ), we can generate a certificate for the domain we are targeting ( the paths here are Gentoo specific, and will overwrite the default apache keys – you may want to back these up in case you need the originals ):

openssl req -new -x509 -nodes -out /etc/ssl/apache2/server.crt 
-keyout /etc/ssl/apache2/server.key

This command will then ask for details, none of them are really important ( they only refer to what appears on the certificate, incorrect or missing data will not cause the certificate to fail to work ) except the Common Name. The Common Name refers to the domain name we are going to intercept.

We now have a certificate which we can use with apache, Gentoo users will need to add the modules to the APACHE2_OPTS variable /etc/conf.d/apache2 :

-D SSL -D PROXY -D PROXY_HTML

Ensure that the modules are loaded in /etc/apache2/httpd.conf ( or your OS’s similar file ), there should be some lines that look something like these, and be near the top of the file where modules are loaded:

LoadModule dumpio_module modules/mod_dumpio.so
LoadModule ssl_module modules/mod_ssl.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

We also need to add these lines to the same file ( /etc/apache2/httpd.conf ) to begin proxying, and logging data ( obviously replacing https://test/ with your target domain ):

ProxyHTMLLogVerbose On
SSLProxyEngine on
ProxyPass / https://test/
DumpIOInput On
DumpIOLogLevel debug
DumpIOOutput On

Apache should also have some definitions pointing to the certificate and keys ( Gentoo has them in /etc/apache2/vhosts.d/00_default_ssl_vhost.conf ) :

SSLCertificateFile /etc/ssl/apache2/server.crt
SSLCertificateKeyFile /etc/ssl/apache2/server.key

One last change is needed ( on Gentoo in /etc/apache2/modules.d/00_default_settings.conf, just grep for LogLevel on other OSs ) to ensure we get all the data we need, simple set LogLevel to debug, like this :

LogLevel debug

You can now start apache ( /etc/init.d/apache2 start for Gentoo ), and either change your local DNS server to point your ‘victim’ target hostname to your apache server, or add this to it’s host file ( C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on everything else ), again replace test with your target domain, and 192.168.1.100 with your apache server’s ip:

192.168.1.100  test

You can now open your target URL in the web browser on your ‘victim’ machine, and you should get a certificate error. If you get a timeout, or another error, check your apache ssl error logs ( /var/log/apache2/ssl_error_log on Gentoo ). If you don’t receive a certificate error, then the interception isn’t working correctly, you might need to restart your browser to make it take affect, or ( very unlikely ) your ‘victim’ machine is setup very insecurely. Have your ‘victim’ browser , or machine, accept the certificate, then add it to your ‘Trusted Root’ certificate store.

You should now be able to examine your interception server’s apache logs and see the raw GETs, POSTs and other content between your ‘victim’ machine and the SSL encrypted target domain.