How To: Redirect HTTP Traffic to Proxy Using iptables

Invisible Traffic

Proxy Madness

Using Squid or any other proxy for transparent caching/filtering of HTTP traffic has many benefits, being for logging purposes or the aforementioned use-cases, keeping every client configured can be a nuance. Networking equipment from Cisco and Juniper has the ability to redirect all passing HTTP traffic, in IOS and JunOS respectively, to the desired proxy.

A more cost-effective solution is to use a Linux box inline the client network and the “Internet”, redirecting HTTP traffic to a separate transparent proxy box, before it reaches the Internet.

Another, more realistic (…), use case. Is to use the transparent caching proxy server inline the VPN Server, VPN Client and the Internet. Example below.

VPN Client --> VPN Server --> Caching Transparent Proxy --> Internet

The benefit being that the VPN Server can resend cached content to the VPN Client, reducing latency for the server and the connection as a whole.

The Solution

Using the example above, traffic redirection using iptables most efficiently takes place on the VPN Server.

Below is the required configuration:
~# iptables -t nat -A PREROUTING -i [TUNNELIFACE] -p tcp -m tcp --dport 80 -j DNAT --to-destination [PROXYIP]:[PROXYPORT]

Working example:
~# iptables -t nat -A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.17.13.37:3128

As an end note. For best results and lowest possible latency, the VPN Server and Caching Transparent Proxy should be on the same network, preferably on the same network switch.

Happy Caching!

Client side Security, How’s My SSL? (.com)

https

Years ago,

Moxie Marlinspike taught us that web-browser hints such as a “lock icon” in the address bar, didn’t guarantee ciphered communication. Since the website you are visiting still happily falls back to plain http since you, the user, made an effort to not be redirected from a clear to ciphered session… Not really. Man-In-The-Middle is so very unforgiving to its victims.

Even though major websites, the giants, such as Facebook, Google and Micro$oft products such as Outlook.com. Has mitigated this fallback bug somehow. Smaller websites, such as Intranets and self-hosted WordPress blogs, is still vulnerable. Two-factor authentication solves the credentials issue, this is about privacy and information sanity. TLS or not, what cipher am I using anyway?

There is a website, Howsmyssl.com, which tells you what encryption ciphers are currently being used by the browser, in the order the browser sends them. Also, it list common and newly discovered vulnerabilies in the SSL/TLS protocol. What I find particularly interesting, is the cipher suites listed at the bottom of the page. To still see RC4 is getting very tedious…

Lab Time!

Just for fun, I disabled all the insecure ciphers I could find and made TLS1.1 the minimum required TLS version in Mozilla Firefox. For the first two weeks, every https I visited worked fine. Until I had some banking piled up at the end of the month…

Apparently my bank still uses TLS1! Mozilla won’t let me continue! And what’s even more surprising, is that the error message speaks of SSL3? For two protocols with only three years apart, maybe there isn’t much difference?

Nevertheless, I called my banks end-user technical support and explained the issue. And what did they tell me? To use another browser…

Conclusion

With the big scary Internet growing and tighter supervised than ever. Datacenters spinning with almost unlimited capacity, these 90’ts encryption protocols are surely broken. The old reheated excuses for large company’s to not implement https -not enough capacity, bandwidth, offloading etc- don’t apply anymore.

Out with the old, in with the new

 

iPhone App: Privacy PGP Messenger – Sending GPG/PGP Signed Email

Privacy PGP Messenger for iOS

Ever since I first dove down into the many protocol specifications of a typical email-setup. I noticed that there is very little (no) privacy, and (absolutely) no security.

Sure, most protocols can be “tunneled” through SSL/TLS in the Session and Presentation Layer. But how can you guarantee message integrity when it relays off to another server? In between datacenters and so on? And to think every message is stored in anything but cleartext, is wishful thinking.

Most clients support S/MIME, but is embarrassingly uncommon and terrible at presenting (attachment galore). GPG/PGP is in my opinion, albeit a little tricky, the ultimate privacy solution.

Privacy PGP Messenger Example

What about mobile clients you ask? One simple and very easy to use app for sending GPG/PGP signed email is Privacy PGP Messenger for iOS. It fetches the public key associated with the email address from a public keyserver (probably MIT), signs your message and uses your existing account in the Mail app to send.

It is generally recommended with GPG/PGP software that the private key associated with your email-address is kept Private. Preferably only one copy and stored offline. Therefore, this app is not a solution for Receiving signed email.

Happy Signing!

How To: Avoid password theft, Faceraping, Email hijacks etc. On public networks

Network SendHas your email been blacklisted? Does your forum-posts suddenly contain nothing but kittens? Did your relationship status become same-sex over night? Well, physical access to your box may be the answer to most of these scenarios. But everything you send on public wire, in plain-text that is, has the potential to be sniffed out or otherwise phished if you are careless.

Here are a few tips in avoiding disaster:

* SSL/TLS
Encrypt, encrypt, encrypt and make sure the certificate in question is properly signed – its mandatory. Wether if its web, email or chat. Most online services today allow an encrypted alternative and that includes popular services like Google, Facebook and Twitter. Just be on the lookout for https:// and not plain http:// in the address-bar. Never trust a pretty “Lock Icon”, those can be injected onto the session while SSL is being striped out, in an attempt to fool the user.

Secure Address-Bar

The same mindset applies to SMTP/IMAP/POP3-email and various chat protocols. Enable, if any, SSL option that is available. For email, the default SSL port numbers are as follows: 993 for IMAP(S), 995 for POP3(S) and 465 for SMTP(S). The port number may vary depending on your email provider.

* SSH Tunnel
When encrypted alternatives are not available, or doesn’t exist, an SSH-tunnel can be used. Simply, tunnel the traffic through an encrypted SSH-session and relay it through the trusted network where the SSH-server is located. I have a tutorial on how to do just that, complete with syntax and resources required here: http://peppoj.net/2012/10/tunnel-http-traffic-encrypted-using-polipo-and-ssh/.

* BYOIC (Bring Your Own Internet Connection)
If all else fails and trust is an issue, avoid public networks completely and use your own connection. If you already made the leap to the new generation and bought a smartphone with a generous dataplan, why not use it? Most smartphones today (and some older devices I’ve seen) allow tethering to computers and other devices. Simply enable tethering, hock it up and mess with the network settings on your host.

Disclaimer:
None of the tips above will protect you from Phishing, or otherwise plain fraudulent websites. Use you’re brain.

Feedback welcome

External Resources
CompariTech: Common phishing scams and how to recognise and avoid them

Tunnel HTTP traffic encrypted, using Polipo and SSH

SSH can be used to do allot of great things. Login remotely, transfer files with scp and run single commands for a quick fix. All encrypted! Another great and well-known feature of SSH is SSH tunnelling.

SSH tunneling can be used to tunnel any kind of traffic, and in this guide I’ll focus on HTTP tunneling in conjunction with the proxy client Polipo (encrypted of course).

Things you will need:

  • Linux server
  • SSH daemon running on the server (openssh-server recommended)
  • Polipo daemon running on the server
  • SSH client (openssh-client recommended)

How to:

~$ ssh username@server -L 8118:localhost:8123 -N [Enter]
(Enter password)
Point your web-browsers proxy (Firefox, Chrome, etc) to localhost, port 8118

Syntax:

  • -L Specifies the remote address, remote port and local port ([local port]:[remote address]:[remote port])
  • -N Don’t execute any command on the remote machine when connected

Tunnel initiated!