Reverse proxy: Backend's SSL certificate not verified?

[clsa]

Hello,

we are using OLS as reverse proxy and it pulls the content from our backend server without any issues.

However: The backend server has an SSL certificate from an intranet CA installed, which cannot be known to OLS and therefore it should have no chance to verify it.

Conclusion: OLS very likely doesn't verify the backend server's certificate at all by default.

Is that true? If yes: How can this behaviour be changed?

In other words: What is the OLS equivalent of NGINX's "proxy_ssl_verify", "proxy_ssl_protocols", "proxy_ssl_ciphers" and "proxy_ssl_trusted_certificate"?
(http://nginx.org/en/docs/http/ngx_http_proxy_module.html)

Thank you in advance.

 

[Cold-Egg]

Could you log in to the web admin > Virtual Host > XXX > SSL, scroll the page down to the bottom, there's a Client Verification section, I am not sure if that is what you were asking?

 

[clsa]

No, i didn't mean client verification. This is only useful to secure the connection between client and OLS.

We would like to secure the connection between OLS and the backend, because the subnet is not trusted in our case.

With the current defaults anyone can run a MITM attack on the backend connection and noone would notice.

 

[Cold-Egg]

I see, there's no such feature in OLS currently, not sure if Apache has this feature or this is for Nginx only. The proxy may not verify SSL cert, or fall back to a non-secure connection, so I don't see an actual issue in the real world. Another example is Cloudflare in the front, many users are still using HTTP only in the backend, but there's no security issue. For the backend server, it's better to be protected by a firewall.

 

[clsa]

I'm aware of the proxy being allowed to fall back to insecure connections, but this doesn't automatically make it an desired behaviour for all kinds of networks. This rather qualifies as vulnerability, because the risk is not obvious for the administrator, who usually configures "https://<backend>" for a reason.

You might anyway want to consider implementing proper certificate verification like NGINX offers, because information systems have to apply transport encryption by law in many European countries, if personally identifiable information is processed. With OLS lacking such feature, it's becomes unsuitable for any infrastructure with state-of-the-art security concepts.

I'm not sure, why you think a firewall could help here. Firewalls are packet filters and not responsible for transport security. If an MITM attack is successful, the connection has been compromised regardless of how many firewalls you put between two nodes.

We will probably try to implement a chain of OLS->NGINX->backend now with the first two on a common, trusted host in order to have the best from both worlds: HTTP/3 and enforced transport security

Thank you.