5

Scenario:

A web server with a web app for remote staff. The web server is behind a reverse proxy (traefik) The web server has a host based firewall configured to allow connections only from the proxy on the designated port. Those connections use TLS. The only other open ports are ssh, zabbix agent and ntp from 10.0.0.0/8 (ssh and zabbix from specific IPs).

The proxy server listens on 80 and 443 and redirects 80 to 443 (and sets HSTS headers). The proxy server enforces mTLS for the domain hosting the webapp but also proxies for other web servers that use only regular TLS. The proxy server has a host based firewall configured to allow incoming 80/443 from anywhere and ssh and zabbix agent from private IPs. The proxy server currently runs a minimum install of Oracle Linux 8 with SELinux in enforcing mode.

The proxy is behind a network firewall that NATs the public IP to a private IP and only allows traffic to 80/443.

The client certs are generated using a private CA (on internal network, not connected to the Internet) and the certs are then installed in the users' cert store so they can access the web app URL from their browsers.

Question:

Assuming for the purpose of limiting the scope of this question that a) the certs remain uncompromised and b) there are no insider threats, what vulnerabilities remain for the web server? In other words, what attack vectors does an attacker have that is outside the network and who does not have access to a valid cert?

Improve this question
3
  • Please clarify? Will your proxy forward a mTLS connection request to the web-application, which will then establish the connection and verify the certificate? Or will the proxy establish an mTLS connection with the client and itself create a new connection with the web-application (in which case the web-application would not see the client certificate at all) ? Commented Nov 14, 2024 at 12:35
  • @Falco The proxy terminates the TLS connection (and a new TLS connection is created to the backend). Client cert and CRL are verified by the proxy. Commented Nov 14, 2024 at 22:12
  • Does the proxy require mTLS with a valid client certificate for any connection? Because certificates are provided in the connection phase, before the details of the HTTP request are clear... ? If it doesn't then SNI spoofing could be an issue you have to deal with. Commented Nov 15, 2024 at 9:23

3 Answers 3

Reset to default
12

All threats remain except for a handful you've either actually mitigated (like man-in-the-middle attacks) or ruled out per assumption.

For example, you haven't mentioned any countermeasures against cross-site request forgery (CSRF). If CSRF is possible, then the whole distinction between “insider” and “outsider” falls apart, and an attacker can try the entire catalog of classical attacks: SQL injection, cross-site scripting, exploiting broken access control etc. Clickjacking can be another method for making a legitimate user unwillingly perform actions on behalf of an attacker.

It's generally dangerous to rely on perimeter-based security alone. Besides CSRF and Clickjacking, insider threats do exist in reality, and private keys do get compromised (especially when users store them as files without proper protection). So the web application has to be able to withstand all possible attacks by itself, regardless of how many proxies, firewalls etc. you've put in front of it. Don't assume it will only have to deal with “harmless” requests sent by legitimate users.

Improve this answer
5
  • Thank you. Can you elaborate? Of course all threats bar those I mitigated remain. That's exactly what I'm asking about. what are those threats? You mentioned CSRF. What else is there, again, assuming the attacker is outside and does not have a valid cert for the server.. I understand that the insider threats exist. I just want to limit the scope of the question. I first want to make sure I considered all reasonable threats that fall within the scope of the question. Commented Nov 13, 2024 at 0:34
  • 5
    @IamNaN: Like I said, CSRF breaks the barrier between “inside” and “outside”, so making this distinction isn’t useful and probably even counterproductive. Proxies, firewalls, strong authentication etc. are all reasonable security measures, but the web application cannot rely on them. When you assess the security of the application, assume that an attacker can send any request they want. This means you have to deal with the same threats as any other web application. If you’re not sure what those threats are, the OWASP Top 10 are a good starting point. Commented Nov 13, 2024 at 1:26
  • @IamNaN Unfortunately, not only is the current threat landscape vast, it's constantly changing (generally getting larger). A list of all, or even almost all, possible threats doesn't seem feasible in a stack exchange answer. If you want to effectively evaluate the attack surface of a system you support, my strong recommendation is to use one or more vulnerability scanning tools and/or services. If you dive into these tools and the supporting documentation, you'll find that there can be thousands of vulnerabilities for a single component of a system. Commented Nov 13, 2024 at 19:22
  • "and private keys do get compromised (especially when users store them as files without proper protection)" The windows keystore has the ability to store client certs such that the user is allowed to use them in e.gg. browser requests but not export the private key (I've read that admin users can work around this.) I'm curious what your opinion is on this type of scheme in general and in Windows. Commented Nov 14, 2024 at 22:21
  • 1
    One way to look at it: There is a whole variety of possible attacks, which stem from the fact of using the same application (a browser) for your protected app as well as executing third party code (other websites). Most stem from the fact that the code of different websites can interact (CSRF, click jacking, iframes, parameter injection, ...) some from the fact that code runs in the same process (extensions, timing-attacks, out of bounds memory access, ...) Commented Nov 15, 2024 at 9:33
3

You haven't really stopped web-based attacks... the server is still accessible by the general internet on ports 80 & 443. Any number of attacks against web servers are still available to would-be hackers.

Since this isn't a web application you want the general public to have access to, you should put it all behind a private VPN (ie wireguard, etc) and only allow authorized users to connect to the VPN.

Improve this answer
2
  • 4
    A web application which sits behind a proxy enforcing mTLS (as described by the OP) is not accessible to the general public, only autorized users -- just like in your VPN. Commented Nov 13, 2024 at 6:35
  • I know of at least on VPN that uses mTLS as part of its client authentication. Commented Nov 14, 2024 at 22:10
2

You mentioned that the same proxy serves a number of different domains, and some of these domains do not require client certificates, so in addition to the attacks mentioned elsewhere, you should ensure that you're not vulnerable to domain fronting. If someone establishes a TLS connection for one of the no-client-cert domains, but once connected makes a request whose "Host" header is that of the domain that requires a client cert, does that request succeed?

Improve this answer
2
  • 1
    Whether domain fronting constitutes a vulnerability depends on your threat model. Historically, major hosts turned a blind eye to it. This did eventually change, probably in part due to the ACME TLS-SNI vulnerability (this, despite ACME TLS-SNI being blocked once the vulerability was discovered). Commented Nov 13, 2024 at 15:40
  • 1
    @Brian yes, I took an educated guess that for OP's threat model, being able to access the mTLS host with a non-mTLS connection constituted a vulnerability. For many common setups this isn't a plausible scenario. Commented Nov 14, 2024 at 9:41

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.