Discovery of the day: quick and easy Apple Mail connection tunneling

[kpreid]

I'm on a wireless network which apparently has a firewall which is MITMing port 993 connections (IMAP-over-SSL); my mail client reported a certificate error (the presented certificate was from “FortiGate”). Now, I trust this network's provider, but that doesn't mean I'm going to give them my personal e-mail, much less the password for it; so I went looking for a solution. It turns out that Apple Mail supports SOCKS proxies, and if you have SSH access to another system it's trivial to set up; ssh -D somelocalport somehost, then go into Network Preferences → Advanced → Proxies, and enter localhost:somelocalport as the proxy, and you're done!

It's not clear to me, though, once I set this up how much of my traffic goes over the proxy — the setting is not specific to mail or Apple Mail. This might be testable by shutting down the proxy and seeing what fails.

Comments

[wrog]

actually, SSH port forwarding should be essentially invisible to the applications. I don't see why Apple Mail has to do anything special to support it (i.e., other than not throw conniptions at the idea of an IMAP server listening in a strange place like 127.0.0.2, or being able to connect to SSL-IMAP servers on ports other than 993.

And yes, everybody who talks to 127.0.0.2:993 (or wherever the local side of the tunnel is) gets forwarded the same way; it is indeed not application specific. However if a given application doesn't know about the tunnel, there's pretty much no way it's going to find it on its own, unless you've put it in some standard place like localhost:993, but the only programs that will be using that will be other mail clients, and if you don't have any, you're done.

[kpreid.livejournal.com]

This isn't ssh port forwarding (-L); this is a SOCKS proxy (-D). I would have used a port-forward, but Apple Mail is being half-bakedly clever: it “knows” that a MobileMe (Apple's mail-and-etc service) mail account should be reached at mail.mac.com:993. So I had to do this, avoiding changing the mail config, instead.

[(Anonymous)]

So, um, did you check that the firewall isn't also MITM'ing SSH? SSH completely sucks because it has no certificates to cause errors like the one you saw. There are just those incomprehensible hex numbers that everyone clicks "yes" to whenever they change. You have to compare them by some reliable out-of-band channel, since the firewall could also be rewriting them in flight in any text stream you look at them through.

[kpreid.livejournal.com]

So, um, did you check that the firewall isn't also MITM'ing SSH?

Um, yes? I didn't “check”; SSH did that for me. I know it isn’t since SSH didn’t complain when I connected.

I have never accepted a SSH host key without checking what's up. Also, your description of the UI is inaccurate; to accept a change in host key, one must remove the old key from known_hosts manually; there is no “just continue” option (or at least, this was the case the last time I saw a host key change myself; it's been a while).

SSH’s system is superior to certificates because certificates don’t really get you anything (or rather, they're no better than the worst, least thoroughly verifying CA on your root CA list) but claim to; SSH gives you a working system without any third-party authorities which don't really have your interests in mind.

If you're going to say “certificates are superior for the naive user”, well, that could be argued, but the matter at hand is not naive users. IMO, the Right Thing is to take the SSH model and improve it — make it easier to verify the keys and pass around the information designating “this host, and here's what its key fingerprint should be” — not add certificate authorities.