At 11:06 -0400 8/14/03, Hardy Merrill wrote:
Rudy Lippan [EMAIL PROTECTED] wrote:
 On Thu, 14 Aug 2003, Hardy Merrill wrote:
 > If I'm running DBI/DBD::mysql on a mysql client machine,
 > and I want to connect to a different mysql server
 > machine, I must supply the username and password
 > in the DBI connect.  So, that username and password
 > will be passed from the client machine to the server
 > machine in cleartext, right?  My question is, how can I do
 > that such that the username and password is NOT
 > passed over the wire in cleartext - in the connect
 > statement?

 In theory you should be able to use SSL.  I have yet to try it, but
 DBD::mysql does support it if you compile with the -ssl option.

Thanks Rudy - I did read 'perldoc DBD::mysql' where it talks about mysql_ssl* parameters, but didn't notice that those were in the connect section :( After reading that

           mysql_ssl
               A true value turns on the CLIENT_SSL flag when connecting to
               the MySQL database:

mysql_ssl=1

               This means that your communication with the server will be
               encrypted.

my thought was that specifying 'mysql_ssl' in the connect
would connect 1st, and *then* start encrypting communications
between the client and server - it doesn't really clearly
state that the connect itself (username, pw) will also be
encrypted.

Is this clear to everyone else?  If not, I'd like to
propose a clarification to the DBD::mysql perldocs - to
explicitely say that mysql_ssl will cause the connect,
and all subsequent dbi statements, to be encrypted between
client and server.

Everybody seems to be accepting the idea that the password is passed in cleartext. On what is that based? It's false. (It is true that in MySQL 4.1.x some improvements are made to the encryption, but in earlier versions the password is not sent in cleartext.)

The username is sent in cleartext, yes.

Also, adding mysql_ssl=1 won't in itself give you an SSL connection.
You need the other mysql_ssl_xxx options to specify the key and
certificate files.



Thanks.


--
Hardy Merrill
Red Hat, Inc.



Reply via email to