[Modules] mod_gnutls support for looking up SRP user params in SQL DB (e.g., GNUTLSSRPPasswdQuery)

Quinn Slack sqs at cs.stanford.edu
Tue May 24 17:57:00 EDT 2011


I have attached a modified version of this GnuTLSSRPPasswdQuery patch
that properly handles NULL values in the query results.

I have also attached documentation suitable for
http://www.outoforder.cc/projects/apache/mod_gnutls/docs/.

What else can I do to move this patch forward? Get some friends to try
it out and post here that it works? Just let me know.

Thanks,
Quinn

On Mon, May 2, 2011 at 1:48 AM, Quinn Slack <sqs at cs.stanford.edu> wrote:
>> Quinn Slack <sqs at cs.stanford.edu> writes:
>>
>>> Right now, mod_gnutls uses a flat-file SRP verifier to store SRP user
>>> params for TLS-SRP. I would like to implement a database backend
>>> similar to mod_authn_dbd so that mod_gnutls can query an SQL database
>>> for a user's SRP parameters.
>
> OK, I've attached a patch that adds this feature. Example config:
>
>    # requires mod_dbd
>    DBDriver sqlite3
>    DBDParams "db.sqlite3"
>    DBDPrepareSQL "SELECT srp_group, srp_v, srp_s FROM srpusers WHERE
> user = %s;" srp_lookup_user
>    GnuTLSSRPPasswdQuery srp_lookup_user
>    GnuTLSSRPPasswdConfFile srp.conf
>
> To try it out, here are the commands to create an SQLite3 table with
> one user named "user" with password "secret":
>
>    CREATE TABLE srpusers(user TEXT PRIMARY KEY, srp_group INTEGER,
> srp_v TEXT, srp_s TEXT);
>    INSERT INTO "srpusers" VALUES('user', 1024,
> 'nKSKOitJs7z1FcFBsTjvLIOzGQajVYh9NsA6kovP8ju01QQoCDgYl3N8Hy+uR8JdRyB9eQRTV7KQSr5Q+ELQ5iCNlncQkgQP+uNcwMFFpOlk/rqbbRzBXuLU+Pm97TtDEfu/xyWszL9pw2LDIn0HKTFcjQbn80vgNFGjns8tovk=','2kG2UNO7YtbViXyOkmn8zg==');
>
> You can create srp.conf with `srptool --create-conf srp.conf`. Then
> connect to your server with, e.g., `gnutls-cli --srpusername user
> --srppasswd secret 127.0.0.1`.
>
> A few things...
>
> * Since query labels prepared with DBDPrepareSQL are namedspaced
> per-VirtualHost (DBD handles are specific to a server), I need to
> access the VirtualHost's server_rec in the mgs_srp_server_credentials
> callback. So, I added a new server_rec* member to mgs_srvconf_rec. It
> seemed impossible to instead find the corresponding server_rec*
> through the new 2.1+ mgs_find_sni_server, since it looks up
> vhost_cb_rec, not server_rec. If anybody has a better idea of how to
> do this, please do tell.
>
> * It expects the query to return results with columns named
> "srp_group", "srp_v", and "srp_s". Since it's easy to use "SELECT abcd
> AS srp_group, ..." to rename columns in the result set, I think this
> OK.
>
> * srptool has defined its own incompatible Base64 encoding. Instead of
> perpetuating that non-standard encoding, this code expects the srp_v
> and srp_s values to be standard Base64-encoded values. For existing
> SRP passwd files, I have a Python script to convert between SRP Base64
> and standard Base64 at [1].
>
> * This code only supports the standard SRP groups in GnuTLS (1024-,
> 1536-, and 2048-bit). This can easily be changed later, if needed.
>
> On Wed, Apr 27, 2011 at 11:58 PM, Simon Josefsson <simon at josefsson.org> wrote:
>> I think this sounds great.  If it is possible, please design this in a
>> modular way internally so that it is will be easy to write a LDAP
>> backend eventually.
>
> Coo. It is fairly modular. If you look at the code and had something
> else in mind for modularity, let me know.
>
> [1] http://trustedhttp.org/wiki/Converting_between_SRP_Base64_and_standard_Base64
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mod_gnutls-GNUTLSSRPPasswdQuery-20110524.patch
Type: text/x-patch
Size: 11620 bytes
Desc: not available
Url : http://lists.outoforder.cc/pipermail/modules/attachments/20110524/020bccb3/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GnuTLSSRPPasswdQuery.xml
Type: text/xml
Size: 2439 bytes
Desc: not available
Url : http://lists.outoforder.cc/pipermail/modules/attachments/20110524/020bccb3/attachment.xml 


More information about the Modules mailing list