Secure Client-Server

  • Thread starter Thread starter Chris Botha
  • Start date Start date
C

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.
 
Chris Botha said:
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
 
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.


Pieter Philippaerts said:
Chris Botha said:
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
 
Chris Botha said:
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
 
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

Chris Botha said:
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.


Pieter Philippaerts said:
Chris Botha said:
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
 
Back
Top