Re: Securing ssh tunnels.

From: Brian Hatch (secure-shell_at_ifokr.org)
Date: 06/26/03

  • Next message: Brian Hatch: "Re: Securing ssh tunnels." 
    Date: Thu, 26 Jun 2003 10:20:12 -0700
To: Darren Reed <avalon@caligula.anu.edu.au>

    > 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

  • Next message: Brian Hatch: "Re: Securing ssh tunnels."
    • Quantcast