0

Assume a server which offers some information which must not be exposed publicly. A client of this which may be e.g. a windows service (or at least something executing headless) needs to access the information on the first server.

So the client needs to trust that he is talking to the correct server and the server needs to trust that he is talking to the correct (authenticated and authorized client).

The information transactions must be obscured, i.e. crypted.

What is the best strategy to achieve this kind of security when it is a requirement that the client is running silently, headless and cannot/shall not ask interactively for credentials from a user on the client site ?

Some kind of integration into AD (another forest) ?

Client certificate (number of clients is fairly low and the burden to handle this is not too big).

Other ?

  • 1
    You really need to first define your requirements properly. Answering this exhaustively would take pages. – Stephane Feb 05 '15 at 10:26
  • Thanks, Client cert. sounds appealing. If the cert. is "stolen" then the credential/identity is stolen, right ? May the client cert. contain e.g. some crypted. info which identifies the client machine ? (As you may understand, security/certificates etc. is not exactly my speciality) – user67764 Feb 05 '15 at 11:13

1 Answers1

1

As per my understanding of your needs, use SSL/TLS with mutual authentication (ie. client cert):

  • It will guaranty both ends identity,
  • Protect the communication confidentiality and integrity,
  • It is a well known standard, largely available allowing quick implementation.
WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104
  • Does TLS also offer mutual authentication (with client certs)? If yes, then that would be [much better](http://security.stackexchange.com/a/70724/49075). –  Feb 05 '15 at 11:45
  • @RickyDemer Yes it does – RoraΖ Feb 05 '15 at 12:53
  • Unless there is an explicit version mentioned ("SSL v2" for instance), when one talks about SSL he usually talks about TLS too. "SSL" being patented by Netscape, a new name had to be found for the developments made over SSL v3, so they called it "TLS v1" instead of "SSL v4" just to avoid potential patent issues ([RFC 2246](https://tools.ietf.org/html/rfc2246#page-74). – WhiteWinterWolf Feb 05 '15 at 15:55
  • @GZBK: That was probably true before POODLE. Even if it were still the case, "SSL" certainly _includes_ SSL v3, so one shouldn't recommend SSL. –  Feb 06 '15 at 05:40
  • @RickyDemer Following your post, I edited my message to talk about SSL/TLS which is technically more precise than talking about SSL. However, technically again, SSL and TLS are just two versions of the same protocol (the latter being safe against Poodle), it is so true [that](https://www.digicert.com/ssl-certificate.htm) [all](https://www.verisign.ch/ts-sem-page/index.html) [certification](https://www.comodo.com/landing/ssl-certificate/free-ssl/) [authorities](https://www.geocerts.com/products/quickssl) always talk about "SSL certificates", neither "TLS certificates" nor "X.509 certificates". – WhiteWinterWolf Feb 06 '15 at 10:49