2

We have a series of services exposed as web servers. Potentially, every web app could contact and be contacted by any other one. I want to secure the communications between the applications, which means ensuring that both parties are who they say they are. I want my applications to only be allowed to communicate between themselves: this is not a matter of frontend-backend communication, and no app is in the hands of customers or external users.

That said, I also want to avoid the complexity of setting up a CA, generating TLS certificates and so on. We want the security checks to be as streamlined as possible, and possibly easy-maintenance and easy to migrate. Also, we are going to add new applications, and the current method (which I'll describe in a second) is already too cumbersome according to my manager.

I want to understand what the risks are in a scenario in which we implement a quasi-PKI infrastructure, which means I would use industry-recognized encryption algorithms (no custom encryption at any stage) but in a custom workflow.

Let's consider a single connection between a provider and a consumer of the service, and for simplicity's sake let's call them server and client.

All connections are HTTPS-based, except maybe when developing. This should take care of MitM attacks and of server authentication.

What we currently have is as follows. The server has a registry of authorized client applications, and each of them has a GUID and a secret key. When a client contacts the server, it sends its GUID in a custom HTTP header; the server recognizes the GUID from the registry and challenges the client to an authentication challenge (essentially HMAC): a request is sent to the URL stored in the registry, containing a random string, the client responds with the result of encrypting the random string using its secret key (for example with RSA-256). If the server receives the expected response, then the client is authenticated and the response is served.

The secret key is never sent over the network, which keeps it safe, and the challenge string changes every time, which protects against replay attacks.

The weakness is that, if a third party learnt the client's application GUID, they could make requests to the server and the server would send the challenge to the real application, without noticing. This can be fixed either by checking the provenience of the request (but I think that can be spoofed) or by making the client record its requests, so that it rejects authentication challenges that do not match a request it made.

However, this system requires us to define the client application in the registry, pair the access information in the registry and in the client's configuration, and implement the challenge handler in the client. Also, access information may be different between development, staging and production (I'd say it's best it be different). If we factor in 15-20 applications (and growing), each managing its registry as a server, each potentially being a client of several others, you can see this becomes an important setup overhead.

What I'm aiming for is to remove the authentication challenge. Removing the authentication challenge speeds up the process and eliminates the need for a challenge handler. A server would still keep a registry of authorized clients, with a secret key for each client.

Instead of HMAC, the challenge would be time-based, even though I don't like having an interval during which the result would stay the same (which exposes to replay attacks for a short time). However, I can't figure another way to have an always-changing authentication code without the server offering a seed.

So, to sum up, the question is two-fold:

  • is it any less secure to use industry-standard encryption algorithms in a custom workflow (assuming the custom workflow doesn't introduce security holes itself)?
  • how to perform the authentication without the authentication challenge, without also exposing to replay attacks?
  • "I also want to avoid the complexity of setting up a CA, generating TLS certificates and so on." - what you do currently looks significantly more complex and fragil than using a PKI and HTTPS with client certificates to me. – Steffen Ullrich Jul 1 at 14:43
  • @SteffenUllrich I partially agree with you. However, I'm not an expert at setting up a PKI infrastructure (I've done it a few times to setup VPN certificates, but that's far from being an expert), and management is not confident that it will work flawlessly - possibly because none of us has a significant experience with that. What would a minimum PKI setup look like? What does it require, especially in the maintenance phase? – Simone Jul 1 at 16:14
  • With this level of security you currently have (i.e. simple pre-shared secret between client and server) a simple CA like offered by openssl is sufficient. Creating a client certificate is not harder then creating a shared secret, but more secure (no secret known on the server). Revocation can be done by distributing the CRL to the server when needed, which is similar to removing a compromised shared secret from the server. No self-made authentication is needed since common web servers can handle mutual authentication with client certificates and local CRL already. – Steffen Ullrich Jul 1 at 16:29
  • Wikipedia's X509 article is a very good start – postoronnim Jul 1 at 17:16
1

Here's a few thoughts and suggestions.

(1)

All connections are HTTPS-based, except maybe when developing. This should take care of MitM attacks and of server authentication.

At this point you need to have a PKI in place to ensure integrity of connections;

(2)

What we currently have is as follows. (...) The secret key is never sent over the network, which keeps it safe, and the challenge string changes every time, which protects against replay attacks.

Your methodology doesn't look bad at face value, however the major issue is key distribution. How do you handle/store/distribute these secret keys?

(3)

The weakness is that, if a third party learnt the client's application GUID, they could make requests to the server and the server would send the challenge to the real application, without noticing. This can be fixed either by checking the provenience of the request (but I think that can be spoofed) or by making the client record its requests, so that it rejects authentication challenges that do not match a request it made.

I'm not sure how you can verify the provenience of this value. Also sending the challenge code to a spoofed client shouldn't be a security issue in your implementation. As in, this should not be of use for an attacker, as it would if it were netntlm.

(4)

What I'm aiming for is to remove the authentication challenge. Removing the authentication challenge speeds up the process and eliminates the need for a challenge handler. A server would still keep a registry of authorized clients, with a secret key for each client.

Sounds like adding a weakness and complexity.

is it any less secure to use industry-standard encryption algorithms in a custom workflow (assuming the custom workflow doesn't introduce security holes itself)?

You are asking a question with a caveat where the caveat is the answer. If you design and implement a secure system, then the system will be secure. The matter is, however, can you be confident of this?

how to perform the authentication without the authentication challenge, without also exposing to replay attacks?

This is a long winded response. A secure authentication protocol needs resilience against brute forcing, replay attacks and in some ways impersonation of authenticated peers. It is up to you to work out how to do this.

I understand this is the answer you want to avoid. But using PKI with client side certificates addresses most of these points, certainly (1) (2) and (3), and you might be able to forego (4).

| improve this answer | |
  • 2) The keys are pre-shared, offline. They are stored in the application configuration - not too hard to get them, I know, but they never travel on the net, and the attacker should obtain admin access to the machine. – Simone Jul 1 at 16:16
  • 3) The problem is not sending a challenge to a spoofed client - it's that the spoofed client won't be challenged: if he sends an existing application GUID, the application will pass the challenge for him. That's what I fight with request tracking (even more complexity, I know). – Simone Jul 1 at 16:17
  • I partially agree with you about PKI. However, I'm not an expert at setting up a PKI infrastructure (I've done it a few times to setup VPN certificates, but that's far from being an expert), and management is not confident that it will work flawlessly - possibly because none of us has a significant experience with that. What would a minimum PKI setup look like? What does it require, especially in the maintenance phase? – Simone Jul 1 at 16:18
  • Maintenance-wise not much, especially if you create your certs with long validity periods – postoronnim Jul 1 at 17:19
  • Not trying to convince you not to implement this protocol, just pointing out that ruling out PKI is possibly going to cost you in effort to get it right. PKI does address some of the issues you mentioned. – Pedro Jul 1 at 19:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.