Re: Securing ssh tunnels.

> I was thinking why would you do this and then I thought, shouldn't
> there be an ssh proxy ? (You can all stone me for suggesting this
> after you've read it ;)

As a user, I like the ability to have an end-to-end secured connection, and any interference from the firewall administrator would annoy me, and I'd try to get around it if I could.

As the security guy in charge of the firewall, the idea of an SSH proxy is very appealing. You'd be impersonating the remote server, so since you're the negotiation endpoint, you'd be able to disable things like X11, agent, or port forwards, yet allow generic connections through. While it's obvious a determined user could overcome these, the default would stop most simple or unintended problems, such as old ssh_config files that allow X11 by default.

A transparent proxy would do a full mitm 'attack', more or less:

	client attempt to connect out to the internet
	proxy get's the connection instead (use whatever means are
		available on your firewall...)
	proxy knows the outgoing IP address
	proxy checks local directory to see if it's got a fake
		host key for this IP.  If not, it creates one and
		uses that host key for this destination henseforth.
		(It could use the same key for all destinations if
		you prefer - this may make more sense, but it does
		make your known_hosts file look rather suspicious.)
	proxy make client SSH connection to the actual destination
	proxy checks a second local directory to see if it's got a
		host key for this destination.  If not, it stores
		the one presented.  If it does, it verifies that it's
		correct.
	proxy continues handshake with user, refusing any options we
		don't like and requesting those we do from the actual
		server
	proxy shuttles authentication methods back and forth
	proxy encrypts/decrypts as appropriate (content checking
		could be integrated here iff necessary)

The first obvious problem is that there's no way to provide the user with the ability to say the destination's host key is correct, so the proxy must trust it on faith. I can't think of an easy way to get around this without providing some sort of actual proxy support into SSH itself, where it'd have a chance to acknowledge the proxy's key and then the true destination's key. It'd never be actually using the true destination's key, except for that one initial acceptance. This also brings up other issues - if Mr "I'll click anything" blesses the destination key, am I stuck with his decision, even though I'd normally check the key manually?

--
Brian Hatch                  Military Intelligence
   Systems and               Microsoft Works
   Security Engineer
http://www.ifokr.org/bri/

Every message PGP signed

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek