From owner-freebsd-questions@FreeBSD.ORG Sun Mar 24 04:25:32 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1B1F3E33 for ; Sun, 24 Mar 2013 04:25:32 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.org [108.92.93.123]) by mx1.freebsd.org (Postfix) with ESMTP id EB06FB46 for ; Sun, 24 Mar 2013 04:25:31 +0000 (UTC) Received: from [10.0.12.8] (cpe-108-184-156-247.socal.res.rr.com [108.184.156.247]) (authenticated bits=0) by zoom.lafn.org (8.14.3/8.14.2) with ESMTP id r2O4M8xq061978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 23 Mar 2013 21:22:09 -0700 (PDT) (envelope-from bc979@lafn.org) From: Doug Hardie Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Client Authentication Message-Id: Date: Sat, 23 Mar 2013 21:22:07 -0700 To: "freebsd-questions@freebsd.org List" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Virus-Scanned: clamav-milter 0.97 at zoom.lafn.org X-Virus-Status: Clean X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 04:25:32 -0000 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=