23 Commits (6b107e90f33fe168055f5a7a38f5237ddacfa599)

Author	SHA1	Message	Date
George Joseph	29167b00dc	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	9 months ago
George Joseph	0c272429e6	res_pjsip_authenticator_digest: Fix issue with missing auth and DONT_OPTIMIZE ... The return code fom digest_check_auth wasn't explicitly being initialized. The return code also wasn't explicitly set to CHALLENGE when challenges were sent. When optimization was turned off (DONT_OPTIMIZE), the compiler was setting it to "0"(CHALLENGE) which worked fine. However, with optimization turned on, it was setting it to "1" (SUCCESS) so if there was no incoming Authorization header, the function was returning SUCCESS to the distributor allowing the request to incorrectly succeed. The return code is now initialized correctly and is now explicitly set to CHALLENGE when we send challenges.	10 months ago
Artem Umerov	4c8c37b21b	logger.h: Fix build when AST_DEVMODE is not defined. ... Resolves: #1058	10 months ago
George Joseph	a0987672f0	Add SHA-256 and SHA-512-256 as authentication digest algorithms ... * Refactored pjproject code to support the new algorithms and added a patch file to third-party/pjproject/patches * Added new parameters to the pjsip auth object: * password_digest = <algorithm>:<digest> * supported_algorithms_uac = List of algorithms to support when acting as a UAC. * supported_algorithms_uas = List of algorithms to support when acting as a UAS. See the auth object in pjsip.conf.sample for detailed info. * Updated both res_pjsip_authenticator_digest.c (for UAS) and res_pjsip_outbound_authentocator_digest.c (UAC) to suport the new algorithms. The new algorithms are only available with the bundled version of pjproject, or an external version > 2.14.1. OpenSSL version 1.1.1 or greater is required to support SHA-512-256. Resolves: #948 UserNote: The SHA-256 and SHA-512-256 algorithms are now available for authentication as both a UAS and a UAC.	10 months ago
sungtae kim	f89e56c178	res_pjsip: Expanding PJSIP endpoint ID and relevant resource length to 255 characters ... This commit introduces an extension to the endpoint and relevant resource sizes for PJSIP, transitioning from its current 40-character constraint to a more versatile 255-character capacity. This enhancement significantly overcomes limitations related to domain qualification and practical usage, ultimately delivering improved functionality. In addition, it includes adjustments to accommodate the expanded realm size within the ARI, specifically enhancing the maximum realm length. Resolves: #345 UserNote: With this update, the PJSIP realm lengths have been extended to support up to 255 characters. UpgradeNote: As part of this update, the maximum allowable length for PJSIP endpoints and relevant resources has been increased from 40 to 255 characters. To take advantage of this enhancement, it is recommended to run the necessary procedures (e.g., Alembic) to update your schemas.	2 years ago
Alexander Traud	463f6c83e8	res_pjsip: Fix for Doxygen. ... ASTERISK-29747 Change-Id: Ic7a1e9453f805a6264fe86c96b7d18b87b376084	4 years ago
George Joseph	9cc1d6fc22	res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs ... RFC7616 and RFC8760 allow more than one WWW-Authenticate or Proxy-Authenticate header per realm, each with different digest algorithms (including new ones like SHA-256 and SHA-512-256). Thankfully however a UAS can NOT send back multiple Authenticate headers for the same realm with the same digest algorithm. The UAS is also supposed to send the headers in order of preference with the first one being the most preferred. We're supposed to send an Authorization header for the first one we encounter for a realm that we can support. The UAS can also send multiple realms, especially when it's a proxy that has forked the request in which case the proxy will aggregate all of the Authenticate headers and then send them all back to the UAC. It doesn't stop there though... Each realm can require a different username from the others. There's also nothing preventing each digest algorithm from having a unique password although I'm not sure if that adds any benefit. So now... For each Authenticate header we encounter, we have to determine if we support the digest algorithm and, if not, just skip the header. We then have to find an auth object that matches the realm AND the digest algorithm or find a wildcard object that matches the digest algorithm. If we find one, we add it to the results vector and read the next Authenticate header. If the next header is for the same realm AND we already added an auth object for that realm, we skip the header. Otherwise we repeat the process for the next header. In the end, we'll have accumulated a list of credentials we can pass to pjproject that it can use to add Authentication headers to a request. NOTE: Neither we nor pjproject can currently handle digest algorithms other than MD5. We don't even have a place for it in the ast_sip_auth object. For this reason, we just skip processing any Authenticate header that's not MD5. When we support the others, we'll move the check into the loop that searches the objects. Changes: * Added a new API ast_sip_retrieve_auths_vector() that takes in a vector of auth ids (usually supplied on a call to ast_sip_create_request_with_auth()) and populates another vector with the actual objects. * Refactored res_pjsip_outbound_authenticator_digest to handle multiple Authenticate headers and set the stage for handling additional digest algorithms. * Added a pjproject patch that allows them to ignore digest algorithms they don't support. This patch has already been merged upstream. * Updated documentation for auth objects in the XML and in pjsip.conf.sample. * Although res_pjsip_authenticator_digest isn't affected by this change, some debugging and a testsuite AMI event was added to facilitate testing. Discovered during OpenSIPit 2021. ASTERISK-29397 Change-Id: I3aef5ce4fe1d27e48d61268520f284d15d650281	5 years ago
Corey Farrell	527cf5a570	Remove redundant module checks and references. ... This removes references that are no longer needed due to automatic references created by module dependencies. In addition this removes most calls to ast_module_check as they were checking modules which are listed as dependencies. Change-Id: I332a6e8383d4c72c8e89d988a184ab8320c4872e	8 years ago
Corey Farrell	9cfdb81e91	loader: Add dependency fields to module structures. ... * Declare 'requires' and 'enhances' text fields on module info structure. * Rename 'nonoptreq' to 'optional_modules'. * Update doxygen comments. Still need to investigate dependencies among modules I cannot compile. Change-Id: I3ad9547a0a6442409ff4e352a6d897bef2cc04bf	8 years ago
Richard Mudgett	6f15500ced	res_pjsip_authenticator_digest.c: Fix sorcery's immutable contract violation. ... The inbound authentication object is supposed to be immutable when it is stored in sorcery. However, the immutable property is violated if the authentication object does not have a realm set. The immutable contract violation has a different effect depending upon what sorcery back end is used. If it is the config file back end you would get the same object back until res_pjsip is reloaded. If it is the real-time or AstDB back end you would get a new object on each query. If it is cached you would get the same object back until it is refreshed from the database. Once an inbound authentication object has its realm set it may or may not get updated again if the default_realm changes. If the same authentication object is used for inbound and outbound authentication then the immutable violation can make it very hard to determine why the outbound authentication now fails. The only diagnostic message is a complaint about no realms matching when it had worked earlier. It fails because of the difference in behaviour for an empty realm setting between inbound and outbound authentication objects. * Fixed the sorcery object immutable violation by creating a new object and setting the default_realm on it instead. The new object is a shallow copy for speed. * The auth_store thread storage no longer holds an auth ref. It interferes with the shallow copy and never needed a ref anyway. ASTERISK-26799 #close Change-Id: I2328a52f61b78ed5fbba38180b7f183ee7e08956	9 years ago
Kevin Harwell	1e876d6915	res_pjsip_authenticator_digest: Don't use source port in nonce verification ... From the issue reporter: "res_pjsip_outbound_authenticator_digest builds a nonce that is a hash of the timestamp, the source address, the source port, a server UUID that is calculated at startup, and the authentication realm. Rather than caching nonces that we create, we instead attempt to re-calculate the nonce when receiving an incoming request with authentication. We then compare the re-calculated nonce to the incoming nonce, and if they don't match, then authentication has failed early. The problem is that it is possible, especially when using TCP, to receive two requests from the same endpoint but have differing source ports for those requests. Asterisk itself commonly will use different source ports for outbound TCP requests." This patch removes the source port dependency when building the nonce. ASTERISK-25978 #close Change-Id: I871b5f4adce102df1c4988066283095ec509dffe	10 years ago
Alexei Gradinari	322c3b4262	res_pjsip: module load priority ... The res_pjsip_authenticator_digest, res_pjsip_endpoint_identifier_* and res_pjsip_registrar modules should load ASAP to avoid "No matching endpoint found" for legitimate endpoint. ASTERISK-25994 Change-Id: Iac95d95ad031e0be104189d29e923a2ad7c24a1b	10 years ago
George Joseph	4ebf9a938d	res_pjsip: Add ability to identify by Authorization username ... A feature of chan_sip that service providers relied upon was the ability to identify by the Authorization username. This is most often used when customers have a PBX that needs to register rather than identify by IP address. From my own experiance, this is pretty common with small businesses who otherwise don't need a static IP. In this scenario, a register from the customer's PBX may succeed because From will usually contain the PBXs account id but an INVITE will contain the caller id. With nothing recognizable in From, the service provider's Asterisk can never match to an endpoint and the INVITE just stays unauthorized. The fixes: A new value "auth_username" has been added to endpoint/identify_by that will use the username and digest fields in the Authorization header instead of username and domain in the the From header to match an endpoint, or the To header to match an aor. This code as added to res_pjsip_endpoint_identifier_user rather than creating a new module. Although identify_by was always a comma-separated list, there was only 1 choice so order wasn't preserved. So to keep the order, a vector was added to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar to find the aor. The res_pjsip_endpoint_identifier_* modules are called in globals/endpoint_identifier_order. Along the way, the logic in res_pjsip_registrar was corrected to match most-specific to least-specific as res_pjsip_endpoint_identifier_user does. The order is: username@domain username@domain_alias username Auth by username does present 1 problem however, the first INVITE won't have an Authorization header so the distributor, not finding a match on anything, sends a securty_alert. It still sends a 401 with a challenge so the next INVITE will have the Authorization header and presumably succeed. As a result though, that first security alert is actually a false alarm. To address this, a new feature has been added to pjsip_distributor that keeps track of unidentified requests and only sends the security alert if a configurable number of unidentified requests come from the same IP in a configurable amout of time. Those configuration options have been added to the global config object. This feature is only used when auth_username is enabled. Finally, default_realm was added to the globals object to replace the hard coded "asterisk" used when an endpoint is not yet identified. The testsuite tests all pass but new tests are forthcoming for this new feature. ASTERISK-25835 #close Reported-by: Ross Beer Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d	10 years ago
Rodrigo Ramírez Norambuena	eec010829a	AST_MODULE_INFO: Format corrections to the usages of AST_MODULE_INFO macro. ... Change-Id: Icf88f9f861c6b2a16e5f626ff25795218a6f2723	11 years ago
Kinsey Moore	86a4ce4957	PJSIP: Enforce module load dependencies ... This enforces that res_pjsip, res_pjsip_session, and res_pjsip_pubsub have loaded properly before attempting to load any modules that depend on them since the module loader system is not currently capable of resolving module dependencies on its own. ASTERISK-24312 #close Reported by: Dafi Ni Review: https://reviewboard.asterisk.org/r/4062/ ........ Merged revisions 425690 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 425691 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425700 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Richard Mudgett	270932635d	Simplify UUID generation in several places. ... Replace code using ast_uuid_generate() with simpler and faster code using ast_uuid_generate_str(). The new code avoids a malloc(), free(), and copy. ........ Merged revisions 424103 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 424105 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424109 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Mark Michelson	dcf1ad14da	Add module support level to ast_module_info structure. Print it in CLI "module show" . ... ASTERISK-23919 #close Reported by Malcolm Davenport Review: https://reviewboard.asterisk.org/r/3802 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419592 65c4cc65-6c06-0410-ace0-fbb531ad65f3	11 years ago
Matthew Jordan	c6df713da7	res_pjsip_authenticator_digest: Fix md5 hash buffer ... An md5 hash is 32 bytes long. The char buffer must be at least 33 bytes to avoid clobbering of the stack. This patch also fixes a potential clobbering in test_utils.c. Thanks to Andrew Nagy for reporting and testing this out in #asterisk-dev Reported by: Andrew Nagy Tested by: Andrew Nagy ........ Merged revisions 404843 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404844 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	5b4aab75ef	Fix correct authentication behavior for artificial endpoint. ... When switching to using a vector for authentication, I initialized the vector for the artificial endpoint to be of size 1. However, this does not result in AST_VECTOR_SIZE() returning 1 since there isn't actually anything in the vector. Rather than trifle with the vector by putting unnecessary elements in, I simply changed the callback in res_pjsip_authenticator_digest.c to explicitly report that the artificial endpoint requires authentication. Thanks to Joshua Colp for pointing this out. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403605 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	b18ed67d16	Switch PJSIP auth to use a vector. ... Since Asterisk has a vector API now, places where arrays are manually resized don't really make sense any more. Since the auth work in PJSIP was freshly-written, it was easy to reform it to use a vector. Review: https://reviewboard.asterisk.org/r/3044 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403499 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Jonathan Rose	3c645e8520	PJSIP: Improve error handling in digest authenticator ... Previously, regardless of whether failure to authenticate was due to lacking any authentication or actually failing authentication, the Digest Authenticator would simply return that a challenge was still needed. It will continue to do that when no authentication information is in the received SIP digest, but when authentication information is present and does not pass authentication, that will be treated as an authentication error. This is to ensure that PJSIP will issue security events indicated failed auths. ........ Merged revisions 402537 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402538 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	bbf5fbbd8c	Change how realms are handled for outbound authentication. ... With this change, if no realm is specified in an outbound auth section, then we will simply match the realm that was present in the 401/407 challenge. (closes issue ASTERISK-22471) Reported by George Joseph (closes issue ASTERISK-22386) Reported by Rusty Newton Patches: outbound_auth_realm_v4.patch uploaded by George Joseph (License #6322) ........ Merged revisions 399059 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399082 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago
Mark Michelson	735b30ad71	The large GULP->PJSIP renaming effort. ... The general gist is to have a clear boundary between old SIP stuff and new SIP stuff by having the word "SIP" for old stuff and "PJSIP" for new stuff. Here's a brief rundown of the changes: * The word "Gulp" in dialstrings, functions, and CLI commands is now "PJSIP" * chan_gulp.c is now chan_pjsip.c * Function names in chan_gulp.c that were "gulp_*" are now "chan_pjsip_*" * All files that were "res_sip*" are now "res_pjsip*" * The "res_sip" directory is now "res_pjsip" * Files in the "res_pjsip" directory that began with "sip_*" are now "pjsip_*" * The configuration file is now "pjsip.conf" instead of "res_sip.conf" * The module info for all PJSIP-related files now uses "PJSIP" instead of "SIP" * CLI and AMI commands created by Asterisk's PJSIP modules now have "pjsip" as the starting word instead of "sip" git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395764 65c4cc65-6c06-0410-ace0-fbb531ad65f3	12 years ago