]> git.ipfire.org Git - thirdparty/asterisk.git/commit
res_pjsip_authenticator_digest: Make correct error messages appear again.
authorGeorge Joseph <gjoseph@sangoma.com>
Tue, 28 Jan 2025 16:14:34 +0000 (09:14 -0700)
committerGeorge Joseph <gjoseph@sangoma.com>
Wed, 29 Jan 2025 17:01:13 +0000 (10:01 -0700)
commit5ac08742408fddd2be914b311cc6e6fad020ce3b
tree9cbd3e9aac3cc338d1c8eb0356f11709d0513649
parentc3cf4bd223082b747f6f6cf7b82431b5798147ad
res_pjsip_authenticator_digest: Make correct error messages appear again.

When an incoming request can't be matched to an endpoint, the "artificial"
auth object is used to create a challenge to return in a 401 response and we
emit a "No matching endpoint found" log message. If the client then responds
with an Authorization header but the request still can't be matched to an
endpoint, the verification will fail and, as before, we'll create a challenge
to return in a 401 response and we emit a "No matching endpoint found" log
message.  HOWEVER, because there WAS an Authorization header and it failed
verification, we should have also been emitting a "Failed to authenticate"
log message but weren't because there was a check that short-circuited that
it if the artificial auth was used.  Since many admins use the "Failed to
authenticate" message with log parsers like fail2ban, those attempts were not
being recognized as suspicious.

Changes:

* digest_check_auth() now always emits the "Failed to authenticate" log
  message if verification of an Authorization header failed even if the
  artificial auth was used.

* The verification logic was refactored to be clearer about the handling
  of the return codes from verify().

* Comments were added clarify what return codes digest_check_auth() should
  return to the distributor and the implications of changing them.

Resolves: #1095
res/res_pjsip_authenticator_digest.c