On Wed, 20 Nov 2002 11:29:26 +0100 (MET), Andreas Jusek wrote:
>Hello,
>I am developing an SSL-secured client/server application. In one special
>case, the client machine isn't trusted to be secure. Therefore I can not
>put a CA's certificate into the filesystem, because otherwise an attacker
>could exchange it and redirect the next connection to the server to his own
>machine being certified by the fakeed CA's cert.
I don't follow you. If this key secures the client, what stops an attacker
with access to the client from disabling the security check entirely? Are you
saying this key secures the client from itself?
>Since the connection is always established to the same server, which is
>certified by an internal CA, I'm thinking about hard wiring the CA's cert
>into the clinet's code. Does anyone know how this can be done? How can I
>put the contents of the file into an X509 object in the source code?
You can hardcode the DER or PEM key into an array in the program. But what
stops an attacker from modifying the executable?
>Does anyone have a better idea how to cope with this situation?
You have to clarify what it is you're trying to do. Fundamentally, you can't
protect the client from the client. If the key is to protect the client, and
someone can compromise the client, what is left to protect?
You can use a key, stored in the client, to protect the client from a
malicious server. The client would confirm the server's key and on that
basis, the client could trust the server. But someone who can attack the
client directly needn't bother sabotaging the client's key, he could disable
the security check entirely, couldn't he?
Is this an anti-theft feature? If so, why not have the server send the
client information it couldn't obtain any other way? This is far more secure
than a hard-wired key.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
