Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


But... | 7 comments | Create New Account
Click here to return to the 'But...' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
But...
Authored by: jldera on Nov 27, '01 07:31:10PM

If I'm to read this correctly, you're secure tunnelling from your Mac to an SSH server, and then doing port forwarding on top of it. So that, all of my traffic between my Mac and that server is encrypted to SSH standards. However, if I'm then using the SSH server to connect to say, pop.mydomain.com, any traffic between the server and pop.mydomain.com will remain unencrypted. Am I just confused on how you wrote it, or is that the case. If the latter, then why are you wasting time doing all of this, just get a provider that has POP over SSL.



[ Reply to This | # ]
But...
Authored by: Anonymous on Jan 03, '02 02:47:26PM
Yes, POP is still sending a cleartext password. In my given example, the cleartext password is going over the encrypted tunnel to the server, and then being transmitted unencrypted over 127.0.0.1. Now, if somebody's sniffing my localhost traffic on my OpenBSD server, my POP password is the least of my worries. ;-) Alternatively, this same method can be applied to a corporate network. Given where I discuss pointing your port forward to another address, the assumption is you have a secured network. In my case, at my place of employment, the corporate network exists behind a firewall, using the RFC1918 space, so the same method can be used to tunnel the cleartext password over the internet, then be used on the secured corporate network.

Basically, you need to do a threat assessment. A secured end-to-end connection, such as an SSL connection like you mention, would be ideal. It's also impossible in Claris Emailer, and likewise other apps I'm sure. Things that come to mind are BBEdit and Dreamweaver, which incorporate ftp functionality (mind you they may support better methods these days; I haven't used the ftp stuff in ages). Assuming you have an app which does not support SSL, port forwarding is one way to work around it. For that matter, in a threat assessment, I can assure you there will be people sniffing 802.11 traffic at MWSF; I am one of them. ;-) In your given example of port forwarding to say a home ssh box, then upstream to the ISP, while there's still risk of sniffing between the home box and the ISP, it's significantly lower than cleartexting over an 802.11 at MWSF. Port forwarding, like all other methods, is just one tool. It should be in your toolbox, but it's up to the individual to make a threat assessment and devise a security policy relevant to the individual threats.

[ Reply to This | # ]
Duh-referred article
Authored by: Anonymous on Jan 03, '02 02:53:18PM
I mention in the above "my example", but then don't link to it. Sorry, brain dead day I guess. Here'sthe example of which I speak...

[ Reply to This | # ]