Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 Mar 2013 21:22:07 -0700
From:      Doug Hardie <bc979@lafn.org>
To:        "freebsd-questions@freebsd.org List" <freebsd-questions@freebsd.org>
Subject:   Client Authentication
Message-ID:  <B2DC7342-9F1A-489A-94F0-49802B1E5DF6@lafn.org>

Next in thread | Raw E-Mail | Index | Archive | Help
I am not sure this is the best place to ask this, but I didn't see any =
other maillists that seemed more appropriate.

Basically, my outgoing mail server is being systematically attacked to =
try passwords looking for one that works.  When they do find one, we get =
inundated by spam sent through that account throughout the world.  The =
situation is such that most of our users are older and their computer is =
a hand-me-down so they can talk to their grandchildren.  Passwords are a =
great inconvenience for them and create numerous problems with =
remembering them even when they are simple.  Unfortunately, most of them =
are quite easy to guess.

Telling users to use more appropriate passwords is a complete waste of =
my time.  Its never going to make any changes as they probably would not =
remember any other password (or where they wrote down the password).  =
This situation requires a technical solution.

I have been investigating the use of client authentication through SSL.  =
DoD uses this approach by having the certificates on an ID card and a =
card reader on each computer.  We don't have the money to use that =
approach no could we every get our users to spring for that.  I was =
hoping to figure out a way to put the certificate on a flash drive or CD =
that the user would carry.  The approach we use has to also work for =
iPads, smart phones etc that do not have an interface for a card reader.

At this time, I have successfully configured a test for openssl client =
authentication using a client certificate.  There are a few issues =
remaining.  DoD uses a p12 format for their certificates.  Many browsers =
support that format.  It encrypts the certificate and private key so =
they are not easily obtained from the smart card.  Openssl's s_client =
uses pem certificates and the key has to be included in the certificate =
file.  While that is easily transported on CD or flash drive, the =
private key is in the clear on the device.  Thats not really viable.

S_client works properly without a certificate when the certificate check =
in the server is set to not fail if a certificate is not provided.  This =
is needed because we will never get all our users to use this approach =
at home.  They will still want to use passwords.  Since the certificate =
request is made before the connection information is available, there is =
no easy way to request it only when needed.  I have only been able to =
test with the Safari browser and it does not handle the no certificate =
case properly.  I believe it is dropping the connection when the user =
does not select a certificate.  I still have to test the other browsers.

There is an interesting aspect of openssl that the certificate it uses =
for normal SSL authentication is not used for client authentication.  =
There are another completely different set of calls that have to be made =
to set the certificate/key for use in validating the client =
certificates.  Much of this is only documented in existing code.

With Safari you have to import the client's certificate into the =
keychain.  Then it works fine.  Unfortunately, it doesn't go away when =
you are done with it.  Unlike the smart card which, when removed, =
removes the certificate, the Safari certificate can continue to be used =
by anyone afterwards.  Hence, its not all that useful for =
authentication.  One approach I have heard about, but not investigated =
yet is to place the keychain on the removable device.  That would make =
it go away.  However, that approach would not work with any other =
browser or mail program.

Any ideas/suggestions on this will be appreciated.  Thanks,

-- Doug=



Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?B2DC7342-9F1A-489A-94F0-49802B1E5DF6>