You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
What would it take to support TLS-enabled backends? #12
Hello, I've noticed from the known limitations in the readme that the auth backend cannot use TLS. From the code, I indeed see that socket.http is used and I'm wondering what would it take to make TLS work. I'd be glad to help on that if possible but I don't fully understand the issue yet.
I would have to test it once again, but one limitation that comes to my mind immediately is that haproxy-auth-request connects to IP addresses and not hostnames. That is because DNS lookups are not possible within the Lua script. haproxy-auth-request cheats by pulling the IP addresses HAProxy resolved from the backend structure. So I would need to set the SNI value manually (I don't know whether that's even possible with HAProxy's sockets) and also make sure to properly validate certificates.
I mean I think it's not as simple as replacing socket.http with another library otherwise I guess you would have done it. So, can you elaborate?
socket.http is only used for the HTTP parsing. The underlying socket is taken from HAProxy's Lua Standard library. Non-HAProxy sockets must not be used, they will cause issues. I'm planning to get rid of socket.http in the medium term (8a17b20), but that will change nothing about the SSL situation, because that's a different layer.
The recommended workaround is something like this, pointing the auth request backend to HAProxy itself, listening on localhost, which then forwards the request TLS encrypted to the actual backend. It comes at the cost of two additional TCP connections, but allows the full HAProxy configuration flexibility with regard to TLS verification as well as header rewriting (in case that is required).
backend auth_request_backend
mode http
server proxy 127.0.0.1:8080
listen auth_request_proxy
mode http
bind 127.0.0.1:8080
server example example.com:443 ssl
changed the title [-][Question] What would it take to support TLS-enabled backends?[/-][+]What would it take to support TLS-enabled backends?[/+]on Apr 5, 2020
Thank you for the detailed answer @TimWolla and for the workaround. It'll just be fine for me since doing the actual fix seems far from trivial with my limited knowledge.
Activity
clems4ever commentedon Apr 5, 2020
I mean I think it's not as simple as replacing
socket.httpwith another library otherwise I guess you would have done it. So, can you elaborate?TimWolla commentedon Apr 5, 2020
I would have to test it once again, but one limitation that comes to my mind immediately is that haproxy-auth-request connects to IP addresses and not hostnames. That is because DNS lookups are not possible within the Lua script. haproxy-auth-request cheats by pulling the IP addresses HAProxy resolved from the backend structure. So I would need to set the SNI value manually (I don't know whether that's even possible with HAProxy's sockets) and also make sure to properly validate certificates.
socket.http is only used for the HTTP parsing. The underlying socket is taken from HAProxy's Lua Standard library. Non-HAProxy sockets must not be used, they will cause issues. I'm planning to get rid of socket.http in the medium term (8a17b20), but that will change nothing about the SSL situation, because that's a different layer.
The recommended workaround is something like this, pointing the auth request backend to HAProxy itself, listening on localhost, which then forwards the request TLS encrypted to the actual backend. It comes at the cost of two additional TCP connections, but allows the full HAProxy configuration flexibility with regard to TLS verification as well as header rewriting (in case that is required).
[-][Question] What would it take to support TLS-enabled backends?[/-][+]What would it take to support TLS-enabled backends?[/+]clems4ever commentedon Apr 7, 2020
Thank you for the detailed answer @TimWolla and for the workaround. It'll just be fine for me since doing the actual fix seems far from trivial with my limited knowledge.
Thank you.