Re: Clarification about SSL authentication
Avery Pennarun
On 6/23/08, Lukasz Kosewski <lkos...@navarra.ca> wrote:
> - 1.Support for SSL authentication. WvDBus now handles SSL
> connections properly, but doesn't use the SSL certificate for
> validation.
>
> If you say so, I believe you, but I find it a little suspicious that
> grepping through the dbus code in wvstreams for ssl shows nothing? I
> guess it's something more low-level (like connection streams - go
> wlach and your X.509 hacking) that support this?
WvDBus just does its thing on any stream you care to provide, and you
(usually) provide it using a WvStream moniker. See wvcreate<WvStream>
and so on, as well as the constructors for WvDBusConn and
WvDBusServer.
The trick is we'll now need to find a way to get a copy (or at least
checksum, or something) of the certificate once we're connected.
Perhaps a global WvX509Mgr object (which moniker-created WvSSLStreams
can use) or something is the way to go here, but use your imagination.
Ideally we'd avoid having special command-line options to wvdbusd
that involve SSL, as currently there's no need for that.
> 1.1.The client side (vxodbc) should provide a certificate (saved on
> the client machine using Windows Protected Storage). UniConf already
> has an interface for reading/writing Windows Protected Storage.
>
> OK, do you have any requirements for how/where this is stored in
> protected storage? AFAICS, protected storage is a maze of guids which
> specifies where stuff is stored. Do you have a spec for this? Any
> front-end software which clients/developers will be using to store the
> SSL certificates?
It's been a while since I used this, but we did it in ExchangeIt and
it was somewhat easier than it sounds. My memory is that each
application basically has all its passwords stored under a particular
GUID (which you randomly create and then hardcode into the app), and
then you can use binary key/value pairs under that GUID however you
want. I might suggest something like "moniker = [sslkey]".
> Also, who is validating this certificate? It seems to me that vxodbc
> connects to DBus, do you want WvDBusd to validate this? Part 1.3
> implies that you want versaplex to validate this (since it's the only
> component here that has a configuration file), but then do you want
> versaplexd to validate it /again/? Do you want the client to re-send
> to versaplexd, or have WvDbusd have some way of passing on the public
> key of the client to versaplexd when it asks? Also... doesn't this
> mean we wouldn't really work with SSL over non WvDbus?
Well, only WvDBus currently handles SSL anyhow, so that's a bit of a
moot point for now. But I've thought about it, so...
My idea to do this "more portably" is like this: introduce a new
authorization service (not in org.freedesktop.dbus, but somewhere
else) with a function that maps a DBus connection id (like :153) to an
X509 certificate. In WvDBus, this service will actually be part of
WvDBusd, and the certificate will be provided at SSL setup time. With
other dbus daemons, we could theoretically provide a seperate
authenticator daemon that does an out-of-band SSL handshake somehow,
or CHAP authentication over DBus messages, or whatever. Then once
it's authenticated, it can provide exactly the same authorization
service to everyone else.
Since we know we *could* do that if we wanted, then we won't do all
that work for now (YAGNI). We'll just have the single mapping
function call in WvDBusd directly.
> 1.2.The client side should validate that its connection to the server
> matches the certificate it was expecting (the public key of the server
> should be saved in Windows Protected Storage).
>
> Again; any spec for where in protected storage you want the public key
> to go? Also... I didn't read this carefully enough when I first
> looked at it... I take it "server" here is not DBus or Versaplex or
> whatnot, it's actually a box with a public key.
Basically we just need a way to attach the public key to the ODBC
entry. Perhaps putting a GUID in the ODBC entry, then looking up that
GUID in protected storage, is the way to go.
In this case, the client wants to validate that it's talking to the
WvDBusd that it thinks it is, by checking the SSL server's (in
WvDBusd) public key. Versaplexd should then be able to deal with just
key ids, not actual encryption or authentication.
Incidentally, to keep the versaplexd config file looking halfway sane,
we probably want to have a key-to-user mapping that looks something
like this:
[...big long X509 cert in base64...] = [username]
Much like .ssh/authorized_keys, except we map it to a username so that
we can give each username different database permissions.
> 1.3.The server should check certificate validity and the associated
> username by looking for a matching certificate in the configuration
> file, instead of using a hardcoded userid as it currently does.
>
> I assume by server here you mean versaplexd, but I can't figure out
> which hardcoded userid you mean. You mean the one specified in the
> file? But... that seems like a mapping. I'm not sure where the
> hardcoded name comes from.
Well, there's no getuid() in Win32, so on Windows, wvdbusd always just
returns a hardcoded UID when you ask. That whole system is crap, so
we shouldn't be using it for real authentication purposes.
So we're talking about wvdbusd here. Once you have the username
(note: not uid, which varies by system), versaplexd can just deal with
that. And yes, versaplexd already has a username -> database mapping.
Have fun,
Avery