On Dec 20, 2008, at 8:10 PM, Edward Diener wrote:
> I am kind of baffled that no one seems to know how it actually
> should work
There are lots of reasons to avoid fighting with this feature:
- Probably most MySQL users run it on the same machine as the clients,
so there's no point to SSL.
- Many more run MySQL only on a trusted network, such as between a
group of machines in a colo, with the MySQL server firewalled so that
it only accepts connections from its LAN peers. To get a sniffer onto
the LAN to find passwords and such, someone has to break into one of
the peers, at which point it's Game Over anyway.
- Probably most of those that remain don't worry about the security of
the channel; observe how many people send email and FTP passwords in
- Those few that remain have more options than just SSL. Many IT
shops already have functioning VPN and/or ssh infrastructures, both of
which will do this job just as well as SSL, with less setup and
management required, simply because it's already there and working,
and the PKI management has to happen already.
My company falls into the first category now, and if we ever had to
push the DB server off onto another box, we'd fall into the fourth.
Hence, I have never had a reason to dig into how SSL works with MySQL.
On top of all this, MySQL employees seem to no longer be answering
support questions on the MySQL list(s). No doubt they want you to buy
a support contract.
> I am a bit leery of virtualization software.
Every one of the MySQL++ packages, source and binary, is generated on
a VM. tangentsoft.net is hosted inside a VM, too. My company's
binary RPMs are made on a different set of VMs. It's been mature
technology for many years now, which is why it's now being commoditized.
What with the proliferation of CPU cores and the *lack* of
proliferation of programs that can use all of those cores at once, VMs
are going to take over the world. Better get used to the technology.
> I got my code working by specifying the full path to the client key
How about you try it again with a trailing slash on the path? The C
API library might just be blindly concatenating the strings.
> why is the fourth parameter actually needed at all
For myself, all I can say is that the C API wants it, so MySQL++
requires it, too.
If we can prove it's never helpful, we can talk about removing it in
If it's merely rarely helpful, we can move it to the end of the
parameter list so you can leave it at its default, which will also
have to wait for MySQL++ v4.
I'll need research from an interested party such as yourself to be
making any plans for changes, though.
> I am assuming I need some sort of network sniffer to test
That's a good first step, but it can only tell you that the traffic is
scrambled, not how well it's scrambled. To test that, I'd use that
sniffer to dump the raw packet data -- leave off TCP headers and such!
-- and run that through a randomness tester. Such a thing shouldn't
be hard to find on the Internets. Without the key, good crypto is
indistinguishable from an excellent PRNG.
I'd also examine the server logs to see if it will tell you what kind
of encryption it has negotiated. You might have to bump the log level
to get it to tell you this.
I'm worried by the fact that you didn't get MySQL rebuilt on your
local machine. If it's true that the distributed MySQL binaries have
no encryption in them, that applies to the C API library, too, not
just the server.
Until you examine the logs and test the encryption, assume that either
a) it's quietly failing to negotiate a secure channel due to lack of
cypto support; or b) it's using only 40-bit encryption, so as not to
provide Syrian terrorists with the ability to make dangerous roadside