Re: Problem (again!) with openssl!

[Jan Danielsson <jan.m.danielsson%gmail.com@localhost>]

On 28/07/14 19:51, Paul Goyette wrote:
> On Mon, 28 Jul 2014, Dave Huang wrote:
> 
>> http://www.washington.edu/imap/documentation/SSLBUILD.html makes it
>> sound like there's no configuration setting for the key/certificate
>> path. Putting a private key in /etc/openssl/certs sounds bad for
>> security to me, but maybe I'm making it a bigger deal than it really
>> is.
> 
> Well, the contents of certs directory are all set to 644, while the
> ca.key (in /etc/openssl/private/) is 600, so it also feels bad to me.
> 
>>
>> In any case, that page says, "The imapd.pem and ipop3d.pem must
>> contain a private key and a certificate.  The private key must not be
>> encrypted." So, you'll need to find the file that contains the private
>> key that matches that certificate, cat the key and the certificate
>> together, and put the combined file at /etc/openssl/certs/imapd.pem
> 
> This works.  But still not so sure that I want the key file to be world
> readable...

   The key file should only be readable for the process which is going
to use it.  Some daemons read the key as root, and then switch uid.
Like I mentioned elsewhere, sometimes programs simply refuse to start if
the file the key is in doesn't have sufficiently restrictive permissions.

> Why would the _server_ need to access they key?  Wouldn't it make more
> sense for the _client_ to prove it possesses the key?

   This is a handshake issue; you don't have mutual authentication. This
setup "only" (importance not to be underestimated) allows you to be
certain[*] you've connected to the proper server, and once that has been
done then your login credentials (passed over the encrypted channel) are
used to prove that you are who you say you are.

   Anywho.. The handshake..

   Public certificates contain the public keys, which can be used to
verify signatures made using the private key.

   This is merely a conceptual description of what is happening, but it
shows why you need the CA certificate, and both the server certificate
and key.

   The server sends over its public certificate to your client.

   It sees "Aha! This is issued by Acme Inc CA!" which you have stored
locally on your client. So it checks the signature in the transmitted
server's certificate using the public key stored in the CA certificate
you have.  This way, you know that the server certificate, in fact, was
issued by your trusted CA.  However, how do you know someone else didn't
just copy the server's public certificate and are using it on their own
machine?

   This is where the server's private key comes it.

   The server signs a message and sends it over to the client (which now
knows it can trust that the server certificate is "proper" in some
sense, but it can't know that the machine using it is the one who is
supposed to have it).

   By verifying the signature of the message using the _server's_ public
key, the client knows that the server is in possession of the key, and
can be trusted.  In some sense...


   Mutual authentication is essentially the same deal, but .. also the
other way, so the client has a similar handshake.  A lot of practical
issues arise with client authenticated SSL/TLS, unfortunately.  :(


   [*] Given that all the proper verifications are done, of course.

-- 
Kind Regards,
Jan