I am trying (for testing in a lab network) to capture SSL using Squid proxy's SSL Man-in-the-Middle mode, and I want to store it for analysis in Wireshark and other programs. Is there a way I can derive the pure HTTP traffic from Squid somehow? Even if it involves grabbing the keys from Squid and using them in conjunction with captured traffic to decrypt things, I'm open to any ideas. I already know about the client-side pre-master-secret business, but I'd like to avoid relying on a client-side thing since this is going to be a pentesting lab kind of network.
If I understand what you want to do, what you'll need to do is inject your own certificate into the middle of the transaction (taking your man-in-the-middle attack to the next level) and somehow get your users to ignore the subsequent certificate warning.
If you don't want them to see a certificate warning, that's going to be a little more interesting, and would involve injecting a trusted CA on the client computer (this is why you should restrict users from being able to add their own trusted authorities on client machines), altering DNS, and having your Squid proxy box impersonate a site that you know a user will try to visit (Facebook is a classic). I'm probably missing a couple of steps in here, but that should keep you busy for a while.
1 Like
We've already done all that, MITM SSL proxying is working. I just need a way to decrypt the SSL between the client and the proxy
I'm fairly sure that if you have the private key for the server certificate you can give it to wireshark and it will decrypt the traffic. But considering that it generates a certificate for each site that may not work.
Squid may not be the right tool for the job as it does everything internally and I don't think there's a way to get in there with a packet sniffer. I have done what you want to do before using ssl strip and something to do arp poisoning before. Maybe have a look at something like that.
In that case if you can keep a copy of all the generated server certificates you can load them in to wireshark and decrypt the traffic, you just won't be able to do it in real time
I believe we have that figured out as it shouldn't be too hard to keep all the certificates that Squid generates in it's cache folder. What I'm wondering is:
- is there a way to do this automatically and spit out an already-decrypted cap file?
- is there a way to bulk import the certs into Wireshark, or must we add each one manually? For a long "lab session" there could be a pretty large number of them.
I'm not really sure, I was reading through this and it may not be as straight forward as I thought. Especially if you're using elliptic curve or DH.
packetpushers.net/using-wireshark-to-decode-ssltls-packets/
I think using sslstrip instead of squid is a better option as you should be able to capture plain text packets from that. If you want to stick with squid you may be able to use ssldump with a script to decode a packet capture for each certificate key you have (run the capture against each key until you have a fully decoded capture). But you will have to disable elliptic curve and DH ciphers on squid for it to work.
I actually found another way to make it work, with a handy software called mitmproxy. It's basically built to do the same kind of interception as Squid, except it's designed to make logging stuff easy since it's a tool for nefarious things.
Now I have another question. The tutorial I followed has iptables on the proxy machine (an Ubuntu box) forwarding all the traffic on port 80 and 443 through the proxy software. How can I tell iptables to forward all SSL traffic, regardless of port, to the proxy? These are the rules from the tutorial.
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 \
-j REDIRECT --to-port 8080
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 \
-j REDIRECT --to-port 8080
Iptables can't tell ssl traffic from other traffic, you could put in a port range (I think it's first:last etc.) but that will just forward all traffic on those ports to your proxy.
Couldnt you determine the byte offset of the payload and compare the hex to known values of TLS/SSL packets?
But can you make iptables rules based on that? I don't know
Yes
check iptables and/or iptables-extensions man pages...
search for string | hex-string
I will look into that, but as it turns out there are some applications that will not work correctly without a lot of exceptions in the proxy, so we may just leave it on port 80/443 for simplicity's sake.
Next question: I need to make the Ubuntu machine that this proxy is on transparent. So the network will be like
clients --- switch ---> ubuntu proxy machine ---> pfSense firewall --- InternetHow can I set up the Ubuntu machine to be transparent like a switch and still have iptables rules apply (so I can forward the traffic through the proxy)?
You could probably set it up as a bridge but it depends how it works. Alternatively you could set the Ubuntu machine as the gateway in the dhcp settings and then have it forward the traffic to pfsense.
We ended up setting up bridging like you said, and used ebtables and iptables to transparently force traffic through the proxy. Works great!
2 Likes