Is there a way to access a MySQL database over the network from PHP and be confident that

the connection is actually using SSL, and

the server's X.509 certificate was successfully verified?

As far as i can tell, when using the stock MySQL bindings, setting MYSQL_CLIENT_SSL is purely advisory (i.e. it won't fail if the server doesn't advertise SSL support). This means it won't defend against an active network attacker performing the equivalent of sslstrip.

Even if MYSQL_CLIENT_SSL was stronger than an advisory flag, i can't seem to come up with a way to tell PHP's basic MySQL bindings the equivalent of the --ssl-ca flag to the mysql client binary. Without being able to configure this, a "man-in-the-middle" should be able to intercept the connection by offering their own certificate on their endpoint, and otherwise relaying the traffic. A client that does not verify the server's identity would be none the wiser.

One option to avoid a MITM attack would be for the server to require client-side certs via the REQUIRE option for a GRANT statement, but the basic MySQL bindings for php don't seem to support that either.

PHP's mysqli bindings (MySQL Improved, i think) feature a command called ssl_set() which appears to allow client-side certificate support. But its documentation isn't clear on how it handles an invalid/expired/revoked server certificate (let alone a server that announces that it doesn't support SSL), and it also mentions:

This function does nothing unless OpenSSL support is enabled.

Given that debian MySQL packages don't use OpenSSL because of licensing incompatibilities with the GPL, i'm left wondering if packages built against yaSSL support this feature. And i'm more than a little bit leery that i have no way of telling whether my configuration request succeeded, or whether this function just happily did nothing because the interpreter got re-built with the wrong flags. Shouldn't the function fail explicitly if it cannot meet the user's request?

What's going on here? Does no one use MySQL over the network via PHP? Given the number of LAMP-driven data centers, this seems pretty unlikely. Do PHP+MySQL users just not care about privacy or integrity of their data?

Or (please let this be the case) have i just somehow missed the obvious documentation?

Other engineering societies (IETF, USENIX, etc) continue to do socially relevant, useful work without attempting to control copyright of work contributed to them. This just makes IEEE look like a power- and money-hungry organization, rather than a force for positive advancement of technology.

For shame, IEEE.

I will not consider reinstating my membership unless the organization changes their copyright assignment and publication policy to better reflect the spirit of scientific inquiry and technological advancement they should stand for.

Let's say you set up a machine using an encrypted disk with LUKS (debian-installer's partman makes this wonderfully easy!). You choose an initial passphrase, get the machine working, and it's working great. Then, you need to restart it, and realize that (for whatever reason) you've forgotten or lost the passphrase for the volume. oops! (i'm sure this has never happened to you -- let's just pretend it's your less-fortunate friend).

If your system is still running, and you have superuser access to it, you can actually set a new passphrase for the LUKS volume using information that the dm-crypt kernel module has about the in-use mapping. In my examples, i'll imagine that the source volume is /dev/XXX2 and the exported cleartext volume is known by the device-mapper as XXX2_crypt

In the bigger picture, this should serve as a reminder that even though your disk is encrypted, if someone gets live access to the superuser account on a system with the encryption keys loaded, your data is no longer secret.

Before you do any tweaking, you might want to back up your LUKS header, just in case:

Now, the fix: We pull the live "master key" from the running device map, and fill a new luksKeySlot from it (this example uses bash's <() syntax for process substitution -- if you use a different shell, i'm sure you can find a different way to do it):

(note that the luksAddKey invocation above returned an error code of 2 even though it succeeded. I think this is a bug in cryptsetup's return code, not a bug in the password resetting -- it should have returned 0 instead of 2).

You can check to see that a new key slot was enabled by re-running cryptsetup luksKeyDump

And if you really want to double-check before you reboot, you can try enabling a third keyslot using the passphrase you just added, since this would not succeed if your new passphrase failed to unlock any of the existing keyslots:

She has an excellent perspective on the meaning of libraries, and the tradeoffs involved with the current societal trend toward privatizing knowledge through so-called "intellectual property" regulations. In a great critique of the passivity of academia and libraries in the face of attempts at intellectual enclosure by private corporations, she writes:

This uninformed indifference is laying the groundwork for a new tragedy of the commons: a world in which knowledge is turned into intellectual property, monetizied, and made artificially scarce.

She closes with a six-point manifesto that begins:

Liberation bibliography arises out of outrage at the injustice of the current system. It’s not about saving money, it’s about the empowering nature of knowledge and the belief that it shouldn’t be a luxury good for the few.

The article abounds in examples of heinous arrangements in the current system that seem to be accepted as standard procedure, and clear thinking about what the actual tradeoffs are (and how we, as a society, are making them poorly).

If i had one objection, it would be that she neglects to mention increased surveillance as one of the problems that come with privatization of knowledge. Our abilities to read privately and anonymously, and to correspond confidentially are at risk because of these systems of control.

Anyway, I'd love to see more open allegiances between librarians and free software folks; the ideals and struggles are very much in parallel. Go talk to your librarian friends about this stuff today! (and if you don't have any librarian friends, go to your local library and meet them. They're great people, doing important work.)

i suspect a lot of people are used to forwarding TCP sockets with SSH -- for example, to connect locally to a mysql daemon that runs only on the loopback interface of a remote machine (this is debian's default mysql-server configuration):

But sometimes, the remote service runs on a UNIX-domain socket, not on a TCP socket -- for example, debian's default configuration for postgresql is to have it listen only on a UNIX domain socket in /var/run/postgresql, and use SO_PEERCRED with a simple system account == psql account mapping scheme to authenticate users without needing any extra credentials. This is not quite as simple to forward over ssh, but it's doable as long as socat is installed on both your local host and on the remote postgres server.

Here's one way to do it if $SOCKET_DIR points to the full path of a directory under the user's control (this is all one command, split across lines for easier reading):

Each such psql connection will trigger an ssh connection to be made. Of course, this won't work well if ssh has to prompt for passwords, but you should be using ssh-agent anyway, right?

There are at least a couple nice features of being able to use postgresql from a local client like this:

your psql client can load files from your local machine, and can dump/export files to the local machine.

your ~/.psql_history stays local, so you can review what you did even when you're offline

you can run local RDBMS administrative GUIs like pgadmin3 with minimal network traffic and no extra packages installed on the server.

unlike forwarding TCP ports (where any other user account on the machine can hop onto your connection), you can control access to your local UNIX-domain socket with standard filesystem permissions on $SOCKET_DIR.

Of course, postgresql itself already comes with a nice range of high-quality network-capable authentication mechanisms you could use. But many of them (like GSSAPI or X.509 mutual key-based authentication over TLS) require additional infrastructure setup; and you probably already have sshd up and running on that machine -- so why not make use of it?

i've been on an IPv6 kick recently, getting dual-stack systems up and working for a bunch of folks.

I'd like to make some of these services reachable by IPv6-only clients. this suggests that i need a range of details sorted out, but i think the one piece left for me is the glue records for the nameservice. i use in-bailiwick nameservers for DNS where possible, which means i want mandatory glue records. that is, the primary namserver for example.org is probably something like ns0.example.org, which means that the org nameservers themselves need to store not only the NS record, but an A record that corresponds to the name pointed to by the NS.

But for IPv6-only clients that do their own name resolution, i need AAAA glue records, and i haven't yet found a registrar that will push AAAA glue records for the same names as the existing A glue into the org zone.

gandi at least offers the opportunity to enter AAAA glue, but apparently can't let me have both AAAA and A glue for the same name. A note to their support team got me a response that this is planned for Q1 or Q2 of 2011.

Any suggestions for reasonable registrars that offer this today?

Am i being silly in wanting AAAA and A glue for the same names? i note that the root zone and the org zone both offer A and AAAA records for each of their dual-stack nameservers. You can check for yourself:

dig @a.root-servers.net ns org
dig @a.root-servers.net ns .

if i don't go for dual records, i could instead use gandi and go with distinct names for the v6 and v4 servers, like this:

My concern about this is if some IPv4-only system gets a list like the first one, and decides to use c.ns.example.org or d.ns.example.org, which doesn't have an A record at all. That would be a silly implementation, of course. but uh, we have a lot of silly implementations of things out there.

Debian NYC will be holding a workshop next week: What's in a Package? will happen at 7:00pm New York time on October 27, 2010. If you're in the New York area, interested in packaging things for debian and related systems, or just want to understand the packages in your system better, you should RSVP and come on out!

This workshop will provide advanced theory useful for people modifying or creating packages. For people modifying packages, you'll learn many typical motifs and about various build systems. For creating packages, you'll be much better prepared to read and understand guides a deep level. However, this is still not a step-by-step guide in "how to build packages", but will get you very close to there.

Monkeysphere aims at adding a web of trust to the SSL certificates system, but the CA chain problem seems to persist (although I must admit I'm not up to speed with the actual details).

Since i'm one of the Monkeysphere developers, i figure i should respond!

Let me clarify that Monkeysphere doesn't just work in places where X.509 (the SSL certificate system) works. It works in other places too (like SSH connections). And I don't think that the CA chain problem that remains in Monkeysphere is anything like the dangerous mess that common X.509 usage has given us. I do think that at some level, people need to think about who is introducing them to other people -- visual or human-comprehensible representations of public key material are notoriously difficult to make unspoofable.

On the subject of distributed naming: OpenPGP already allows distributed naming: everty participant in the WoT is allowed to assert that any given key maps to any given identity. Duplicates and disagreements can exist just fine. How an entity decides to certify another entity's ID without a consensus global namespace is a tough one, though. If i've always been known as "John Smith" to my friends, and someone else has also been known as "John Smith" to his friends, our friends aren't actually disagreeing or in conflict -- it's just that neither of us has a unique name. The trouble comes when someone new wants to find "John Smith" -- which of us should they treat as the "correct" one?

I think the right answer probably has to do with who they're actually looking for, which has to do with why they're looking for someone named "John Smith". If they're looking for John Smith because the word on the street is that John Smith is a good knitter and they need a pair of socks, they can just examine what information we each publish about ourselves, and decide on a sock-by-sock basis which of us best suits their needs.

But if they're looking for "John Smith" because their cousin said "hey, i know this guy John Smith. I think you would like argue politics over a beer with him", then what matters is the introduction. And OpenPGP handles that just fine -- if their cousin has only ever met a single John Smith, that's the right one. If their cousin has met several John Smiths, then the searcher would do well to ask their cousin some variant of "hey, do you mean John Smith or John Smith ", or even "do you mean the John Smith who Molly has met, or the one who Charles has met?" (assuming that Molly and Charles have each only certified one John Smith in common with the cousin, and not the same one as each other), or to get a real-time introduction to a particular John Smith, where his specific key is somehow recordable by the searcher for future conversations (or beer drinking). This is what we do in the real world anyway. We currently lack good UIs for doing this over the network, but the certification infrastructure is in place already.

What we're lacking in infrastructure, though, is a way to have a distributed addressing. Roland's proposal was to publish addresses corresponding to cryptographic identities within some DNS zone, or in freenet or gnutella. Another approach (piggybacking on existing infrastructure) would be to include IP address information in the OpenPGP self-certification, so the holder of the name could claim exactly their own IP address. This could be distributed through the keyserver network, just like other updates are today, and it could be done simply and immediately with a well-defined OpenPGP notation. I'd be happy to talk to interested people about how to specify such a notation, and what possible corner cases we might run into. Drop a note here, or mail the Monkeysphere mailing list or hop onto #monkeysphere on irc.oftc.net

If you're not using ssh-agent to authenticate yourself to SSH servers, you should be. (i'm assuming you're already using PubKeyAuthentication; if you're still using PasswordAuthentication or KbdInteractiveAuthentication, fix that please).

You should use ssh-agent for a number of reasons, actually, but the simplest is this: when you authenticate to a text-based channel on a remote server, you should never have to type anything about that authentication into the channel that will eventually be controlled by the remote server.

That's because a malicious server could simply accept your connection as an anonymous connection and print out the exact prompt you're expecting. Then, whatever you're typing goes into the remote server instead of into your authentication scheme. and congrats, you just gave away the passphrase for your key.

With ssh-agent, you talk first to your agent. Then, you talk to the server and your ssh client talks to the agent. Your keys and your passphrase are never exposed.

the second reason is that the agent is a much smaller piece of code than the ssh client, and it doesn't talk to the network at all (unless you force it to). It holds your key and never releases it to querying processes; It even runs in a protected memory space so other processes can't peek at it.

So if this protected, isolated agent is what holds your key, you're in much better shape than if a non-protected, larger, network-active process (the ssh client) has direct access to your secret key material.

The third reason is that it's just more convenient -- you can put a key in your agent, and ask it to prompt you when its use is requested. you don't actually need to re-type your passphrase each time. you can just hit enter or type "yes".

And if that scares you security-wise then you can put the key in for a limited period of time, as well.

(btw, you should be using the ssh-agent that ships with OpenSSH, probably not the implementation offered by gnome, which doesn't offer a confirmation prompt, doesn't run in protected memory space, and links in a ton more libraries)

So how do you use the agent? It's probably already installed and running on your computer if you run a desktop with debian or another reasonable free operating system.

Query what keys are in your agent:

0 dkg@pip:~$ ssh-add -l
The agent has no identities.
1 dkg@pip:~$

Add a standard OpenSSH secret key to your agent, prompting for confirmation after each use:

(note that you can combine the -t $SECONDS and -c flags to get key that is time-constrained and requires a confirmation prompt at each use)

Add a monkeysphere-style key (an authentication-capable subkey from your GnuPG secret keyring) to the ssh-agent (this will prompt you for your GnuPG passphrase with a graphical ssh-askpass program during this keyload, if such a program is available), for one hour: