Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 Mar 2013 21:51:53 -0700
From:      Mehmet Erol Sanliturk <>
To:        Doug Hardie <>
Cc:        " List" <>
Subject:   Re: Client Authentication
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sat, Mar 23, 2013 at 9:22 PM, Doug Hardie <> wrote:

> 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

Using Static IP in the client side , and checking Static IP of the user may
be a possibility :
In that way , any message from another IP will not be accepted .

If this is possible for your systems , it may be checked for usability .

One difficulty is that each user should obtain a Static IP and can not
connect to his/her ISP from another IP .

Good side is that nobody can connect to ISP of the user from another IP :
It supplies hardware security ( we are assuming that the user computer is
not captured ) ..

Thank you very much .

Mehmet Erol Sanliturk

Want to link to this message? Use this URL: <>