Re: Secure SQL*Net

From: Cheng-Jih Chen <cjc_at_interport.net>
Date: 1997/12/04
Message-ID: <667bjo$o6n$1@interport.net>#1/1

In article <666n1d$pv9$1_at_interport.net>, Cheng-Jih Chen <cjc_at_interport.net> wrote:
>In article <uyb21z0i1.fsf_at_us.oracle.com>, <rwessman_at_us.oracle.com> wrote:
>>"Markus Schöpflin" <schoepflin_at_ginit.de> writes:
>>
>>> are there any other products which allow transparent encryption of an
>>> SQL*Net session besides Oracle's advanced network options? A non-US
>>> third party vendors perhaps, which don't underly the export regulations
>>> for this kind of software?
>>
>>Sorry, there aren't any other products other than ANO which encrypt SQL*Net.
>
>I haven't tried it yet, but can ssh be set up to proxy port 1521 on
>either side? I believe it can be done with POP mail clients.

Actually, here it is:

Basically:

On my client machine, I just started up:

 ssh -L 1521:<db_server>:1521 -l oracle <db_server>

Also, I modified tnsnames.ora, so that the service name in question points to localhost on my machine:

    (ADDRESS_LIST =

        (ADDRESS = 
          (PROTOCOL = TCP)
          (Host = localhost)
          (Port = 1521)
        )

    )

SQL*NET will look at 1521 on localhost and start talking to it. ssh takes whatever is being sent to localhost:1521 and sends it off to <db_server>:1521. Bang! I'm talking to the database on an encrypted channel.

I ran a packet sniffer while doing things like "select table_name from user_tables" and got gibberish. The day before when I did this, I got readable text. Quite a difference.

Actually, if there's a listener running on the client machine, you can't have ssh point at localhost:1521. No problem there: just point it someplace convenient, and modify the tnsnames.ora file to point at that port.

Of course, this doesn't happen transparently, which is what would be the case with Oracle Advanced Network Option. But I see this as an issue only on, say, Win95 boxes connecting with ODBC. On the other hand, the connection will fail if ssh isn't running, because tnsnames will refer to localhost and not the remote machine. The user should then have enough sense to turn encryption on, presumably with some profile or .bat file.

One major question would be performance. I'm not sure what kind of performance you'd get out of ssh tunnelling. I don't have the resources to test that right now. This was more a proof-of-concept that anything else.

This trick can be used in a variety of situations. Some people I know came up with this when a sniffer was set loose on our network, picking up POP names and passwords. ssh tunneling between POP clients and the server would solve this problem.

The Internet: an empirical test of the idea that a million monkeys banging on a million keyboards can produce Shakespeare.

-- 

The Internet: an empirical test of the idea that a million monkeys banging
on a million keyboards can produce Shakespeare.

Received on Thu Dec 04 1997 - 00:00:00 CST