Simple Password Encryption not happening
Jeff configured Simple Password CSM (SPWDCSM) on IDS 11.50.UC1 with an entry in concsm.cfg and csm=(SPWDCSM) in sqlhosts, and used SECURITY=PASSWORD from the JDBC 3.50.JC1 driver. The connection worked (and failed if only one side was configured), but Wireshark still showed the password in clear text. Jonathan Leffler showed, using his IDSMON proxy to log traffic, that an ESQL/C client with the same CSM setup does not send the password in the clear, concluding either a setup step was missed or JDBC was ignoring the configuration. Others asked for driver/JVM/URL details, which Jeff supplied, but no resolution is recorded in the thread.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
I have attempted to enable Simple Password Encryption yet my network sniffer still shows plain text passwords. conscsm.cfg (copied straight out of the manual): SPWDCSM ("client=/opt/informix/lib/client/csm/libixspw.so,server=/opt/informix/lib/csm/libixspw.so","","") sqlhosts: testdb onsoctcp informix-dev.example.com 1500 csm=(SPWDCSM) And in my JDBC client I use SECURITY=PASSWORD. Now I know something is happening because if I configure only the server or only the client for password encryption, I get an error. With both of them configured, I can connect, but when I look at the packets in Wireshark, I can see my password in plain text. What am I doing wrong? Server = 11.50.UC1 Client = JDBC 3.5.JC1
On Feb 27, 1:29 pm, Jeff <jlar...@yahoo.com> wrote:
> I have attempted to enable Simple Password Encryption yet my
> network sniffer still shows plain text passwords.
>
> conscsm.cfg (copied straight out of the manual):
> SPWDCSM ("client=/opt/informix/lib/client/csm/libixspw.so,server=/opt/informix/lib/csm/libixspw.so","","")
>
> sqlhosts:
> testdb onsoctcp informix-dev.example.com 1500 csm=(SPWDCSM)
>
> And in my JDBC client I use SECURITY=PASSWORD.
>
> Now I know something is happening because if I configure only the
> server or only the client for password encryption, I get an error.
> With both of them configured, I can connect, but when I look at
> the packets in Wireshark, I can see my password in plain text.
>
> What am I doing wrong?
>
> Server = 11.50.UC1
> Client = JDBC 3.5.JC1
I have not done the JDBC connection, but I have done a plain ESQL/C
connection, and logged the traffic between client (my SQLCMD program)
and IDS (11.50.FC1) all running on Solaris 10, with my IDSMON program
sitting in the middle, logging everything sent by the client to the
server and everything sent by the server to the client.
When I do this, I do not see my password being sent over the wire -
evidence below, FWIW.
Consequently, there are two main possibilities:
* You've missed a step in the setup.
* JDBC isn't paying attention to your configuration.
At this stage, I'm neutral between the two.
Warning - long posting (oops - too late!)
There are a fairly large number of configuration files etc to get
right, partly because I'm interpolating IDSMON into the setup.
Let's look at this in two stages - unmonitored (normal) and then
monitored (abnormal).
Stage 1: IDS Configuration.
* Server name is black_19.
* Server aliases are: black_19_tcp, black_19_enc, black_19_shm,
black_19_str, black_19_pwd.
* $INFORMIXDIR/etc/sqlhosts file contains:
black_19 ontlitcp black 18190
black_19_tcp ontlitcp black 18191
s=4,pam_serv=login,pamauth=password black_19_enc ontlitcp black 18192 csm=
(black_19_enc)
black_19_shm onipcshm black black_19
black_19_str onipcstr black black_19 black_19_pwd ontlitcp black 18193 csm=
(black_19_pwd)
* When I boot black_19, one of the environment variables is:
INFORMIXCONCSMCFG=$IXD/etc/concsm.black_19* The contents of the concsm.black_19 file is (extraordinarily long
lines - sorry about the wrapping).
# CSM Configuration for server black_19
black_19_enc("server=/usr/informix/11.50.FC1/lib/csm/
iencs11a.so,client=/usr/informix/11.50.FC1/lib/client/csm/
iencs11a.so", "cipher[des3:cbc],mac
[levels:<high>,files:<builtin>],switch[cipher:1440,key:180]")
#black_19_enc("server=/usr/informix/11.50.FC1/lib/csm/
iencs11a.so,client=/usr/informix/11.50.FC1/lib/client/csm/
iencs11a.so", "config=/usr/informix/11.50.FC1/etc/enccsm.black_17")
black_19_pwd("server=/usr/informix/11.50.FC1/lib/csm/
ispws11a.so,client=/usr/informix/11.50.FC1/lib/client/csm/
ispws11a.so", "", "")
I had to fix the client library names - it was copied from an older
version, and still had 09 instead of 11 in the names. Fortunately,
the server side was correct (oops that I hadn't spotted the bogus
client information), so I didn't have to reboot IDS to get it to work.
Stage 1: Client configuration
* The client program (SQLCMD for me) required the INFORMIXCONCSMCFG
environment variable and the correct server name (black_19_pwd); in my
environment, $IXD is the same as $INFORMIXDIR and saves me a lot of
typing.
$ INFORMIXCONCSMCFG=$IXD/etc/concsm.black_19
INFORMIXSERVER=black_19_pwd sqlcmd SQL[150]: connect to 'stores' user 'jleffler' password 'Kryptonite';
SQL[151]: select * from elements where atomic_number < 2;
1|H|Hydrogen|1.0079|Y
SQL[152]: quit;
$
OK - that was the unmonitored setup - making sure I could connect to
the database. No, my password is not, and never has been,
Kryptonite. I'm daft, but not that daft.
The server was not rebooted at any stage during this work - so there
was no change in its configuration (though, of course, it was pre-
configured with a simple password encryption listener thread - so I
cheated slightly, or was forewarned and forearmed, or four-legged, or
something).
How does IDSMON work?
IDSMON has two modes to its operation. The first is as a listener on
a 'well-known' port - you tell it which port to listen on. It then
sits in the background (as a daemon), waiting for a process to connect
to its well-known port. When it receives such a request, it forks.
The parent goes back into listen mode, waiting for the next
connection, after logging the connection request and which child it
forked to deal with it.
Meanwhile, the child gets frenetic. (Sequence of operations is
subject to discussion; the net result is accurate enough.) The child
accepts the request and then establishes a socket connection to IDS on
the host/port combination that it was configured to connect to. Then
the child itself forks (so we have child and grandchild of the
listener), logging what it is up to. The child then settles down into
listening for information from the client and writes the data received
to the (IDS) server and to a log file; the grandchild also settles
down to listening for information from the server and writes the data
received to the (CSDK) client and to the same log file. Eventually,
the client or the server gets bored and terminates the connection, at
which point, the child and grandchild shut up shop (after logging the
information, as ever). At some point, the master daemon establishes
that its child has gone to meet its maker over near /dev/null and logs
that the conversation is complete in the master log. There are all
sorts of controls, options and tweaks available, including sqliprint-
compatible output (except that sqliprint does not even pretend to
understand the connection messages).
Stage 2: Monitored client
So, how do we monitor a connection. We set up IDSMON so that it will
connect to the (IDS) server's black_19_pwd port (18193); it listens on
a different port - I chose 38193. We then configure the client so
that it uses the SPWDCSM, but instead of connecting to port 18193, it
connects to port 38193. That's done by an entry in a separate
sqlhosts file, idsmon.sqlhosts:
# @(#)$Id: idsmon.sqlhosts,v 1.4 2009/02/28 18:32:40 jleffler Exp $
#
# SQLHOSTS file for testing IDSMON and tracking connections
black_17 oltlitcp black.lenexa.ibm.com 2317 r=1
black_19 oltlitcp black.lenexa.ibm.com 2319 r=1
black_19_pwd oltlitcp black.lenexa.ibm.com 38193 r=1,csm=
(black_19_pwd)
The name and all the other information is the same as before - just
the port number is different. So, SQLCMD is run:
$ INFORMIXSQLHOSTS=$PWD/idsmon.sqlhosts INFORMIXCONCSMCFG=$IXD/etc/
concsm.black_19 \\
> INFORMIXSERVER=black_19_pwd sqlcmd SQL[158]: connect to 'stores' user 'jleffler' password 'Kryptonite';
SQL[159]: info tables;
jleffler|a
On Feb 27, 3:29 pm, Jeff <jlar...@yahoo.com> wrote: > I have attempted to enable Simple Password Encryption yet my > network sniffer still shows plain text passwords. > > conscsm.cfg (copied straight out of the manual): > SPWDCSM ("client=/opt/informix/lib/client/csm/libixspw.so,server=/opt/informix/lib/csm/libixspw.so","","") > > sqlhosts: > testdb onsoctcp informix-dev.example.com 1500 csm=(SPWDCSM) > > And in my JDBC client I use SECURITY=PASSWORD. > > Now I know something is happening because if I configure only the > server or only the client for password encryption, I get an error. > With both of them configured, I can connect, but when I look at > the packets in Wireshark, I can see my password in plain text. > > What am I doing wrong? > > Server = 11.50.UC1 > Client = JDBC 3.5.JC1 Which JDBC connection class are you using?
Ugh - it would look better in constant-width font and without the unhelpful line breaks. Sorry - contact me if you want a plain-text attachment of the message without the breaks (but I'd prefer you to do it for yourself!) On Sat, Feb 28, 2009 at 12:48 PM, Jonathan Leffler <jonathan.leffler@gmail.com> wrote: > On Feb 27, 1:29 pm, Jeff <jlar...@yahoo.com> wrote: >> I have attempted to enable Simple Password Encryption yet my >> network sniffer still shows plain text passwords. [...] > > I have not done the JDBC connection, but I have done a plain ESQL/C > connection, and logged the traffic [...]. > > Here's the log information from the master daemon log: > > idsmon: 2009-02-28 10:31:49 - pid=4972: IDSMON Daemon 1.33 (2007/10/17 > 23:55:35 +00:00) > idsmon: 2009-02-28 10:31:49 - pid=4972: Listening on port 38193 > idsmon: 2009-02-28 10:31:49 - pid=4972: Relaying to host > black.lenexa.ibm.com port 18193 > idsmon: 2009-02-28 10:31:49 - pid=4972: Session log file names /work1/ > jleffler/src/sqltools/idsmon/b > lack_19_pwd/black_19_pwd.YYYYMMDD-hhmmss.PID [...] >And here's the (text) session log file: > > 2009-02-28 18:33:52 UTC - SC pid 4998 (alt 4999) > 2009-02-28 18:33:52 UTC - CS pid 4999 (alt 4998) > 0.004997 CS 435 > 0x0000: 73 71 41 61 38 42 50 51 41 41 73 71 6C 65 78 65 > sqAa8BPQAAsqlexe > 0x0010: 63 20 6A 6C 65 66 66 6C 65 72 20 20 39 2E 33 35 c > jleffler 9.35 > 0x0020: 30 20 41 41 41 23 42 30 30 30 30 30 30 20 2D 64 0 > AAA#B000000 -d [...] Beautifully formatted originally - under 80 columns per line...damn emailers! -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/ "Blessed are we who can laugh at ourselves, for we shall never cease to be amused." NB: Please do not use this email for correspondence. I don't necessarily read it every week, even.
On 28 Feb, 20:48, Jonathan Leffler <jonathan.leff...@gmail.com> wrote:
> On Feb 27, 1:29 pm, Jeff <jlar...@yahoo.com> wrote:
>
> > I have attempted to enable Simple Password Encryption yet my
> > network sniffer still shows plain text passwords.
>
> > conscsm.cfg (copied straight out of the manual):
> > SPWDCSM ("client=/opt/informix/lib/client/csm/libixspw.so,server=/opt/informix/lib/csm/libixspw.so","","")
>
> > sqlhosts:
> > testdb onsoctcp informix-dev.example.com 1500 csm=(SPWDCSM)
>
> > And in my JDBC client I use SECURITY=PASSWORD.
>
> > Now I know something is happening because if I configure only the
> > server or only the client for password encryption, I get an error.
> > With both of them configured, I can connect, but when I look at
> > the packets in Wireshark, I can see my password in plain text.
>
> > What am I doing wrong?
>
> > Server = 11.50.UC1
> > Client = JDBC 3.5.JC1
>
> I have not done the JDBC connection, but I have done a plain ESQL/C
> connection, and logged the traffic between client (my SQLCMD program)
> and IDS (11.50.FC1) all running on Solaris 10, with my IDSMON program
> sitting in the middle, logging everything sent by the client to the
> server and everything sent by the server to the client.
>
> When I do this, I do not see my password being sent over the wire -
> evidence below, FWIW.
>
> Consequently, there are two main possibilities:
> * You've missed a step in the setup.
> * JDBC isn't paying attention to your configuration.
>
> At this stage, I'm neutral between the two.
>
> Warning - long posting (oops - too late!)
>
> There are a fairly large number of configuration files etc to get
> right, partly because I'm interpolating IDSMON into the setup.
>
> Let's look at this in two stages - unmonitored (normal) and then
> monitored (abnormal).
>
> Stage 1: IDS Configuration.
> * Server name is black_19.
> * Server aliases are: black_19_tcp, black_19_enc, black_19_shm,
> black_19_str, black_19_pwd.
> * $INFORMIXDIR/etc/sqlhosts file contains:
> black_19 ontlitcp black 18190
> black_19_tcp ontlitcp black 18191
> s=4,pam_serv=login,pamauth=password> black_19_enc ontlitcp black 18192 csm=
> (black_19_enc)
> black_19_shm onipcshm black black_19
> black_19_str onipcstr black black_19> black_19_pwd ontlitcp black 18193 csm=
> (black_19_pwd)
> * When I boot black_19, one of the environment variables is:
> INFORMIXCONCSMCFG=$IXD/etc/concsm.black_19> * The contents of the concsm.black_19 file is (extraordinarily long
> lines - sorry about the wrapping).
> # CSM Configuration for server black_19
>
> black_19_enc("server=/usr/informix/11.50.FC1/lib/csm/
> iencs11a.so,client=/usr/informix/11.50.FC1/lib/client/csm/
> iencs11a.so", "cipher[des3:cbc],mac
> [levels:<high>,files:<builtin>],switch[cipher:1440,key:180]")
> #black_19_enc("server=/usr/informix/11.50.FC1/lib/csm/
> iencs11a.so,client=/usr/informix/11.50.FC1/lib/client/csm/
> iencs11a.so", "config=/usr/informix/11.50.FC1/etc/enccsm.black_17")
> black_19_pwd("server=/usr/informix/11.50.FC1/lib/csm/
> ispws11a.so,client=/usr/informix/11.50.FC1/lib/client/csm/
> ispws11a.so", "", "")
>
> I had to fix the client library names - it was copied from an older
> version, and still had 09 instead of 11 in the names. Fortunately,
> the server side was correct (oops that I hadn't spotted the bogus
> client information), so I didn't have to reboot IDS to get it to work.
>
> Stage 1: Client configuration
>
> * The client program (SQLCMD for me) required the INFORMIXCONCSMCFG
> environment variable and the correct server name (black_19_pwd); in my
> environment, $IXD is the same as $INFORMIXDIR and saves me a lot of
> typing.
>
> $ INFORMIXCONCSMCFG=$IXD/etc/concsm.black_19
> INFORMIXSERVER=black_19_pwd sqlcmd> SQL[150]: connect to 'stores' user 'jleffler' password 'Kryptonite';
> SQL[151]: select * from elements where atomic_number < 2;
> 1|H|Hydrogen|1.0079|Y
> SQL[152]: quit;
> $
>
> OK - that was the unmonitored setup - making sure I could connect to
> the database. No, my password is not, and never has been,
> Kryptonite. I'm daft, but not that daft.
>
> The server was not rebooted at any stage during this work - so there
> was no change in its configuration (though, of course, it was pre-
> configured with a simple password encryption listener thread - so I
> cheated slightly, or was forewarned and forearmed, or four-legged, or
> something).
>
> How does IDSMON work?
>
> IDSMON has two modes to its operation. The first is as a listener on
> a 'well-known' port - you tell it which port to listen on. It then
> sits in the background (as a daemon), waiting for a process to connect
> to its well-known port. When it receives such a request, it forks.
> The parent goes back into listen mode, waiting for the next
> connection, after logging the connection request and which child it
> forked to deal with it.
>
> Meanwhile, the child gets frenetic. (Sequence of operations is
> subject to discussion; the net result is accurate enough.) The child
> accepts the request and then establishes a socket connection to IDS on
> the host/port combination that it was configured to connect to. Then
> the child itself forks (so we have child and grandchild of the
> listener), logging what it is up to. The child then settles down into
> listening for information from the client and writes the data received
> to the (IDS) server and to a log file; the grandchild also settles
> down to listening for information from the server and writes the data
> received to the (CSDK) client and to the same log file. Eventually,
> the client or the server gets bored and terminates the connection, at
> which point, the child and grandchild shut up shop (after logging the
> information, as ever). At some point, the master daemon establishes
> that its child has gone to meet its maker over near /dev/null and logs
> that the conversation is complete in the master log. There are all
> sorts of controls, options and tweaks available, including sqliprint-
> compatible output (except that sqliprint does not even pretend to
> understand the connection messages).
>
> Stage 2: Monitored client
>
> So, how do we monitor a connection. We set up IDSMON so that it will
> connect to the (IDS) server's black_19_pwd port (18193); it listens on
> a different port - I chose 38193. We then configure the client so
> that it uses the SPWDCSM, but instead of connecting to port 18193, it
> connects to port 38193. That's done by an entry in a separate
> sqlhosts file, idsmon.sqlhosts:
>
> # @(#)$Id: idsmon.sqlhosts,v 1.4 2009/02/28 18:32:40 jleffler Exp $
> #
> # SQLHOSTS file for testing IDSMON and tracking connections
>
> black_17 oltlitcp black.lenexa.ibm.com 2317 r=1
> black_19 oltlitcp black.lenexa.ibm.com 2319 r=1
> black_19_pwd oltlitcp black.lenexa.ibm.com 38193 r=1,csm=
> (black_19_pwd)
>
> The name and all the other informatio
> From: david@smooth1.co.uk > Subject: Re: Simple Password Encryption not happening > Date: Sun, 1 Mar 2009 22:12:16 -0800 > To: informix-list@iiug.org > [SNIP] > > I would like a copy of IDSMON (davidmsdw at yahoo dot co) then dot uk. > > Pity the protocol between client and server is not documented (it > would make an interesting addition to the > list of protocols that wireshark understands!). Sigh. 1) Which JDBC driver are you using? 2) Which JVM are you using 3) Which versio of Java are you using? 4) What does your URL look like? In terms of threat assessment, are you doing client/server (simple SWING app)? or are you using a web server/app server to db combo? If you are using the latter, are you behind a firewall, and are the machines located near one another? Even if you are capable of encrypting the password connection, if the connection is on a private network where only your machines in the machine room are connected. (ie a 192.168.x.x / 24 network) you have less risk. _________________________________________________________________ Windows Live™ Groups: Create an online spot for your favorite groups to meet. http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009
Ian Michael Gumby wrote:
>
<snip>
>
> Sigh.
>
> 1) Which JDBC driver are you using?
> 2) Which JVM are you using
> 3) Which versio of Java are you using?
> 4) What does your URL look like?
1a) Informix supplied JDBC 3.50.JC1 c
1b) com.informix.jdbc.IfxDriver
2) Sun JRE
3) 1.4.2_13 on Windows XP
4a) jdbc:informix-sqli://informix-dev.example.com:1500/dbname
4b) Environment vars are put into Java properties
INFORMIXSERVER=testdb, SECURITY=PASSWORD
Thanks,
Jeff
Related threads
- the longer you surf, the MORE $$$ you earn !!
- Store procedure
- emulation for Vt100
- extent size questions again ...