I want to have "some thing" to handle client-certs on behalf a server that is unable to do it, for secure user authentication in addition to regular TLS encryption.
In this question How can I double check security against a TLS on a public IP? the answers set clear that regular TLS does not typically do client authentication, although it seems it would be possible if the server requests it.
Let's suppose I have a server that is able to communicate via "plain text" or "on a TLS channel" (I can re-start the server with or without TLS), but if TLS is enabled, the server does not support checking client-certificates for auth.
The original question was for a docker registry, but I generalize the question to any server supporting TLS but not client-side certs.
What I'm thinking
I am thinking of offloading the "TLS part" to a security-specific software (much similar to what SSH port-forwarding tunnels are) and decouple the server and the TLS handling.
Probably there would be 2 processes involved:
- The server listens in a firewalled localhost port or a linux socket in "plain text", but as it is firewalled it can never be reached from the outside.
- Some kind of "security middleware" (Probably OpenSSL, but I'm not sure) -I think it'd be called a TLS terminator, but I'm neither really sure, too- to do this:
- Handle the public-IP listening
- Handle the server-side certs to secure the channel via TLS
- Handle the client-side certs to check authenticity (probably against a set of public keys I'll have previously uploaded in the server)
- If and only if the client belongs to a white-list of users, then forward the decrypted channel to the regualar plain-text server.
Would be this TLS offloading a normal setup?
If so, is OpenSSL a good handler for this offloading?
If yes, what documentation could be a good starting point for this kind of setup, where I can read on and learn?