Proxying with radsec/TLS, Access-Reject leads to "spoofed proxy reply"
Hello, I am playing with radsec. I have set up a proxy-connection between our staging server and an additional testserver to act as homeserver. Both servers are v3.0.10. What I have managed so far is: The staging-server can contact the homeserver and establish a TLS-secured connection. The staging server sends a request to the homeserver and the homeserver will process it. The homeserver replies. If the homeserver rejects the Request, the staging-server will not accept the reply, but discards it with "Ignoring spoofed proxy reply. Signature is invalid" If the homeserver sends an Access-Accept, the staging-server will accept the reply. I have tried the proxy setup without radsec/TLS. In that case both Accept and Reject work. On the homeserver's side I have: client radiustest { ipaddr = $STAGING proto = tls secret = radsec } On the staging-server's side I have: home_server radiusdevel { ipaddr = $HOME port = 2083 type = auth secret = radsec proto = tcp status_check = none tls { ... } } In debug output I first see on HOME: (0) SSL Connection Established on STAGING: (0) (other): SSL negotiation finished successfully I assume, that means that I set up the TLS-part correctly. Then I see on STAGING: Listening on proxy (STAGING, 46303) -> home_server (HOME, 2083) Waking up in 0.2 seconds. (0) Proxying request to home server HOME port 2083 (TLS) timeout 10.000000 (0) Sent Access-Request Id 239 from STAGING:46303 to HOME:2083 length 137 on HOME (0) tls_recv: Access-Request packet from host STAGING port 46303, id=239, length=137 (0) <running>: Received Access-Request Id 239 from STAGING:46303 to HOME:2083 length 137 (0) Sent Access-Reject Id 239 from HOME:2083 to STAGING:46303 length 49 And then on STAGING: "Ignoring spoofed proxy reply. Signature is invalid" 10 seconds later: (0) No proxy response, giving up on request and marking it done (0) ERROR: Failing proxied request for user "radtest@testrealm.de", due to lack of any response from home server HOME port 2083 I have poked around with gdb on the staging server a bit. Within rad_verify() at the point of calc_replydigest() we get to the point of "Received %s packet from home server %s port %d with invalid Response Authenticator! (Shared secret is incorrect.)", (did not appear anywhere in the Debug Output). Does anyone have an idea what the problem could be? Regards and Thanks Susan -- S.Barnes Cologne University IT/Networking Dept.
On Dec 23, 2015, at 10:23 AM, Susan Barnes <barnes@rrz.uni-koeln.de> wrote:
I am playing with radsec. I have set up a proxy-connection between our staging server and an additional testserver to act as homeserver.
Both servers are v3.0.10.
What I have managed so far is: The staging-server can contact the homeserver and establish a TLS-secured connection.
The staging server sends a request to the homeserver and the homeserver will process it.
The homeserver replies.
If the homeserver rejects the Request, the staging-server will not accept the reply, but discards it with "Ignoring spoofed proxy reply. Signature is invalid"
If the homeserver sends an Access-Accept, the staging-server will accept the reply.
That's weird. The code path is pretty much the same for both packets.
I have tried the proxy setup without radsec/TLS. In that case both Accept and Reject work.
OK. I'll have to take a look at it. Probably next week.
I have poked around with gdb on the staging server a bit. Within rad_verify() at the point of calc_replydigest() we get to the point of "Received %s packet from home server %s port %d with invalid Response Authenticator! (Shared secret is incorrect.)", (did not appear anywhere in the Debug Output).
Does anyone have an idea what the problem could be?
Not really.. the code paths for accept / reject are pretty much identical. Apparently not identical enough, though. Either the home server is calculating the authenticator wrong, or the proxy is calculating it wrong. Knowing which one would help. I'd suggest using gdb to look at rad_verify() on the proxy, and rad_sign() on the home server. Ensure that the "secret" variable is set to "radsec" on both ends. Alan DeKok.
On 23.12.15 17:09, Alan DeKok wrote:
On Dec 23, 2015, at 10:23 AM, Susan Barnes <barnes@rrz.uni-koeln.de> wrote:
I am playing with radsec. I have set up a proxy-connection between our staging server and an additional testserver to act as homeserver.
Both servers are v3.0.10.
What I have managed so far is: The staging-server can contact the homeserver and establish a TLS-secured connection.
The staging server sends a request to the homeserver and the homeserver will process it.
The homeserver replies.
If the homeserver rejects the Request, the staging-server will not accept the reply, but discards it with "Ignoring spoofed proxy reply. Signature is invalid"
If the homeserver sends an Access-Accept, the staging-server will accept the reply.
That's weird. The code path is pretty much the same for both packets.
I have tried the proxy setup without radsec/TLS. In that case both Accept and Reject work.
OK. I'll have to take a look at it. Probably next week.
I have poked around with gdb on the staging server a bit. Within rad_verify() at the point of calc_replydigest() we get to the point of "Received %s packet from home server %s port %d with invalid Response Authenticator! (Shared secret is incorrect.)", (did not appear anywhere in the Debug Output).
Does anyone have an idea what the problem could be?
Not really.. the code paths for accept / reject are pretty much identical. Apparently not identical enough, though.
Either the home server is calculating the authenticator wrong, or the proxy is calculating it wrong. Knowing which one would help.
I'd suggest using gdb to look at rad_verify() on the proxy, and rad_sign() on the home server. Ensure that the "secret" variable is set to "radsec" on both ends.
Alan DeKok.
I have set breakpoints at the suggested places and as far as I can see the secret is "radsec" in all cases: Homeserver: Accept: (gdb) print packet->code $10 = 2 (gdb) print secret $11 = 0x1b03e50 "radsec" Reject: (gdb) print packet->code $12 = 3 (gdb) print secret $13 = 0x1b03e50 "radsec" Staging(Client)-server: Accept: (gdb) print packet->code $5 = 2 (gdb) print secret $6 = 0x1955dc0 "radsec" Reject: (gdb) print packet->code $2 = 3 (gdb) print secret $3 = 0x1955dc0 "radsec" Regards Susan -- S.Barnes Cologne University IT/Networking Dept.
I have set breakpoints at the suggested places and as far as I can see the secret is "radsec" in all cases:
I've pushed a fix.
Thanks. We don't build directly from git, so I want to make sure I'm picking the right commit as a patch for the 3.0.10 SRPM. I'm guessing it's this one? commit d182083dbda2e64da1955255c18ef26ae27eefb3 Author: Alan T. DeKok <aland@freeradius.org> Date: Wed Dec 30 13:47:29 2015 -0500 Ensure that the authentication vectors are always updated -- Sebastian Hagedorn - Weyertal 121, Zimmer 2.02 Regionales Rechenzentrum (RRZK) Universität zu Köln / Cologne University - Tel. +49-221-470-89578
On Jan 1, 2016, at 10:48 AM, Sebastian Hagedorn <Hagedorn@uni-koeln.de> wrote:
Thanks. We don't build directly from git, so I want to make sure I'm picking the right commit as a patch for the 3.0.10 SRPM. I'm guessing it's this one?
You'll want: d182083dbda2e6 169a837a4ac 7b494d2e6c Alan DeKok.
participants (3)
-
Alan DeKok -
Sebastian Hagedorn -
Susan Barnes