Secure Client-Server

[Chris Botha]

I got a strange request from a client today, or maybe it is not so strange.
If I write a WEB Service and also an application called ABC to talk to the
WEB Service, is there a way that the server can know that it is application
ABC that is talking, and will allow nothing else? Thus if someone hits the
WEB Service using the browser or any other application, the server should
deny the request. I've stumbled around looking at application signing, etc,
but can not come up with a concrete answer. This means that if there is a
certificate/signature/key-pair/whatever involved, it should live inside the
client app ABC only, and not be readily available in the computer itself, I
guess.

Thanks.

 

[Pieter Philippaerts]

Thus if someone hits the
WEB Service using the browser or any other application, the server should
deny the request. I've stumbled around looking at application signing, etc,
but can not come up with a concrete answer.

If you're using the SSL/TLS protocol to talk to your webservice, you can
turn on mutual authentication.
Mutual authentication means that the server asks the client to send a
certificate and a proof that the client has the private key associated with
the certificate [this proof consists of signing something]. The server can
then decide whether to accept or reject the client connection, based on the
certificate presented by the client.
If you ship your ABC program together with a certificate and private key
that the server will accept, you can make your scheme work. The obvious
danger is that the certificate and its private key get stolen, so you may
want to password protect them. Windows supports such a password protected
certificate container file called PKCS#12 files [usually with the extension
..pfx or .p12].

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl

 

[Simon Smith]

On Fri, 3 Oct 2003 22:47:54 -0400 in article
<[email protected]> in
microsoft.public.dotnet.framework.aspnet.webservices , "Chris Botha"

I got a strange request from a client today, or maybe it is not so strange.
If I write a WEB Service and also an application called ABC to talk to the
WEB Service, is there a way that the server can know that it is application
ABC that is talking, and will allow nothing else? Thus if someone hits the
WEB Service using the browser or any other application, the server should
deny the request. I've stumbled around looking at application signing, etc,
but can not come up with a concrete answer. This means that if there is a
certificate/signature/key-pair/whatever involved, it should live inside the
client app ABC only, and not be readily available in the computer itself, I
guess.

Thanks.

I do something which might work here. I use the WSE (1.0SP1) and have
a library which generates a username and password, and a key for
encryption which WSE uses. This library is referenced by both the Web
Service and it's clients.

The library will generate a random username (the client calls this).
It then has a method to generate a password based on the username, and
an encryption key based on both. When the call gets to the Web
Service, WSE asks for the password for the username and I regenerate
it, the same with the encryption key.

 

[Chris Botha]

Hi Pieter,

Thanks for the answer, but if you don't mind, I have some more questions.
(1) So then in this case, is there anything that the client program ABC has
to do, or is everything handled by the operating system on the client
computer?
(2) If by the operating system, will it know which certificate to send to
the server if there are more than one on the client computer?

Thanks.

Thus if someone hits the
WEB Service using the browser or any other application, the server should
deny the request. I've stumbled around looking at application signing, etc,
but can not come up with a concrete answer.

If you're using the SSL/TLS protocol to talk to your webservice, you can
turn on mutual authentication.
Mutual authentication means that the server asks the client to send a
certificate and a proof that the client has the private key associated with
the certificate [this proof consists of signing something]. The server can
then decide whether to accept or reject the client connection, based on the
certificate presented by the client.
If you ship your ABC program together with a certificate and private key
that the server will accept, you can make your scheme work. The obvious
danger is that the certificate and its private key get stolen, so you may
want to password protect them. Windows supports such a password protected
certificate container file called PKCS#12 files [usually with the extension
.pfx or .p12].

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl

 

[Pieter Philippaerts]

Thanks for the answer, but if you don't mind, I have some more questions.
(1) So then in this case, is there anything that the client program ABC has
to do

The client will have to decide which certificate to send.

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl

 

[Michel Gallant]

If the client has multiple certificates which could be used to
authenticate to the server, the client will be presented with
a dialog to choose one.
- Mitch

Hi Pieter,

Thanks for the answer, but if you don't mind, I have some more questions.
(1) So then in this case, is there anything that the client program ABC has
to do, or is everything handled by the operating system on the client
computer?
(2) If by the operating system, will it know which certificate to send to
the server if there are more than one on the client computer?

Thanks.

Thus if someone hits the
WEB Service using the browser or any other application, the server should
deny the request. I've stumbled around looking at application signing, etc,
but can not come up with a concrete answer.

If you're using the SSL/TLS protocol to talk to your webservice, you can
turn on mutual authentication.
Mutual authentication means that the server asks the client to send a
certificate and a proof that the client has the private key associated with
the certificate [this proof consists of signing something]. The server can
then decide whether to accept or reject the client connection, based on the
certificate presented by the client.
If you ship your ABC program together with a certificate and private key
that the server will accept, you can make your scheme work. The obvious
danger is that the certificate and its private key get stolen, so you may
want to password protect them. Windows supports such a password protected
certificate container file called PKCS#12 files [usually with the extension
.pfx or .p12].

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl