Okay, so, you’re a new webmin like me and you’re trying to figure out passing keys around. You figure out that maybe nginx can store the keys, and then you can have it talk SSL to the browser, and fetch pages from the actual services via http. This means that the actual servers/appliances/whathaveyou don’t need to have keys, just nginx, and everything works.
So you go looking for what that arrangement looks like, and on a random tutorial page you see the phrase “SSL Termination,” implying there’s some secret knowledge you don’t have yet about what this process is actually called. Well, it turns out that’s exactly what it is, and if you start looking you get immediately directed here to the best graphic available. I’ve recreated it below to avoid copyright headaches when I inevitably get famous:
What’s this graphic saying? Well, it’s saying that you, with your browser, are trying to go to these sites via HTTPS, because you want a secured connection. The revers proxy is more than happy to take those requests, and then toss the SSL certificate at you to make the browser happy.
But what it’s doing in the background is taking that request, and pulling the page via HTTP inside the local ethernet. The server never knows anything other than HTTP, and it doesn’t even need to be doing it on port 80; in fact, it’s better if it doesn’t because a misconfiguration could expose an HTTP service to the Internet directly and you don’t want that. So an HTTPS request on port 443 becomes, who knows, 8080, and bam – browser’s happy, you’re happy, the server never needs SSL certs. You just need either a wildcard cert (validate anything in this domain) or you need to have a cert which lists that host, like “service2.domain.com.”
I haven’t done this yet so this is more of a rant, but my god–I’d forgotten, in the Marianas Trench that is industrial controls and automation, that much of IT knowledge is locked away in industry terms that you have to know exist before you can unlock their secrets. “SSL Termination” doesn’t mean anything to the casual reader, but it’s the magic code that lets you find out you can use a reverse proxy to handle the SSL side of things, and then silently pull the data from the server and pass it to the browser.
It feels like a permitted Man-in-the-Middle attack; you have a thing sitting between the server hosting the data and the client trying to get it, silently rewriting the requests down to HTTP. And the reason it’s permitted is because with SSL you notionally have to prove you own the infrastructure and all the servers required to set it up. But get control of that server, and now you can serve up anything with the fancy lock; get control of the reverse proxy, and the pages being passed via HTTP are completely open to rewrite at some level.
But then I guess that risk exists no matter what you do, and you’re not increasing the attack surface so much that it’s not worth having reverse proxies, load balancing, and all the other niceties this arrangement provides.