4

Suppose that I have a reverse proxy such as caddy or Traefik that requires a client certificate to authenticate via mTLS, globally across reverse proxy.

What is the attack surface for services behind this proxy exposed publicly?

The handshake fails right from the beginning if the client doesn’t have a valid certificate. The attacker won’t even see the services. It seems similar to SSL VPN.

I assume the attacker is outside.

Improve this question

1 Answer 1

Reset to default
6

A client certificate is basically authentication done at the reverse proxy and only forwarding the data to the backend if authentication was successful. This protects the backend well, as long as

  1. The authentication is strong,
    which is achievable with client certificates but can also be misconfigured, like when not properly checking the certificate.
  2. There is no way around the authentication,
    like a path or domain at the proxy not requiring authentication, direct exposure of the backend, another proxy facilitating access without proper authentication ...
  3. The backend application is well protected against cross-site requests,
    because like cookies in the past (before the changes regarding same site cookies) a previously used client certificate is automatically used when a site is accessed, no matter if direct or cross-site.
  4. The client machine or certificate is not compromised,
    which would enable an attacker to properly authenticate either through the clients machine or by using the compromised certificate from their own systems.
  5. The reverse proxy itself can not be compromised,
    i.e. no attacks against the proxy possible but also not against the system it is running on. It is unfortunately common today that security systems like firewalls have their own serious security issues and thus can weaken security instead of hardening it.
Improve this answer
16
  • 1
    I think in #3 you are talking about a browser or end-user client. I don't think this have much relevance in server-to-server relationships where mTLS is becoming a more ubiquitous solution. Commented Feb 17 at 19:01
  • 2
    @JimmyJames: True, but the OP has set the tag "web-application" which suggests to me that the client of the server is some kind of browser or similar. And client certificates are actually used for web applications too, even though the usability for this is often lacking. Commented Feb 17 at 19:45
  • I didn't notice that tag. I have used client certificates through a browser (more-or-less) experimentally and I came to the conclusion that there are better solutions available. On the server side, however, managing keys is not unique or novel. Commented Feb 17 at 20:02
  • In #4, it could be the certificate itself (and its private key), or the certificate authority (and its private key) used to generate the client certs, or the method used to determine who the CA will give certificates to. And of course (that's probably somewhere in #1), making sure the proxy only trusts certificates from the "right" CA(s). Commented Feb 18 at 0:24
  • @jcaron: Correct, this a more conceptual description where and what can go wrong in general. There are many ways devices, services or certificates can be compromised, how authentication can be bypassed etc. This is not a extensive threat analysis but mainly to point out the various parts which need to play together well instead of just assuming that throwing in client certificates will provide unbreakable protection. Commented Feb 18 at 6:32

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.