Menu
▾
▴
#19 add client certificate support
This patch is against davfs2 1.1.4. It adds client certificate support.
I did it by looking at the cadaver code and adapted their provide_clicert() callback function.
I added 2 parameters to the args struct and modified the read_secrets() function, so the certificate file's path and decryption password are read from 'secrets' file.
As I'm lazy, i also copied the getpass.[ch] from cadaver (comes from fetchmail), so I had to modify Makefile.in and configure.in a bit (you'll have to rerun ./autogen.sh).
It works for me, but it's not perfect (I'm not a coder). You are free to use it or not. However, if someone suggests improvements, i'll be glad to rework it.
patch to use client certificates
Logged In: YES
user_id=1260327
Originator: NO
Hello Geoffroy,
thanks for the patch.
At the moment I am very busy (earning some money) so I only had a short look at the patch. But I am pretty sure that it will be included in the next version. There will also be some questions about the implementation details I would like to discuss with you.
As soon as I have got more time (in about two weeks) there will be a more detailed response.
Greetings
Werner
Logged In: YES
user_id=1688208
Originator: YES
Hi Werner,
Thanks for your reply. I'm looking forward to reading your comments. In the meantime I will try to get some time to improve the patch.
Geof
Logged In: YES
user_id=1260327
Originator: NO
Hello Geoffroy,
as promised here is a more detailed response. Your patch touches some more general problems, that are not yet solved in davfs2, so this response will get a bit lengthy.
Portability:
------------
When I first saw your patch, I wondered why it is that big. Then I had to learn: this is to make it portable.
davfs2 already has code to read a passord (in mount.davfs.c, ask_auth()), that was introduced by Joe Feise, and works very well. I did not even know there is a get_pass function in libc. But while the GNU version of get_pass can read passwords of arbitrary length and could be used easily, on some platforms get_pass has a restriction on the length of passwords.
At the moment davfs2 only works on GNU systems, because there are some more functions where it relies on GNU extensions or enhancements (e.g. getopt_long). So whether you make your patch portable or not does not make much difference, as davfs2 is not portable anyway, and we can as well leave this problem to be solved later. I believe it is not such a pressing matter, as most people that are interested in davfs2 run some kind of GNU system. But davfs2 should be made portable some day.
It is your decision how to deal with this:
- you may just use the libc funtion get_pass. This would make your patch more simple (so it is easier for me to understand it)
- or you may make it portable, just as an example for further work in this field.
If you want to make your patch portable, it would be nice if you could have a look at http://www.gnu.org/software/gnulib/. At a first glance I would prefer this way over building libraries (but I have no experience in portable programming).
Internationalization / NLS / GNU gettext:
-----------------------------------------
Your patch includes the GNU gettext sources. Here again, davfs2 does not support NLS at the moment, so including it for your patch does not make much difference. But this time, NLS is on top of my TODO list. I just started work by learning a bit about gettext, and in the CVS-sources I just marked the messages to be translated.
I think, It would be easier to gettextize davfs2 in the whole, if your patch did not already include the gettext package.
I also intended, not to include the gettext sources, but to make it a prerequisite that GNU gettext is installed on the useres system. This would help to keep davfs2 simple and small (so I am able to maintain it). I also did this with the Neon package, and it seems to work. But please tell me, if you know of any problems with this aproach.
But now some remarks on the main point, support for client certificates:
------------------------------------------------------------------------
While your approach is straight forward, there are one major and two minor issues to consider.
Daemon mode and user interaction:
When mounting succeeds, mount.davfs forks into daemon mode and user interaction is no longer possible. The first HTTP-requests are done before this, so there should not be a problem, but there is one. Servers might allow unauthenticated access for some resources, but demand authentication for others. This is especially true for the first OPTIONS request (I had problems with this). So it might happen, that the first time we need the password from the user, mount.davfs is already in daemon mode.
The solution I use for the credentials is, to ask for them in main(), before forking. This might be useful for the certificate password as well:
- in main call some function that will
- check whether the certificate is encrypted
- whether we need to ask the user for a password
- and if necessary ask the password from the user
- it might be be usefull to decrypt the certificate at that stage and pass the decrypted certificate to dav_init_webdav, instead of the file name. But this seems to be a matter of taste.
How to change the secrets file:
You have choosen to read one line, that contains all that is necessary. There is one problem, we have to deal with: the user may choose to let some fields empty, as they are not needed (e.g. the user does not want to write the passwords into secrets, but to enter them at the terminal). This might be: username, password, certificate password.
One way to deal with this, would be to use empty strings (""), but this must be documented in the secrets file.
Another approach would be to use two lines: one for the credentials (as is now), and one for the certificate and its password. The second solution would need some kind of key-word, to distinguish it form the credentials line, e.g. like this
'http://foo.bar/dav usercert /home/otto/privat/mycert.crt geheim'
where 'usercert' is the keyword. This would need docoumentation too.
None of this is very nice, maybe there is a better solution. If not I would prefer the second one.
Directory for certificates:
Maybe it would be a good idea to offer a standard directory for client certificates, like
'~/.davfs2/certs/private' for users, and
'[/usr/local]/etc/davfs2/certs/private' for system wide useable certificates.
When choosing this, we should have in mind, that maybe some day there will be a directory for server certificates, that can not be verified, but that the user wants to accept anyway.
Greatings
Werner
Logged In: YES
user_id=1688208
Originator: YES
Hi Werner,
Thanks for your response, i have not really tried to make my patch clean before submitting it because I needed a quick and dirty hack. My apologies. This is why I included the getpass.[ch] files and gettext (because getpass uses it). I already noticed the ask_auth function, I'll try to figure it out. For the secrets file: I like to have one line, and would prefer to put an '-' for fields left empty but it's a matter of taste. The default client certificate directory is also a good idea.
I learned a lot from your answer. I'll take the time to respond more in depth and work on the patch in the next few days.
Geoffroy
Logged In: YES
user_id=1260327
Originator: NO
Hello Geoffroy,
I intend to implement client certificate support into davfs2 next week. Are you still on the subject, so you might give me some hints and suggestions about what you have done so far, what problems may show up, desired features etc?
What I intend to do (as far as I thought about it):
- additional to client certificate support, I will also add support for server certificates, that can not be verified the normal way, but that have been verified by the user.
- add directories 'certs' and 'certs/private' to the config-directories of davfs2. This will hold the user-verified server-certs ('certs') and the client-certs ('certs/private').
- the name of the certificate files (server and client) must be given in the davfs2.conf-files. I think there is no need to keep this names secret.
- the passphrase for the client-cert must be given in 'secrets' in a line containing certfile-name and passphrase (so changes for the secrets file will be minimal).
- decryption of the client cert should be done in function dav_init_webdav(), so we still have a terminal and can ask the user for the passphrase if necessary. The decrypted certificate will be stored in a global variable to be used by the provide_clicert() function.
- if the option ask_auth is set 0, the user will not be asked for the passphrase. If not found in secrets mounting will fail instead.
- I will use the getpass() function and leave protability issues to later generations.
What is your opinion about this?
Cheers
Werner
Logged In: YES
user_id=1688208
Originator: YES
Hello Werner,
Sorry for the long response time. I'm very busy at work and looking for a new home.
I'm still investigating some problems I encountered with davfs, like the zero size files bug (thanks for the suggestions). Right now, I haven't done much regarding client certs, apart from reading the code and trying to figure things out a bit. I'll be happy to test your implementation of client certificates.
btw i agree with you on the implementation ideas bellow.
Thanks
geoffroy
Logged In: YES
user_id=1260327
Originator: NO
Hello Geoffroy,
I just released davfs2-1.2.0 with client certificate support. Please have a look at it.
Cheers
Werner